It is not about how do you build software.
It is about which feature do you build.
This is what I used to say. And it explains how I got into MVP (short for minimum viable product).
But I have changed. Based on the learning from applying MVP on several organizations, I realized there was even more value prior to looking at the product features to build.
It is not about which feature do you build.
It is about which product do you explore.
Prior to defining the product features to be built, you must first define the product to be explored.
There are so many great product exploration opportunities. But which one should you pursue?
One thing I have been playing with is the Cost of Delay concept (I first read it on the amazing book: The Principles of Product Development Flow by Donald Reinertsen).
Put some numbers on the different product initiatives. For each product initiative, estimate how much you are missing out by not having it ready (delay). Then estimate how much it costs for building the first MVP for exploring it (cost). Now apply the ratio cost and delay. Then you will be able to compare the cost of delay for different initiatives.
So you have product initiatives 1. 2. 3. 4… Which product initiative should you explore?
Calculate the cost of delay for each initiative, and then work on the one with highest cost of delay.
Once you decided the best products to explore, then you seek the answers for the following questions: Which product features should you build? What is the MVP?
Then, at this stage, go ahead and schedule a lean inception. Get everyone aligned and create a MVP canvas. Be clear about what encompasses your MVP: the personas, the user journeys, the vision, the expected results, the metrics for validation, and the (minimum set of ) features.
That’s it! Order matter. First decide the product to explore, second define the MVP. And then and only then, you answer a very important question: how do I build the software?
