You’ve probably seen this before: A team of well-funded, intelligent people, many of them engineers from top-flight companies, build a product over the course of six months to a year, maybe more, and when the release it, the industry reacts with a yawn, or not at all, or worst – negatively. Or the product utterly fails to scale, or is unusable by customers, or is so inflexible that customers who do buy it are unhappy.

 As a lean, agile, hungry startup with both existing and new customers, and engineering, product management, and sales teams who all make significant, intelligent, demands on us, we have to make difficult choices every day about where we put our efforts. And once we do make those choices, we are faced with countless design problems, mostly coming down to the question of “how”?

 How should a feature behave? How should customers interact with an application? How should we build a new caching or query system?

 At every turn, we ask a question: “What is the minimal viable product (MVP) approach here?”. This is neither laziness nor cutting corners: Our intent is to get to insight as quickly as possible. When building a caching system, we could attempt to take six months and roll out a complex system that caches queries in a wonderfully reusable, interesting way. Or we could take a sprint, do a quick prototype spike, roll it out in a limited way, and start learning about how the system behaves under load in the real world very quickly. And then roll that learning back into what we do quickly.

 When building a feature, we could implement it in a robust way, with a high degree of flexibility, lots of options, perhaps throw in a dash of extensibility to cover our butts. The kind of things Really Large Companies do when they can only ship once every two years. Instead, we build the minimal feature needed to enable us to learn what our customers, and their customers, benefit the most from – what resonates and what gets no use. Then we can quickly take those learnings and use them to guide our feature development in the most optimal way. The MVP approach can also help get you out of the analysis paralysis phase – rather than bouncing between N solutions, of which none of us is sure of the best one, we simply pick the simplest solution, move quickly, get it deployed, and feed the results back into our plans.

 Try this in your next design meeting.