The lean way of building startups: treat features as options

Written by Kamil Nicieja

Kamil Nicieja’s photo

The lean way of building startups: treat features as options

Every early-stage startup must reach two milestones before it can scale.

These two milestones are achieving product-solution fit and product-market fit. A product-solution fit is when your MVP is used by some early adopters to solve a meaningful problem in their lives. They can use it for free; the key part is building something your users genuinely love. A product-market fit is something else, though; it means you found your own niche and you’re ready to sell—and that your unit economics make sense.

Before achieving any of these two fits, startups frequently redesign their products—sometimes even from scratch. That often means hundreds of work-hours wasted. Can founders do anything to avoid that?

The traditional way of building products is feature-oriented. The feature-oriented mindset implies that a complete product is a sum of its features. The better the features, the larger the sum. Similarly, the better the features work together, the better the user experience. Seamless integration usually requires a lot of effort in implementation and design; delivery teams have no choice but optimize their processes to hit a sweet spot between feature quality and quick implementation. The feature-oriented mindset clearly revolves around building stuff.

This approach can work well when you work with an established product. With an innovative product, great implementation often turns out to be a waste of resources unless a startup can get meaningful traction.

The alternative approach to building products is to treat features as options.

The first significant difference is that an option isn’t a commitment—while talking about features, user stories, product backlogs, versions, milestones, or scope inevitably makes us think about estimates, man-hours, and implementation. An option is just that—an option. You may build it or you may not.

The second significant difference is that planning with options makes you a lot more conservative. Investing little in a feature sounds cheap. Investing little in an option sounds smart; actually, it’s investing too much that would look stupid. Taking the options approach means that, in the end, you believe that only the real-world market can verify whether your ideas make sense and that you’re willing not to have all the answers right from the start.

While the feature-oriented mindset revolves around building stuff, the option-oriented mindset does the exact opposite. It optimizes for removing stuff easily. If you explore and option and you discover that your customers don’t like the functionality you wanted to build, you must be able to abandon it without any hesitation—and every engineer knows that building loosely coupled systems is a different challenge than building tightly coupled monoliths.

So even though some people will argue that calling features options is just a matter of nomenclature, there are some subtle yet meaningful differences. The general rule, I think, is that options are valuable when the level of uncertainty about your requirements is high. The more uncertain you are, the more careful you should be before you commit to spending valuable resources. But when the level of uncertainty is low—for example, you’re building a standardized solution or copying some existing product—the options approach would be unnecessary. It’s up to you to choose which method will work better in your situation.

I already said that the feature-oriented mindset revolves around building stuff easily. The option-oriented mindset does the exact opposite. It revolves around removing stuff easily. If you really want to treat your features as options, you’d better be able to abandon it early on when you’re still not sure whether your customers will like the functionality you built.