Pick 2: Number of Features, Delivery Speed, and Product Quality
The realities of software development constrain optimization. We can never accomplish all three:
- Delivery speed: the velocity of shipping new features (which is different from the sprint velocity).
- Number of features: the product’s capabilities or components.
- Feature quality: features actually work as advertised, due to their design and their technical construction (which is different from whether the users will derive value from those features).
Here’s why you can’t get all three. At small companies, there’s never enough time or people to attain all three. At big companies, the heightened stakes of launch failure and complexities of delivery make it impossible to attain all three.
No matter where you are, you need to choose only two. You’re better off being explicit about it.
You can find examples of successful products built in any of the Venn diagram intersections:
- A) More features built quickly with low quality: Microsoft Office’s first release. I have heard, on good authority, that Office shipped with 50,000+ known bugs. They knowingly cut quality to ship the full suite faster and become the first, dominant player in a new market.
- B) Fewer features built quickly with high quality: Netflix, TikTok, and Shopify*. Even today, these apps remain remarkably simple. They provide an excellent user experience, they’ve grown quickly, and work as well as any app.
- C) More features built slowly with high quality: a space shuttle, or art restoration. For complex projects or with catastrophic costs of failure, this method is rarely used in software development today.
*Note: rather than build many features in-house, Shopify built a platform for third-party developers to build them. This enabled far more custom features for merchants than Shopify ever could have built.
Even though each method has delivered successful products, I believe, for software products today, Choice B maximizes the likelihood of success. Here’s why.
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.
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 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.
Choice B: make focused, de-risked bets (fewer features built quickly with high quality)
This is the best choice, but it can feel uncomfortable because it puts more onus on product managers and designers.
To discover the right product, PM’s don’t merely close their eyes, think really hard, and fiddle around in a spreadsheet. Instead, we pour through user interviews, prior art, knowledge within the company, comparable and competitive products, behavioural models, and build prototypes to execute *experiments*.
We default to no-code experiments unless those can’t yield useful insights.
The alternative to no-code experiments is testing in prod. This can feel fast, but it’s a false economy. That’s because testing in prod is prone to conflate a feature launch with a user outcome. Users don’t care about features. They only care about what features do for them. While it’s tempting to build a feature to test in prod, we can deliver results faster if we invest in experiments before building the feature.
Once our experiments de-risk a feature, we should still pare down the design in order to ship code faster (remember: testing with real users is still the goal). That’s fine – perfect, even! Armed with the testing results, we’re equipped to make the best design trade-offs.
Do all features require experimentation? No. But novel features do. Features can be novel in subtle ways: in design, in a new market, or at a new time. It’s worth taking at least 20 minutes to fact-check your intuition on whether an experiment is worthwhile.
[I]f there’s nothing distinct about your approach… don’t build an MVP! It is the wrong tool because there’s nothing new to validate.
- Avrum Laurie, VP Product of Wealthsimple (MVPs: You’re doing it wrong.)
Does experimentation ensure all features will be successful? No, sadly. We’re still placing bets. But they’re focused bets, stripped down to the risk that we couldn’t eliminate through no-code experimentation.
Managing the downsides of Choice B is the easiest path
A perceived downside of Choice B is that we ship fewer features to users. This is true. But, a silver lining: users get to avoid the bloat of too many features. Instead, what they get is a thoughtfully-designed, minimal, opinionated product that’s easy to use — and hey, it works! With the time you have, focus on quality over quantity.
Another perceived downside of shipping fewer features is we place fewer bets. This is only partially true. Poor quality bets aren’t worth making anyway. Experimentation improves your betting odds. You can also make up for fewer bets with a strong product vision and strategy.
Most ideas just don’t work. 100% of customers are not as excited as we are about any idea. Most don’t care at all. Assume 75% of ideas won’t work as expected.
- Inspired, by Marty Cagan (paraphrased)
Another downside of Choice B is that it doesn’t leave much wiggle-room for new features, because it’s mainly about feature reduction. Suppose an engineer finds a way to minimally extend existing code functionality to build a new feature easily. What then?
It depends. 15 out of 20 good product ideas won’t work as expected. So we should still validate feature ideas that are ostensibly beneficial. If tests indicate it’s usable and valuable, then great — prioritize it! If not, we take it as a learning opportunity. To encourage ideas, run quarterly hackathons and host a regular forum to get input from the agile team and other stakeholders.
Choice C: Waterfall (more features built slowly with high quality)
This is the worst choice because it’s the most likely to fail.
Although waterfall is not defined this way, it nonetheless forces Choice C. Because the scope is fixed while costs and time are variable, it inherently prioritizes completeness (features and quality) over delivery speed.
Again, 15 out of 20 good product ideas won’t work as expected. Waterfall methodology incentivizes us to build more of these ideas and to spend a long time doing so.
Although rapid no-code experiments are worthwhile, the highest fidelity test is, of course, testing in production with real users. This is why we need to ship minimal features to users quickly. Waterfall prohibits that.
Waterfall also poisons culture in today’s software teams. In every team I’ve worked with, we’ve found the same thing: shipping fast and shipping often solves all our problems. It means we’re learning, which enables us to make better choices quickly. It means we’re delivering user value, or getting closer to it. It means we don’t overwrite staging, for cryin’ out loud! It means the rest of the company feels we’re making forward momentum. It means we unblock other features. It means we set a high standard for our future selves.
In summary: to maximize the likelihood of software produce success, choose to build fewer features quickly with high quality.
- Run rapid experiments to improve the odds of feature success.
- Build features against a product vision and strategy (which, itself, should be validated).
- Run quarterly hackathons and host regular a forum to get ideas from stakeholders.
