Tag Archives: minimal marketable product

MMPandMVPfeaturedImage

The Minimum Viable Product

The minimum viable product (MVP), as defined by Eric Ries, is a learning vehicle. It allows you to test an idea by exposing an early version of your product to the target users and customers, to collect the relevant data, and to learn form it. For instance, to test the viability of using ads as the major revenue source, you could release an early product increment with fake ads, and measure if and how often people click on them.

As lack of knowledge, uncertainty, and risk are closely related, you can also view the MVP as a risk reduction tool. In the example above, the MVP addresses the risk of developing a product that is not economically viable.

Since the MVP is about learning, it’s no surprise that it plays a key part in Lean Startup’s build-measure-learn cycle, as the following picture shows:

BuildMeasureLearn

The MVP is called minimum, as you should spend as little time and effort to create it. But this does not means that it has to be quick and dirty. How long it takes to create an MVP and how feature-rich it should be, depends on your product and market. But try to keep the feature set as small as possible to accelerate learning, and to avoid wasting time and money – your idea may turn out to be wrong!

While the MVP should facilitate validated learning, I find it perfectly OK to work with MVPs such as paper prototypes that do not generate quantitative data, as long as they help to test the idea and to acquire the relevant knowledge.

The Minimal Marketable Product

The minimal marketable product (MMP) is a different type of product. It is based on the idea that less is more. The MMP describes the product with the smallest possible feature set that addresses the user needs, creates the desired user experience, and can hence be marketed and sold successfully. The MMP is a tool to reduce time-to-market: It can be launched more quickly than a fat, feature-rich one.

Creating a product with just the right amount of features sounds like common sense. Why would we create more features than necessary? Sadly, I have seen many projects develop over-engineered products with lots of shiny features that provided little value to the users, but cluttered the product and increased the maintenance cost. And it’s not just the others: I am constantly tempted to add just another cool feature to a product, or to write a few extra lines in a blog post. Using the concept of an MMP helps me focus on what really matters, and remove unnecessary features (and lines).

A great example of an MMP is Apple’s original iPhone launched in 2007. I know that the first iPhone was a complex product, and that many people worked incredibly hard on it. But I find it amazing how many features the phone did not provide compared to its competitors: no copy-and-paste, no Outlook integration, and no voice recognition, to name just a few. Nevertheless the phone was still a staggering success. How come?

The key to creating a successful MMP is to “develop the product for the few, not the many,” as Steve Blank puts it, and to focus on those features that make a real difference to the users. To discover the right features, the MVP is a fantastic tool.

Combining the MVP and the MMP

To combine the two concepts, develop one or more MVPs to test your ideas and to acquire the relevant knowledge. Then use your new insights to create and launch the MMP – a product with just the right features and a great user experience, as the following picture shows:

CombiningMVPandMMP

Note that a minimal marketable product differs from a viable one: It is complete enough to be ready for general release, as indicated by the gift wrapping in the picture above. What’s more, launch preparation activities have to take place for an MMP, for instance, creating advertising campaigns, or gaining certification. Some of your MVPs are likely to be throwaway prototypes that only serve to acquire the necessary knowledge; others are reusable product increments that morph into a marketable product.

More Information

You can learn more about applying the two concepts by attending my Agile Product Planning training course. You can also find a more detailed discussion of the minimal marketable product in my book “Agile Product Management with Scrum“.

Product Canvas Creation Workshop Overview

The Product Canvas is a simple, yet powerful tool that helps you create a product with a great user experience and the right features. This post explains how you can create your initial canvas using a collaborative workshop.

Note that many of the recommendations below also apply to other agile and lean product definition tools including a traditional product backlog.

Overview

The Product Canvas creation workshop wants to kick-start your solution validation and product definition activities. It helps you change the focus from problem validation – exploring if there is a need that the new product addresses – to building a product with the right features and the right user experience. The following picture summarises the workshop, and the rest of this post explains the details.

Attendees

