Tag Archives: product discovery


Step 1: Do the Prep Work

Before you create your GO product roadmap, you should carry out the necessary problem validation work. Investigate the target group, the problem to be solved, the business goals, and the technical feasibility of your product. The Vision Board, the Business Model Canvas, and the Lean Canvas are great tools to capture and validate your ideas.


To see how this can work in practice, take a look at the Vision Board below. The board captures the idea of creating a digital dance game together with the intended audience, the benefits, the key features, and some aspects of the business model:


Step 2: Build the Roadmap

The Vision Board, Business Model and Lean Canvas are helpful tools to describe the market, the value proposition, and the business model. But they not tell us how the strategy will be executed. Will the first product version deliver the entire value proposition and generate the desired business benefits, for instance, or will this take longer? Say we focus the first version of the dance game on user acquisition. While this is a necessary step towards the vision, it does not answer the question when revenue will be generated. This is where the GO roadmap comes in.

I used the Vision Board above to create the roadmap shown below. You can download a PDF and Excel template by clicking on the picture.


The roadmap above takes the Vision Board contents, and shows how the strategy is executed over the next 12 months. It states the planned major releases with their goals, key features, and metrics. Version 1, for instance, is focussed on user acquisition, version 2 on activation and revenue generation. Version 3 is about retaining existing users, and version 4 targets a new segment and tries to acquire new users. (I discuss in more detail in my post “The GO Product Roadmap”.)

Your roadmap should tell a coherent story about how the product is likely grow: Choose the goals carefully and consider their relationships.

Which timeframe your roadmap should cover and how often you want to create a major release / new product version depends on your product. You should be reasonably confident about your roadmap and avoid speculation. You can regard the roadmap goals as hypotheses, but they should be informed assumptions, and not wild guesses.

If you cannot look further than the next release, then do not employ a roadmap!

Step 3: Derive your Product Canvas/Backlog

With your GO roadmap in place, you can now take the next step and use the product roadmap to stock your Product Canvas or product backlog. The GO roadmap provides you with the goal for the next major release, the two to three key features, and the metrics, which are a great starting point for discovering the product details including the user journeys, epics, the visual design, and the nonfunctional requirements.


The GO roadmap connects the Vision Board / Business Model Canvas to the Product Canvas/backlog; it links market insights and business model with the product. What’s more, the roadmap allows you to focus your Product Canvas/backlog on the next major release, which results in a smaller and more manageable canvas/backlog that is easier to change and update.

Step 4: Pivot or Persevere?

The process I have suggested so far sounds rather sequential: Do some problem validation work, then build the roadmap, and derive the Product Canvas to develop the product. This may give the impression that the GO product roadmap is a fixed plan that simply has to be executed. But the opposite is true.

Whenever we create something new – be it a brand-new product or new features – the one thing we can be sure of is that our initial ideas don’t work out as planned. As you collect feedback from users and customers on your prototypes, product increments, and MVPs, you should always ask yourself if your product strategy is still valid.

Say we expose an early prototype of the dance game to a test group. But unfortunately, we have to recognise that the kids are less excited by the game and playing it much shorter than anticipated. This data should make us rethink our strategy by asking ourselves if our market assumptions (segment and problems/needs) are wrong or if the user experience provided by the product is adequate. In both cases we have to pivot and change the strategy together with the product roadmap, as the following picture shows.


Note that the picture above assumes that the Vision Board / Business Model has to be changed in addition to the roadmap. That’s not necessarily true if the UX or features of the product are inappropriate but the market and business model-related assumptions are valid.

Be prepared to throwaway your existing GO product roadmap and to create a new one.

To minimise any rework, do the necessary problem validation work recommended in step one, and keep your product roadmap focussed and concise. The more details you add the more attached you become to your roadmap, and the harder it is to let go.

Once you have reached product-market fit and are confident that you are building the right product for the right people, I recommend you review and adjust your roadmaps on a regular basis, for instance every two months, as part of your portfolio management process.

