Tag Archives: early and frequent releases

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

When I teach product owners, one of the questions I ask is: “What qualities should the product backlog fulfil?” More often than not, a key property is missed: emergence. This corresponds to my experience of how backlogs are commonly used: as a requirements list that doesn’t change much. Instead of being rigid and fixed, the product backlog should be dynamic. It should evolve based on customer and user feedback thereby facilitating the discovery of the right product features, as this blog post explains.

Ideas, not Requirements

At the beginning of a new product development project, there are many unknowns, and we often do not understand what the product should look like and do in detail. Our initial thoughts about the product resemble more ideas than hard-and-fast requirements. We should therefore treat the items of an initial product backlog as assumptions that have to be validated and refined using the feedback from customers and users. This allows us to better understand how we can best solve the customers’ problem, and what the product should really look like and do.

Learning from Customer Feedback

To turn your backlog into a learning tool, expose product increments early and regularly to customers and users, for instance by demoing the increment or by releasing it. Then evaluate the feedback you receive, and decide which changes are required, as the following diagram illustrates:


When evaluating feedback, avoid two common mistakes: clinging on to your ideas and ignoring what your customers and users tell you, and saying yes to every piece of feedback, any new idea, or feature request.

Analyse the feedback carefully with your product vision in mind. Ask yourself if the feedback is helpful turn the vision into a great product – assuming that your vision is valid. If the answer is yes, incorporate the insights gained. Remove or change existing product backlog items, and add new ones. Your product will consequently evolve through on-going dialogue with customers and users.

Enabling Change

Adjusting a large, detailed product backlog usually takes too much time and is error-prone. Focussing your backlog and keeping the majority of its items coarse-grained helps you achieve the necessary conciseness.

If you are developing a brand new product, you may want to restrict the backlog scope to creating a first product increment that allows you to gather customer feedback (aka minimal viable product or MVP). Then use the feedback to decide if and how to proceed.

Keep the majority of your backlog items sketchy and coarse-grained. A great way to do this is to employ my Product Canvas and to capture ideas as epics and user journeys. Identify the biggest risks, and select the epics and journeys you want to test with the next product increment. Then derive small stories and make them high priority.

Summary

Viewing the product backlog as a learning tool facilitates the development of successful products. But it requires overcoming the misconception that the requirements of a new product can be correctly determined upfront. We stand a better chance of success by using early and frequent feedback from customers and users to validate our ideas. As Ken Blanchard says: “Feedback is the breakfast of champions.”

With the term startup we usually associate starting a new company and pursuing a new idea with a small, creative team. While Scrum has been used for many years in startup companies – companies with a limited operating history – I have found that setting up a Scrum team as a “startup” or incubator within an established enterprise is a powerful approach to create a new product, and to pilot a new way of working.

A Scrum Startup consists of the product owner, the ScrumMaster and the development team. Together, they form is a self-contained unit that is loosely coupled to the rest of the organisation and in charge of developing and releasing the product. The product owner acts as an intrapreneur, an entrepreneur within the larger organisation.

An Enterprise Scrum Startup

The first Scrum project I helped run in 2004 had ambitious plans: It was tasked with creating a new enterprise telecommunications software product. The company had high hopes for the product: It was considered vital to the business group’s future. To create an environment that encouraged innovation and creativity, we opened up a new development site, and assembled a new team.

We also made sure that the product owner was able to act as an intrapreneur and received the backing from senior management. The individual had a vision for the new product and a budget to turn the vision into reality. The Scrum Startup controlled the product under development including the development and test environment, and it experienced few changes to the team composition. The individuals had a personal stake in the outcome: Everybody desperately wanted the new product to succeed knowing that it would shape future of the group.

We didn’t quite realise it, but we had created a startup within a well-established, large enterprise: Siemens, a company which has more than 420 000 employees and which is over one hundred years old. The resulting product became part of OpenScape Unified Communications. It has won a number of awards, and is still selling well.

Autonomy

Setting up a Scrum team as an incubator is so powerful as it disentangles the team tasked with innovating from the rest of the organisation. Think of a Scrum Startup as a new house in the enterprise village, or a new tree in the corporate garden.

The members of the Siemens telecommunications project were free to literally think outside the box, to try out new things, and to be creative. Most importantly, it created a safe environment for experimentation: for testing new ideas and for failing. Our first minimal viable product (MVP), the product increment of the second sprint, turned out to be a failure: We had chosen the wrong component technology, and the product did not live up to the users’ performance expectations.

Our first process experiment ended in failure too: We had started using a heavily tailored, lightweight version of the Rational Unified Process (RUP) that included development practices from Extreme Programming. After a few iterations, we decided to switch to Scrum. The RUP iteration management and collaboration practices simply did not work for us.

Without those early failures and the learning that they enabled, we probably would have not been able to deliver a successful product.

Collaboration

As important as autonomy is, it needs to be balanced with collaboration: working together within the Scrum Startup and with the stakeholders. A healthy, trustful relationship between the product owner and the team, the product owner and the ScrumMaster, and the ScrumMaster and the team is a prerequisite for applying Scrum successfully and for creating a great product. But it’s no less important to invite internal stakeholders to participate in the development process, and to use the feedback from target customers and users to create a product with the right features for the right people.

