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


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


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

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

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

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
comments powered by Disqus