The Vision, the Product Backlog and the Minimal Viable Product

Posted on Monday 7th November 2011

Summary

Learn how the product vision, the product backlog, and the concept of a minimal viable product (MVP) can be combined to facilitate successful innovation.

25 Flares Filament.io 25 Flares ×

I find the Lean Startup concept of a minimal viable product (MVP) rather exciting: It entails creating a first product version to test our ideas 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.

Build, Measure, Learn

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.

To reach our goal, we have to decide on an approach or strategy. This includes making assumptions about the target group, the needs the product should address, the key product features, and the value it should create for the organisation developing. I use my Vision Board to capture and visualise the product strategy.

The strategy’s assumptions must be validated. A great way to do this is to create the minimal viable product and to release it to the target customers and users.

The Product Backlog

Unfortunately, the product strategy is often too coarse-grained and partial 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 strategy.

The corresponding items are placed in a sketchy, lightweight product backlog. To put it differently, the backlog is derived from the product strategy; it makes the strategy implementable.

Vision, Product Strategy, Product Backlog

From Backlog to Minimal Viable Product

Once we have a strategy 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 relevant data.

Strategy, Backlog, and MVP

Note that releasing the MVP can be limited to a small group of 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. A counter example is Google Buzz: The software was apparently loved by Google engineers, but unfortunately not by the rest of the world.

Pivot or Persevere?

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 in the product strategy – which is likely to be the case when a new product is developed – we should adjust it together with the product backlog. Making changes to the strategy is also called pivot.

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 product strategy can require restocking the backlog. With the backlog updated, we continue with the next cycle, develop a new MVP, and gather new feedback.

Pivot

If the data confirms our strategy, we preserve and adapt the product backlog by incorporating the insights gained. 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.

Persevere

Summary

Using a minimal viable product is a powerful concept to validate the product backlog 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 @stefanroock for feedback on the first MVP of this post.

If you’ve found this blog post interesting, you are likely to benefit from my Agile Product Management training. The course teaches a combination of Lean Startup, Scrum, Kanban, and Design Thinking techniques. Check it out!

13 comments on “The Vision, the Product Backlog and the Minimal Viable Product

  1. Synesthesia says:

    […] The Vision, the Product Backlog and the Minimal Viable Product […]

  2. Vin D'Amico says:

    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.

  3. […] 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 […]

  4. […] 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 […]

  5. […] 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 […]

  6. MJ says:

    Hi Roman,

    Great Article! I love your posts.

    I believe one strong point in your writing is the way to represent your ideas through visuals…I might skip a few words but can never get enough of the images you use…Do you mind sharing how you get these? Do you have an UI expert?

    Keep up the good work!

    • Hi MJ, Thanks for the feedback. Glad to hear you enjoy reading my blog. I create the pictures myself. My goal is to allow the readers to understand the gist of a post by just looking at the images. But I am lucky to have a wife who is a textile and fashion designer, who provides constructive feedback on my pictures, and sometimes helps out with a little bit of Photoshop work.

  7. […] Our first minimal viable product (MVP), the product increment of the second sprint, turned out to be a failure […]

  8. Taimoor changaiz says:

    Nice Article, having knowledge able things. Great :)

  9. […] We use product increments or MVPs to gather the relevant information from users, customers, and other stakeholders. […]

  10. jh says:

    2nd MJ’s thoughts. Wondering if you would share the diagram templates?

Leave a Reply

Your email address will not be published. Required fields are marked *

* Copy This Password *

* Type Or Paste Password Here *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>