When we created the telco product, we invited representatives from marketing, sales and service to the sprint review meetings, and we demoed MVPs to other development groups destined to build on the product. Releasing early product increments to employees in other parts of the enterprise is another great way to benefit from the ideas of the rest of the organisation, and to keep people informed about the progress. Exposing product increments early and frequently to target customers and users in form of demos or releases helps to achieve a great product market fit.

Scrum Startup Qualities

To help your enterprise Scrum Startup succeed, make sure it fulfils the following four properties: It should be loosely-coupled to the enterprise and in control of the product; the people working on the product should have a personal stake, and the incubator should be stable. The following image depicts the four qualities:

Summary

Reflecting on more than ten years of experience using agile techniques to create products and helping organisations establish Agile, I am convinced that combing the introduction of Scrum with a new product development effort and setting up the Scrum team as an incubator can facilitate product and process success. Give it a go, and let me know how it’s working for you.

Prioritisation requires us to decide how important an item is. If everything is high priority, then everything is equally important. This means in effect that nothing is a priority, so there is only a slim chance of delivering what the customer really needs. Prioritisation is part of product backlog grooming, and it directs the team’s work by focusing the team on the most important items. It also freezes the backlog contents progressively. As items are detailed according to their priority, flexibility is built into the process and allows delaying decisions about the lower priority items, buying the Scrum team more time to evaluate options, gather feedback from customers, and acquire more knowledge. This ultimately results in better decisions and a better product. The reminder of this posts explores four useful factors to prioritize the product backlog: value; risk and uncertainty; releasability; and dependencies.

Value

Value is a common prioritisation factor. We certainly want to deliver the most valuable items first. But what makes a product backlog item valuable? My answer is simple. An item is valuable if it is necessary for bringing the product to life. If that’s not the case, the item is irrelevant; it is excluded from the current release or product version. The Scrum team either de-prioritizes the item and places it right at the bottom of the product backlog or better, discards it altogether. The latter keeps the product backlog concise and the Scrum team focused. If the item is important for a future version, it will re-emerge.

Risk and Uncertainty

Risk is an intrinsic part of software development; no product can come to life risk-free. Correlated with risk is uncertainty. The more uncertainty there is the riskier the project is. Because risk and uncertainty influence product success, uncertain and risky items should be high priority. This accelerates the generation of new knowledge, drives out uncertainty, and reduces risk. If the Scrum team, for instance, is unsure about some aspects of the user interface design, then the relevant design options should be explored and tested by gathering feedback from customers and users. Tackling uncertain, risky items early creates a risk-driven approach that may enforce early failure. Failing early allows the Scrum team to change course while there is still the opportunity, for instance, to modify the architecture and technology selection.

Releasability

Releasing early and frequently is a great way to let the software evolve into a product that customers love. It’s also an effective way to mitigate risks. If the Scrum team is uncertain about if and how a feature should be implemented, then early releases can answer this question. Being able to release product increments early and frequently should therefore influence the product backlog prioritisation. Each release should provide functionality that is useful to customers and users and that generates the desired feedback. Note that it’s usually not necessary to fully implement a theme; a partial implementation is often sufficient for early releases.

Dependencies

Weather we like it or not, dependencies in the product backlog are a fact. Functional requirements, for instance, often depend on other functional and even non-functional requirements. And if several teams work together, dependencies between them can influence the prioritisation. Dependencies restrict the freedom to prioritize the product backlog and influence the effort estimates; the item others depend on has to be implemented first. You should therefore try to resolve dependencies whenever possible. If that’s not an option then the dependencies are likely to influence the product backlog prioritisation. Two dependent items may have to be implemented in the same sprint, for instance.

Find out more about how to prioritise your product backlog in my book Agile Product Management with Scrum: Creating Products that Customers Love.

We all want to create great products – products that customers love and that meet or exceed our financial goals. But the odds of failure are high: Cooper states a failure rate of 25% to 45% for new products in his book Winning at New Products (third edition); some studies reveal even higher odds of failure. Markets develop unexpectedly and customer reaction is hard to predict.

Luckily, agile practices help us increase the likelihood of creating great products. While there are many factors at play, I have found that three practices are particularly important.

Shared Product Vision

Ensure that you have a shared vision in place that describes the target customers and users, the needs the product is going to address and what the product will roughly look like and do. Consider not only the key functional attributes but also non-functional ones including user experience and operational qualities such as performance and robustness. Use prototypes and mock-ups to develop the vision and to gather feedback from target customers and users.

Minimal Marketable Product

Envision the minimal marketable product – a product with minimum functionality that meets the selected customer needs. This shortens time-to-market and allows you to find out quickly how the market responds. If the response is not great then adapt then product to better meet the customer needs. Note that even if you carefully select the target customers and users to gather early feedback as described below, their views might not be representative for the entire market or market segment. And hardly ever is the first version of a product perfect.

Early and Frequent Customer Feedback

Third, gather early customer and user feedback by inviting (selected) customers and users to sprint review meetings and by releasing product increments early and frequently. This integrates customers and users into the development process, and it lets the product evolve based on their feedback. It also shows you quickly if you are shooting for the right goal or if your product vision is ill-conceived.

Find out more about creating great products in my book AgileProduct Management with Scrum or contact me for more information. The book discusses creating a shared vision, envisioning the minimal marketable product, prototyping, early and frequent releases, and involving customers and users in the sprint review meetings in greater detail.