Photo by Bench Accounting, courtesy of Unsplash

The Vision, the Product Backlog and the Minimum Viable Product

Published on 7th November 2011

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

I find the Lean Startup concept of a minimum 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.

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.


From Backlog to Minimum 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.

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.

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.


Summary

Using a minimum 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 Stefan Roock for feedback on the first MVP of this post.

Post a Comment or Ask a Question

9 Comments

  • Abbas Dar says:

    Hi Roman

    Many thanks for this, it’s always insightful reading your thoughts. One aspect i’m not grasping from your content is some examples of how to transfer a Vision into a Product Backlog. For me; I perhaps would use a simplistic approach by identifying from the vision what the end user is looking to achieve from this and create some rough PBI’s to form further discussions with the stakeholders/ end users. This of course given that the vision has been validated. I would then work through the PBI’s which in essence are requirements not only with the stakeholders but the development team (which would include actual developers, architect etc) to determine our approach, how we would potentially implement this and identify some of the technologies that could be used.

    Could you point me in the direction that explains your thoughts on this or kindly provide a few examples of the approach/ process you’d take to take to get the vision into a product backlog please?

    your response would be much appreciated,
    Many Thanks

  • jh says:

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

    • Roman Pichler Roman Pichler says:

      Thanks for the feedback, jh. What templates are you referring to? The vision board is described here: https://www.romanpichler.com/blog/the-product-vision-board/

  • Taimoor changaiz says:

    Nice Article, having knowledge able things. Great 🙂

  • 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!

    • Roman Pichler Roman Pichler says:

      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.

  • 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.

    • Roman Pichler Roman Pichler says:

      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.

Leave a Reply

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

Sign up for great new content from Roman

Hear about his latest product management work including new articles, videos, podcast episodes, and more.