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.
The Product Vision
“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.
The Product Backlog
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.
From Backlog to Minimal Viable Product
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.
Comments