Learn more

You can learn more about working with the GO product roadmap by attending my Agile Product Planning training course.

Please contact me for product roadmap workshops and webinars.


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:


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:


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

 “This is your last chance. After this, there is no turning back. You take the blue pill – the story ends, you wake up in your bed and believe whatever you want to believe. You take the red pill – you stay in Wonderland, and I show you how deep the rabbit-hole goes,” says Morpheus to Neo in the movie “The Matrix”. This quote reminds me of the choice we face when dealing with a new product idea: Should we walk away from it, or should we jump into it? And how can we tell?

To help product owners and teams decide if and how to progress an idea, I have developed a tool called the Vision Board. The board captures important assumptions that influence the product success, and it allows teams to start testing and refining their ideas. In this post, I explain how the vision board can be applied to kick-start the innovation process and to create a new software product.

A New Product Idea

I’ve recently had the idea of developing an electronic tool, a digital version of the Product Canvas. The canvas is a multi-dimensional product backlog that allows teams to properly capture the user experience including the user interaction and the user interface design. Since I published the canvas in July 2012, I have received lots of encouraging feedback. Some of it suggested an electronic version, and Johan Steenkamp started to work on a free, web-based product canvas as part of his BMFiddle.

After loosely collaborating with Johan for a couple of months, I was wondering if an enhanced digital canvas would be a good idea. It was like weighing up which pill to take: Take the blue one and leave the tool development to Johan, or take the red one and commit time, money, and energy? To help me make the right choice, I created a vision board for a new electronic product canvas. But before I introduce the board to you, let me briefly remind you what the vision board is all about.

The Vision Board Reloaded

The product vision board captures the initial ideas and assumptions for a new product, as the following picture illustrates.

The board above describes the overarching vision that guides the product. It states who should use and purchase the product (Target Group), why people would want to use and buy it (Needs), what the key product features are (Product), and why the organisation should invest money in the product (Value).

It’s important to understand that the vision board is intended to initiate the innovation process. It does not want to describe the users, the product, and the business model comprehensively or in great detail. It rather captures the critical assumptions, those assumptions that will make or break the product. More information is provided later in form of the Product Canvas and the Business Model Canvas, as the following picture illustrates.

Creating the Vision Board

To clarify my thoughts, I sat down and created a new product vision board. While I am a great fan of simple, physical tools, I decided to create an electronic vision board, as I wanted to share the board with Johan who lives in New Zealand, whereas I am based in the UK. Here is what I came up with:

 To create the board, I started with the vision statement keeping it intentionally broad. This allows me to follow the vision even if my electronic tool idea turns out to be ill conceived. At the same time, the vision reminds me that the new product is only means to an end: to help organisations create great products.

 Next I recorded my ideas about the users. In addition to product managers and product owners, individuals setting up their own business might find the tool helpful. As I am particularly unsure about this group, I have marked it in italic. I use this convention on the other sections of the board, too.

 I then focussed on the user needs formulating them as goals, for instance, being able to share the canvas with remote team members. Note that I have ranked the needs according to my current knowledge. Additionally, I have introduced a barrier: I believe that concerns about intellectual property and data theft may prevent people from using an electronic canvas. If the assumption is correct then it’s likely to have an impact on the solution and on how it is marketed.

 In the next step, I listed those product features, which I consider to be particularly important to create value for the users. I was careful not state a specific solution such as an iPad app, or a web app. This would be premature at this point in time and narrow down the options too quickly. Before I decide on the product specifics, I want to validate the needs of the target group first. As a consequence, the vision board may change based on the new insights.

 Finally, I stated the motivation for my business to invest in an electronic canvas tool. Similarly to the other sections, I have tried to focus on what I believe are the key assumptions and not be tempted to design the business model before I haven’t learned more about the users and their needs. After all, the business model will only work if the needs are met well!
I also found it helpful to state what I view as an investment barrier: If the electronic canvas tool incurs high running cost then this is likely to prevent me from funding the product development effort.

