I find the Lean Startup concept of a minimal viable product (MVP) rather exciting: It entails creating a first product version to test the vision as quickly and cheaply as possible. This could be a throwaway prototype such as a mock-up or a product increment, working software that is tested and documented. The MVP works together with a build-measure-learn cycle: developing software, gathering customer feedback, and learning from it.
With roots in the Scrum tradition, this sounds rather familiar to me: Validating assumptions by gathering customer feedback using product increments is called empirical management or inspect-and-adapt in Scrum. But Scrum advocates the use of a product backlog containing the outstanding work necessary to create a successful product. How does the backlog fit into the picture? And can the product backlog be helpful to create a minimal viable product?
This blog posts answers this question and investigates how Lean Startup and Scrum concepts can be combined successfully.
“If I had asked people what they wanted, they would have said faster horses,” said Henry Ford famously. A vision, an idea of the future product, is the start of any successful innovation. Without a vision, we lack a shared goal, a common direction. But every vision is a hypothesis: It contains assumptions about the future product including the target group, the needs the product will address, a sketch of the product, and the value it should create for the organisation developing and selling it. (See my vision board for a handy tool to capture and display the relevant information.) These assumptions must be validated. A great way to do this is to create the minimal viable product and to release it to target customers and users.
Unfortunately, the product vision is often too coarse-grained to be used as a direct input for writing software. It can therefore be helpful to take an intermediate step, and to identify the work that is required to validate the vision. The corresponding items are then placed in a sketchy, lightweight product backlog. To put it differently, the backlog is derived from the product vision; it makes the vision implementable.
Vision and Backlog
Once we have a vision and initial product backlog available, we create the minimum amount of functionality necessary to test our assumptions. This may take a day or two, or one or more sprints with a preference for the shorter timescales. Our goal is to find out quickly if the product generates a positive response amongst the target users and customers, and if the target group members use the product in the intended way. Once we’ve created the MVP, we release it and gather the feedback.
Vision, Backlog and MVP
Note that releasing the MVP can be limited to a small group of customers and users if the respondents are representative for the target group. Google, for instance, released early versions of its Chrome browser internally and asked its employees to test the software and to provide feedback before a first public beta was released in October 2008. An example where internal releases did not work so well is Google Buzz: The software was apparently loved by Google engineers but unfortunately not by the rest of the world.
Once we’ve gathered and evaluated the feedback, we need to decide if and how to act upon it. If the feedback invalidates any assumptions made in the vision – which is likely to be the case when a new product is developed – we should adjust the vision and the product backlog. We may decide to change the target group or the needs selected, for instance; maybe the features or the look and feel envisioned is not right; or the business model does not work as expected, for instance, users never click on the ads displayed. Changing the vision can require restocking the backlog – depending on how much the vision has changed. We then continue with the next cycle, develop a new MVP, and gather new feedback.
The Vision is Invalid
If the feedback confirms the vision, we adapt the product backlog, for instance, by adding new requirements that help us turn the vision into a successful product. Depending on the quality of the MVP, we may have to throw away any mock-ups and prototypes created so far, and start afresh developing tested and documented software using agile development practices. If the MVP is a product increment, we can progressively transform it into a shippable product using a series of sprints.
The Vision is Valid
Validating the product vision using a minimal viable product is a powerful concept that be used in harmony with Scrum’s approach of creating working software, exposing it to customers and users, investigating their feedback, and making the necessary adaptations.
Many thanks to Stefan Roock for feedback on the MVP of this post.
RSS
[...] The Vision, the Product Backlog and the Minimal Viable Product [...]
I like the concept of MVP very much, The key challenge lies in determining what is ‘minimal’. Aim too low and the target audience may get frustrated and disillusioned. Aim too high and the market may get tired of waiting and move on.
Constant dialog among the development team, business stakeholders and end users is the only way to arrive at an MVP definition that can work.
Hi Vin, Thanks for your comment. Right-sizing the MVP can indeed be tricky. If in doubt, I recommend to release less functionality – like the team did that developed the first public beta of Google News. The team could not decide which feature to implement: displaying local news or the latest news. So the decision was made to ship without any of the two features. Shortly after the beta went live, users started to provide feedback. About three wanted to see local and 300 to read the latest news.
[...] Pichler posted an nice article called The Vision, the Product Backlog and the Minimal Viable Product. In his post he discusses what the Lean Startup concept of Minimal Viable Product means for Scrum [...]
[...] often not feasible. Finally, test your vision quickly by creating a prototype or product increment (minimal viable product), exposing it to target customers and users, and analysing their feedback. This is likely to result [...]
[...] scope to creating a first product increment that allows you to gather customer feedback (aka as minimal viable product or MVP). Then use the feedback and your product vision to decide if and how to [...]