Everyone tasked with creating the product should attend the canvas creation workshop: the product owner, the team developing and testing the product, and the ScrumMaster or coach. This creates shared ownership, and it is likely to result in better decisions, as the entire team’s creativity and knowledge are leveraged.

I generally recommend that the stakeholders – the users, and customers as well as the internal stakeholders – do not attend the workshop, but share their ideas and feedback based on prototypes and product increments, for instance, in the sprint review meetings. This allows the product owner and the team to be creative before the stakeholders provide input.

Input

Before you start the workshop, you should be able to confidently answer the following questions:

  1. Who are the product’s users and who are the customers?
  2. What problem does the product solve? What benefits does it generate for its users? What is the product’s value proposition?
  3. What business benefits does the product creates? Why should the company invest in it?
  4. What kind of product is it? What are the three to five features that make it stand out?

I like to capture the insights above using the Vision Board. But you can also employ other tools including Ash Maurya’s Lean Canvas and Alexander Osterwalder’s Business Model Canvas, as the following picture shows:

Being able to answer the questions above means that some problem validation has taken place prior to the workshop, for instance, by carrying out user observations and problem interviews. Note that the strength of the Product Canvas is solution validation – building the right product – and not discovering if the product should be built in the first place!

To ensure a smooth workshop, use a facilitator, for instance, the ScrumMaster. Organise an appropriate room with lots of wall space. Have the necessary materials available including paper sheets, paper cards, adhesive notes, masking tape, markers, and pencils. Starting out with paper and pencil is effective and fun in my experience, even if you intend to use a digital canvas.

Steps to Create the Canvas

To create your initial Product Canvas take the following three steps: Create personas; outline the user experience and the features; determine what to do in the first sprint, as the picture below shows:

The first step creates personas based on the insights gained in your problem validation work. The personas allow you to connect with the target users and customers. Their needs enable you to discover the right product features. I also recommend using a primary persona, as it creates focus and facilitates decision-making. You can read more about personas in the post  “A Template for Writing Great Personas”.

The second step describes the product comprehensively but at a rough, coarse-grained level. Helpful techniques to capture the user experience and the product functionality include scenarios, storyboards, epics, constraint stories, and design sketches / mock-ups. Make sure that the product features you identify address the need of a persona, or support the business model.

The third step determines what should be done in the first sprint. As you are about to start building the first product increment, you should address the greatest risk or the biggest uncertainty. This could be a lack of knowledge surrounding the user interaction, the user interface design, a product feature, or the architecture and technology. See my post “Effective Sprint Goals” for more information on choosing the right goal or hypothesis. Finally, determine what needs to be done to reach the goal, or to test the hypothesis, for instance, creating a scenario and a paper prototype to learn more about the user interaction.

The three steps above form a breadth-first approach: The product is sketched holistically, but the details are determined on a sprint-by-sprint basis. This keeps your canvas concise, and allows you to make changes quickly and effectively.

Outcome

At the end of the workshop you should have a Product Canvas that is good enough to start sprinting: to start building product increments/MVPs, gathering feedback, and integrating the insights gained, as the following picture shows:

Make sure you create a good-enough canvas, but not a perfect one. Your Product Canvas will change and evolve anyway based on the feedback you receive!

Duration

Four to eight hours should be enough time to create your initial canvas. If you require more time, then this may be a sign that you haven’t got enough information available and may have to carry out more problem validation and market research.

Summary

Employing a collaborative workshop, and following the process described above creates an initial Product Canvas that allows you to focus on solution validation – building the product with the right user experience and features. Make sure you understand the product’s value proposition before you enter the workshop, describe the product holistically at a coarse-grained level, and don’t worry too much about the product details: These will emerge incrementally based on the feedback you gather.

You can learn more about the Product Canvas creation workshop by attending my Certified Scrum Product Owner training course. If you would like me to help you run a Product Canvas workshop, then please contact me.

