Pick 2: Number of Features, Delivery Speed, and Product Quality
By: David Pardy
Tags: Agile, Experimentation, Product Design, Delivery, MVP

Choice A: low-quality product (more features built quickly with low quality)

This is the second-worst choice. There are two main reasons: (1) poor design quality makes products bad, and (2) poor technical quality makes products bad.

(1) Poor design quality makes products bad

Every feature you add makes the product worse for everyone; it also makes the product better just for the people who use it. - Tobi Lütke, CEO of Shopify (paraphrased from a podcast)

It is the most basic of all product lessons that trying to please everybody will end up pleasing nobody.

Cramming too many features into a product, which is the primary culprit for bad design, fills the user experience with friction. Adding makes the product’s positioning blurry. Users get confused. You lose the game before it starts.

Instead, keep it simple. It’s very hard to make something simple. It’s impossible to make a complex product simple. Nail simple, then layer on complexity. (This is also from Tobi Lütke.)

Today, nearly every market niche you can find is home to a high-quality product. The bar for products is higher than ever — and it will continue to rise. We, as spoiled consumers, demand top quality from every app.

(2) Poor technical quality makes products bad

Products are dead on arrival if the features don’t work. Features that don’t work shouldn’t be there at all.

Technical quality is not just a matter of poor user experience. It also slows down development. The code becomes unwieldily. The data gets contaminated. You get so bogged down in firefighting that you can’t spend any time on new features.

Experiencing a product first hand, it’s easy to see why quality matters. Original tweet: https://twitter.com/jasonlk/status/1299356971020156928

Building lots of features quickly with poor quality is “Agile’s Worst Myth”. It’s a myth because this is often how it’s (mis)interpreted, not because it’s a flaw in agile itself.

The main tenets of agile (rather than waterfall) are:

focus on individuals and interactions (rather than process and tools), deliver working software (rather than documentation), get customer-product interaction (rather than negotiate contracts), and respond to change (rather than follow specs).

Agile’s Worst Myth. This is not what agile methodology actually preaches.

Agile’s Worst Myth is as follows. First, we choose to get Feature A working in the hands of customers quickly (agile tenets 2 and 3). To do this, we pare it down to A1, the bar for which is: “it works”. We don’t fuss over process or documentation, since our assumption is that we’ll respond to change once customers use it (tenets 1 and 4). This rationale is sound: we deliver A1’s value to users quickly, answer some questions about user behaviour, and use those learnings to build A1’s evolution: A2.

And if there were no other business priorities, that’d be dandy.

But here’s why it’s a myth: companies clamour for resources to build the next thing, Feature B. So instead of building A2, we build B1. By the time B1 is done, the priorities have changed again. So we build C1. This continues until we’re left with a suite of janky features A1 to Z1 instead of high-quality features A3, B2, D5, etc.

This is not how the agile method is designed to work. Agile presumes we’re capable of prioritizing A2 versus B1, C1, or beyond. Granted, in some cases we are. But doing so takes discipline — and not the sexy kind. It takes the kind of discipline of looking into your CEO’s eyes and saying, “Hello, CEO. You know that feature we shipped 10 months ago? We need to work on that again, and here’s why.” Deeply unsexy discipline. This type of discipline, by definition, is not Choice A.

To counter Agile’s Worst Myth, it’s best to build A1 to the sufficiently high quality that, if and when priorities change, users are still content that they have it. Typically, this requires a higher quality bar than the feature merely working.