Posted on Mar 28, 2017 on Create Hub, here. Bringing Ideas Alive Early Samuel Fry You may have heard of the concept of a “Minimum Viable Product” before. The idea is that teams should release a product, website or app as early as possible, rather than waiting to release a fully-fledged product at a much later point, at which time it may no longer be valuable to those that need it. In my own projects, I have found this to be a useful way to think about getting quick feedback on a new product. I have found that teams often love the idea of creating a Minimum Viable Product, and can see how it has worked for projects in the past; however, they find it difficult to decide what this means for their own project. So, I thought I would share a few of my own thoughts on the subject here. Where did the idea of an MVP come from? The concept of a ‘Minimum Viable Product’ (MVP) originally comes from a movement called ‘Lean’. The ‘Lean’ approach started in the manufacturing industry, and is made up of 7 principles, including the need to eliminate waste, build quality and deliver fast. It’s been applied to many industries since, and is also used by entrepreneurs. Entrepreneurs took to the idea after Eric Ries created a book called ‘The Lean Startup’. Ries has claimed ‘Lean’ is “the movement that is transforming how new products are built and launched.” So, that’s where the idea of an MVP came from. But what happened next? Skateboards, Cars and the Minimal Viable Product A few years ago, a consultant called Henrik Kniberg demonstrated the idea of an MVP through the metaphor of building a car. Essentially, if you were building a car and wanted to define the ‘minimum’ product able to be tested with users, you would have to ask the question: why do the users need a car anyway? Kniberg explained that, in this case, the users want to get from A to B. So, to test whether a vehicle (such as a car) helps them get from A to B, it is not very useful to test an individual part, such as a wheel. For the users, a wheel does not help them with the overall outcome that they need. Instead, you need to test a minimal viable product, such as a skateboard. It’s not quite a car yet, but it helps test if a vehicle that can get you from A to B is useful at all. Kniberg demonstrates this through an image, comparing the two approaches: As Kniberg’s image shows, creating a MVP means that at no stage is an incomplete or unworkable product released. Instead, whatever is released should always serve the core purpose (helping users get from A to B). Kniberg’s explanation is a good one; however, it is just a metaphor. In reality, a car is pretty unlikely to be built in this way. The point is to show that by releasing a product early, you can quickly understand whether it’s worth building at all. The example reminds me, when I am working on my own projects, that it is important to test whether what has been created is a success. We need to test whether the new product gives the user the outcome that they need. Plus, it’s important to test whether this new product will drive other benefits to the business. For instance, will it provide another source of income? Or, will this new product improve customer perceptions of the business that is providing it? It’s for this reason that some people prefer the phrase ‘Earliest Testable Product’ rather than ‘Minimal Viable Product’ – as it helps them focus on the need to test what is being created, early and often. Deciding on your Minimal Viable Product For a lot of teams, the challenge is deciding what the minimal product is. I’ve worked on developing several different websites and apps. In my view, the only way to be able to plan an effective Minimal Viable Product is to understand the following:
User Story Mapping If you think about it, the less that is needed to be built, the quicker it can be built. However, many businesses find it difficult to decide what the minimum amount needed in a product is. Naturally, they want everything. Who can blame them? If you were paying for a new product to be built, wouldn’t you? Yet building everything is rarely the right thing to do. It’s expensive and, without any user feedback, that money could be completely wasted. Instead, if we know all three of the things listed above, then we can conduct several exercises to explore options for the Minimal Viable Product itself. My favourite exercise is one that I first discovered by reading a book called ‘User Story Mapping‘, by Jeff Patton. In one chapter of this book, Patton uses the metaphor of designing the experience of leaving the house in the morning, to demonstrate how to decide what is needed in your MVP and what is not. In theory, there are lots of things you could do in the morning: you could have breakfast, prepare your lunch, check the weather report. However, if you woke up just 5 minutes before you needed to leave, you probably could still leave, right? So, what do you have to do to leave the house? What do you have to have in your product to achieve your ends? In this case, when planning the MVP, we would measure whether the ‘user’ can leave the house in 5 minutes while completing the tasks at hand. This is a great example, and one I liked so much that I created the video below to show the metaphor in full: In my view, thinking about the Minimal Viable Product is a good way to prioritise what is needed and what is not. Plus, the concept also helps teams to focus on what needs to be tested with users. It might not work for every project, but if you can apply it to your work, then I find it to be a good way of getting early feedback.
The Story Map above is just one exercise to help decide on a Minimal Viable Product. I would love to hear about other exercises or processes that people use to create their MVPs. Let me know by tweeting me: @samueljfry
0 Comments
Leave a Reply. |