To create a new product, we have to peek into the future and anticipate what the product will roughly look like and do. For anyone not blessed with perfect foresight, predicting the future correctly is notoriously difficult. After all, the only thing certain about the future is that it is uncertain! Investing in a new product hence always involves risk. We may have targeted the wrong market segment, envisioned the wrong product or the wrong features, or the market may have changed by the time the product is launched.

Envisioning a Lean, Minimal Product

A great strategy to minimise the investment risk is to envision a lean, minimal product with the smallest possible feature set. I refer to such a product as the minimal marketable product. It contains just enough functionality to be viable – to launch, market and sell the product successfully. Developing a minimal product is quicker and cheaper than a more ambitious, feature-rich one. If the product bombs less time and money is lost. If it is a success, the product starts earning money sooner. Additionally, a minimal product allows us to receive feedback earlier so we adapt the product quicker to the market response. Rather than trying to create the perfect product, we follow the motto “get it out, then get it right.” Note that the product’s quality must be right from the start. Otherwise it will be difficult to adapt the product; bugs may hinder its adoption, or even damage the brand.

The iPhone

An example of a minimal marketable product is the original iPhone, which launched in 2007. One of the secrets behind its success is the narrow set of customer needs Apple selected. The company avoided the trap of trying to please too many people at once, of trying to copy all the features competitors offered. Instead, Apple took a fresh look at what smartphones should look like and do, and deliberately left out some functionality. The original iPhone shipped without many features standard on existing phones: copy and paste, the ability to send text messages to multiple recipients, and a software development kit, for instance. These limitations, though, did not hinder its success. Paring down the functionality allowed Apple to develop and ship the product within a competitive timeframe and gave the company a significant lead over its competitors. Building on the success of the first iPhone version, Apple started to extend the capabilities of the phone both in terms of hardware and software with the launch of the 3G model in 2008. This version also allowed the company to enter a new market segment by targeting business users.

The Apple Newton

Developing a minimal marketable product may sound like a no-brainer. But my experience suggests that many start-ups and established companies alike find it hard to restrict the features of a new product. It’s often too tempting to opt for a big-bang release trying to satisfy as many users and customers at once in order to maximise revenue. Contrast the iPhone with another Apple product: the Apple Newton, first launched in 1993 after five long years of development. Remember those Apple ads that promised a PDA that could do all sorts of wonderful things, including recognising your handwriting? When it was finally shipped, the Newton proved to be too bulky and heavy. Worse, its most important feature, the handwriting recognition, did not work properly. The product underperformed and was finally withdrawn from the market in 1998. In hindsight, Apple was overly ambitious with its Newton plans. The company launched a product that tried to do too much at once, and failed.

The Steps towards a Minimal Marketable Product

To create a lean, minimal product, limit the target group and “build a product for the few, not the many,” as Steve Blank recommends in his book The Four Steps to the Epiphany. For instance, if you use personas to describe members of your target group, consider the impact of removing a persona. Would the product still sell? If yes, reduce the target group by dropping the persona. Once you have done a great job for your early customers, you’re in a position to build on the initial success with a new, incremental release that attracts new customers.

Second, understand your product’s value proposition and only select the features that are essential to address the needs of the target group. Have the courage and discipline to discard all others for now. Selecting the minimal set of features does not mean creating a bland, boring or simplistic product. It means focusing on those properties that are essential for the product success. If you work with user stories, for instance, review each story or epic, and ask yourself if the product can be shipped with out it. If yes, exclude the story. As the French writer and poet Antoine de Saint-Exupery put it:

“Perfection is achieved, not when there is nothing more to add,
but when there is nothing left to take away.”

You can learn more about minimal marketable products by attending my Agile Product Planning training course. You can also find a more detailed discussion of the concept in my book “Agile Product Management with Scrum“.

