True agility

Introducing the Product Canvas


Originally appearing in JAX Magazine, agile guru Roman Pichler introduces us to a new tool primed to help your agile team deliver a modernised product.

Originally appearing in JAX Magazine, agile guru Roman Pichler introduces us to a new tool primed to help your agile team deliver a modernised product.

The product backlog is a handy tool that lists the outstanding work necessary to develop a product. But it can be insufficient to create a brand-new product or an update aimed at a new market. Its linear structure makes it difficult to capture all product aspects including the user interface design and the user interaction; there is no place to state assumptions about the target group, the users and customers of the product and their needs; and trying to prioritise all items can lead to longwinded discussions that are of limited value.

To help product owners and teams create new products, I have developed a new tool, the Product Canvas. The canvas has grown out of my work with product owners and product managers over the last ten years, and it’s designed to be compatible with the Business Model Canvas.

A Sample Canvas

The Product Canvas displays the key pieces of information necessary to create a new product. As its name suggests, it intends to paint a holistic picture of the product.


Figure 1: The Sample Canvas


The sample canvas above contains a brief vision statement, the product name, the personas characterising the target users and customers with their needs, epics that describe the product’s functionality, design sketches that capture the product or user interface design, user journey diagrams that illustrate how users are likely to interact with the product, and constraints that express generic operational qualities such as performance.

The canvas is designed so that the information flows from left to right starting with the target users and customers and the needs to be addressed. This puts the user at the centre of the development effort, and it ensures that you develop a product that is beneficial and desirable.

Figure 2: The flow


The journeys, epics, sketches and constraints sketch the future product, and the ready stories ensure that there are implementable items.

Learning and Emergence

The biggest challenge when developing a new product or a major update is to deal with uncertainty and lack of knowledge. We may not know, for instance, if there is enough demand or which needs should be addressed. The Product Canvas is therefore designed as a learning tool: to sketch our initial ideas and assumptions, to get stories ready for implementation, and to adapt and refine the content based on the insights gained. Figure 3 illustrates this cycle.


Figure 3: The learning cycle


Consequently, you should expect your canvas to change as you learn more about the users and customers, and how to best address their needs. Even bigger changes that involve clearing out and refilling one or more canvas sections (including the personas one) are common. These indicate that the initial product strategy was inappropriate and has to be adapted (also called pivot).

The Sections Explained

As you have probably noticed, the Product Canvas combines form and function, a structure together with specific techniques. The following diagram in Figure 4 provides an overview of how the eight canvas sections should be used, and I describe the sections in more detail below.

Figure 4: Beneath the surface of the Product Canvas


Vision states the intention or motivation behind the product. Keep the vision statement short and sweet and limit it to one or two sentences.

Product name simply states the name of the product.

Personas describe the target group using fictional users and customers including the needs to be addressed or the problem to be solved. The section therefore explains who we believe is likely to use and purchase and the product and why.

Journeys allow you to capture complex interactions of the user with the product. User journey diagrams, story boards, and story maps are great to illustrate how a user is likely to employ the product. Focus on the important interactions, concentrate on your primary persona, and don’t be shy to update or replace the diagrams, as your understanding changes and you explore new aspects of your product.

Epics are coarse-grained, big user stories that sketch the product’s functionality. Every epic must serve a persona or be required by the business model, for instance, to display online ads. You can connect the epics to the personas by using the persona names in narrative: As <persona name>, I want to <use functionality> so that <need or problem of the persona is addressed>. It’s usually not necessary to order the epics.

Don’t make the mistake of listing all product functions you can possibly think of. Rather focus on the epics that are most essential to address the user needs. Exposing product increments to users and customers will test your assumptions and ideas, and you are likely to discover new epics. The development team should size the epics if you want to track the project progress via a burndown chart.

Design sketches communicate your design ideas. The sketches should capture the critical aspects of the product or user interface design, for instance, the design of a few important screens. I prefer to work with paper sketches, as they are usually good enough to communicate the important design aspects; they are quick and easy to create; and they invite change and refinement.

Resist the temptation to create the entire design upfront. The design should evolve based on the feedback you receive, and the details are created incrementally as part of the canvas grooming work. This maximises the chances of designing a product with a great user experience.

Constraints describe the operational qualities that apply to the entire product. These include performance, interoperability, robustness, and regulatory requirements. It’s worthwhile to you pay enough attention to the constraints. They influence the user experience; they drive architecture and the technology decisions; and they impact the total cost of ownership together with the product’s life expectancy. Describe the constraints clearly to ensure testability. For instance, state for a performance constraint the type of data being transferred, the number of concurrent transactions taking place, and the system configuration used. A great technique to capture operational qualities is using constraint cards.

Ready stories are small, detailed stories that feed the next cycle. They are derived from the epics, and satisfy the sprint goal when Scrum is used. The ready stories have to be clear, feasible, and testable so that the development team can transform them into a product increment or minimal viable product (MVP).

Order the ready stories from one to n, for instance, first, second, third, and so on, to maximise the chances that your acquire the desired knowledge, and to guide the development work. The team should size the ready stories if velocity-based iteration planning is employed or if a burndown chart is used to track the project progress.

The Business Model

The Product Canvas describes the target group with the needs and the product features. But where is the value that the product should create for the organisation providing it? How can the necessary investment be justified?

While I have intentionally kept the Product Canvas focused, I have designed it to be compatible with the Alexander Osterwalder’s and Yves Pigneur’s Business Model Canvas. I recommend you use the two canvasses together, as the following picture illustrates.

Figure 5: Comparing Business Model and Product Canvasses


There is a small overlap between the two canvases, as both consider the market and the value proposition. But I don’t find this an issue: I use the Business Model Canvas to capture the market and value proposition at a high-level, and I state the details for one specific product on the Product Canvas.

If you don’t want to employ two separate canvases, you can add the relevant Business Model Canvas sections to your Product Canvas. But ensure that the resulting canvas is still easy to understand and update.

Physical vs. Electronic

I have a strong preference to work with a physical Product Canvas that is placed on the office wall. This has several advantages: It ensures that the relevant information is visible to the product owner and the team. This creates alignment and facilitates collaboration: It makes it possible to employ simple yet effective, collaborative tools such as paper cards and paper sheets. Having to work with limited wall space helps focus on the important information rather than trying to capture everything that might be relevant.

You can, of course, take picture of the Product Canvas and post it on your wiki, or replicate the canvas in an electronic tool, for instance, a spreadsheet, if you have to work in a distributed set-up. But be aware that you will lose some of the canvas’ power.


The Product Canvas brings together the key pieces of information necessary to create a new product: the users and customers with their needs, the product’s functionality and design, and the user interaction. It’s intended to be a collaborative tool that helps you state your ideas and assumptions, test them, and integrate the insights you gain.  

Roman Pichler helps his clients develop innovative and successful software products – products that customers love. He has a long track record in training and coaching individuals and teams in agile product management and Scrum, and ten years experience in helping companies embrace agile methods. Roman is the author of three books on Agile and Scrum including “Agile Product Management with Scrum” and a frequent speaker at international conferences.

This article originally appeared in JAX Magazine – New Horizons. Download that issue and others here.

Roman Pichler helps companies create great products by providing consulting, coaching and training in agile product management and Scrum. Roman has ten years experience in helping companies embrace agile methods, and a long track record in teaching and coaching product owners and product managers, business analysts, ScrumMasters, managers, and teams. He is the author of several books on Scrum including

Inline Feedbacks
View all comments