Validating the Vision Board

The next step for me is to validate my assumptions starting with the most critical one: the target group and the needs. I am planning to conduct a series of problem interviews focussed on the issues product owners and managers experience today when they identify, capture and modify requirements, as the picture below shows.

Problem interviews focus on the user needs, their goals and pain points rather than the product itself. In fact, it’s a good idea to exclude any product validation form the problem interviews, and not to ask, for instance: “Would this feature be helpful?” There are other research techniques, of course, for instance, observing users, but I am confident that interviews are adequate for now.

The interviews will hopefully help me validate my assumptions and allow me to learn more about the users. This should enable me to narrow down the solution and decide, for instance, to develop an iPad application, as well as help me find a viable business model. As Morpheus puts it: “Welcome to the desert of the real.” For as long as we just assume and hypothesise, we live in a dream world. By testing our ideas, we face reality.

Get Involved

If you would like to share your experience working with product boards, canvases, or backlogs, if you have any thoughts about what an electronic tool should do for you to capture, test and refine your product ideas, or if you have any specific questions about the Product Vision Board or the Product Canvas, then I’d love to hear from you. Please drop me a line either by email or via Twitter.

You can learn more about applying the product vision board by attending my Agile Product Management training course.


Personas in a Nutshell

A persona is a fictional character that represents a subset of the market we want to address. A persona typically has a name, a picture, relevant characteristics such as age or income group, behavioural traits, common tasks, and a goal that describes the problem the persona wants to see solved or the benefit the character wants to achieve. This information is traditionally based on direct observation, interviews, and other qualitative market research.

Personas should help us develop sympathy for our users and customers. They encourage us to embrace a user-centred approach: Putting the users first, and building a product that that does a great job for the users by meeting the goals of the personas.

Alan Cooper pioneered  personas in product development in the 1990ies. Today they are a technique every product manager and product owner should be familiar with.

A Persona Template

While personas are a powerful technique to capture our knowledge about the users and customers of a product, it can be tricky to write effective personas: Some persona descriptions I have seen were too detailed and bloated; others lacked important information. That’s particularly true when agile and lean practices are applied, and good enough persona descriptions are appropriate, which are updated and refined as more knowledge about the users and customers and their needs becomes available.

Using personas for my now products and in my client-facing work, I have found that there are three pieces of information that are particularly valuable to creating effective personas: the persona’s picture and name, the persona’s details, and the persona’s goal. I therefore use the template below to write personas. Simply click in the picture to download the template as a PDF.


The first two sections in the template above describe who the persona is. The last one is particularly important, as it makes us ask why the persona would want to purchase or use our product.

An Example

Here is an example of how the template can be applied. It features one of the personas of a new book I have recently started to work on:

Notice that I have tried to make the persona description as relevant as possible. I have left out information that is not essential to understand who the character is and why the person would want to read the book. For instance, I decided not to include Peter’s marital status.

At the same time, I have tried to be as specific as I can right now about the persona, so I can validate my assumptions. As I find out more about the target readers of the book, I will undoubtedly iterate over Peter’s description, and update it.

While refining your persona, ensure that the character is believable and that its description allows you to develop empathy for it. You can do this, for instance, by adding pictures, likes and dislikes to the characteristics.

Visualising the Personas

I prefer to capture personas on paper, so I can easily visualise them, for instance, by putting them on the Product Canvas, as the picture below illustrates. An A4 paper sheet usually works well.


Another advantage of using paper-based personas is the limited space available. This helps us focus on the relevant information rather than writing everything down we believe to know about the user.


Personas are a great technique to describe the users and the customers. Employing the persona template introduced in this post helps you create effective personas by describing what matters while leaving out the rest.

You can learn more about working with personas and applying the persona template by attending my Certified Scrum Product Owner an Product Canvas training course. The courses are also available for onsite delivery. Please contact me for more information.

[This post was last updated on 18 December 2013.]

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.


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

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