“We have 12,000 stories in our product backlog. How can we best groom it,” I was recently asked. Trying to deal with a huge product backlog is more common than we would like to think. Many product backlogs are too long, detailed and complex. This is in stark contrast to what the product backlog should be: a simple artefact listing the outstanding work to bring the product to life. It’s time to put any over-weight product backlog on a diet making it lean and concise.

Think Lean

Lean thinking aims to create a smooth, levelled flow of work by removing waste, minimising variation and avoiding overburden. Waste includes inventory and work-in-progress, defects, delays, and unused employee creativity. Examples of variation are frequent changes to the team and varying release cycles. Overburden occurs when people and resources cannot cope with the workload placed on them. If we want a lean product backlog, then it should contain as little waste and variation, and cause as little overburden as possible. This post focuses on eliminating waste. I will discuss minimising variation and avoiding overburden in a future post.

Eliminate Waste

Waste consumes valuable resources and makes it harder to focus on what’s important. To remove waste in the product backlog, reduce the inventory the backlog holds, avoid overproduction and minimise defects, handoffs and wasted creativity, as I explain in more detail below.

Reduce the inventory in the product backlog: Minimise the amount of detailed product backlog items and only include items in the backlog that are essential for creating a successful product. Ensure that just-enough high-priority items are detailed just in time for the next sprint planning meeting. As a consequence, product backlog items are progressively decomposed and refined – from sprint to sprint. Lower-priority items stay coarse-grained and sketchy until their priority changes.

Avoid overproduction – providing more functionality than users and customer need. Focus on the minimum functionality necessary to bring the product to life, and only list truly valuable items in the backlog. Have the courage to remove all other items from the product backlog. This keeps the product backlog concise and the Scrum team focused. If an item becomes important for a future version, it will re-emerge.

Minimise defects, handoffs and unused creativity by involving the team members and the stakeholders in grooming the product backlog. Jointly discovering and describing product backlog items avoids handing off requirements to the team. It ensures clarity of the requirements thereby reducing defects; and it leverages the creativity and knowledge of the team members and stakeholders. Jointly prioritising the product backlog ensures that technical risks and dependencies are accounted for. Problems consequently surface early, which prevents defects at a later stage of the project.

You can find out more about working with the product backlog effectively in my book Agile Product Management with Scrum: Creating Products that Customers Love or by attending my lean thinking course that teaches product owners how to leverage lean techniques.

A recent posting on deutschescrum brought up an interesting question: How much visioning is necessary in Scrum? Even though I find it impossible to give a general, precise and accurate answer, there are two main factors that influence the time and effort necessary to create the product vision and the initial product backlog: the product’s lifecycle stage, and its complexity.

The younger a product is, the more visioning work tends to be required. A new-product development project may spend several weeks creating the product vision and carrying out necessary prep work such as creating prototypes to explore product design and architecture options. Contrast this with an incremental upgrade of a mature product that may only require a few days of visioning work. The same applies to complexity: The more complex a product is, the more visioning time and effort is usually necessary. Note that complexity comprises not only the internals of the product – its architecture and technology – but also the functionality provided.

When determining your visioning effort, avoid two common mistakes: Don’t rush into the first sprint without having agreed on an overarching goal, without understanding what the future product will roughly look like and do. At the same token, avoid overdoing the visioning work. There is no way to guarantee that the vision is correct, that the new product or next product version will be a certain success. For anyone not blessed with perfect foresight, predicting the future correctly is notoriously difficult; no market research technique can deliver forecasts that are 100% accurate.

I therefore recommend you keep the visioning time and effort to a minimum. Do as little as possible, but as much as necessary. To find the sweet spot, try the following: First, focus on the customer needs and the three to five top features of the product. Second, envision the minimum marketable product – a product with the least amount of functionality that still has a clear value proposition. Third, quickly implement the product vision and gather customer and user feedback on early product increments to validate and refine the vision. And last but not least, reduce complexity by creating a simple product – a product that is easy to use and easy to extend and maintain.

Find out more about visioning in my book Agile Product Management with Scrum or by attending one of my upcoming product owner classes.