The Product Canvas is an alternative to a traditional, linear product backlog. It describes the product’s target group together with the needs addressed, paints a rough picture of the overall product, and it provides the details for the next sprint. The canvas uses scenarios, design sketches, user stories, and constraint cards.
The Product Canvas has grown out of my work with product owners and product managers over the last ten years, it is based on its predecessor, the Product Backlog Board, and it’s designed to be compatible with the Business Model Canvas.
The Product Canvas is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.
This post has been last updated on 18 March 2013.
The Product Canvas contains the key pieces of information necessary to create a new product or product update. As its name suggests, it intends to paint a holistic picture of the product. The sample canvas below shows some of the personas, epics, storyboards, constraint cards, and ready stories I created for our website relaunch project.
The sample canvas above contains a goal statement, and the product name. The first bigger section states the personas characterising the target users and customers with their needs. The next section sketches important aspects of the product using epics to describe the product’s functionality, design sketches to capture the product or user interface design, a storyboard to illustrate how users are likely to interact with the product, and constraints to express generic operational qualities such as performance. The section on the right provides a goal for the next sprint and prioritised ready stories, which are necessary to reach the goal.
The canvas is designed so that the information flows from left to right starting with the personas. This puts the user at the center of the development effort, and it ensures that you develop a product that is beneficial and desirable.
The scenarios, storyboards, epics, design sketches, and constraints describe the future product, and the ready stories ensure that there are implementable items.
The biggest challenge when developing a new product is to deal with uncertainty and lack of knowledge. We may not know, for instance, if there is enough demand for the product, or how users will interact with the product. The Product Canvas is designed as a learning tool: to sketch our initial ideas, to get enough stories ready for implementation, and to adapt and refine the content based on the insights gained. The following picture illustrates this cycle.
Consequently, you should expect that your canvas changes as you learn more about the users and customers, and how to best address their needs. It’s common to deal with bigger changes involving clearing out and refilling one or more canvas sections including the section on personas. These changes indicate that the initial product strategy was inappropriate and had to be adapted. Such a change is also called pivot.
As you have probably noticed, the Product Canvas combines form and function, a structure together with suggested techniques. The following diagram and the text below explain its five sections.
Vision states the intention or motivation behind the product. I use a brief vision statement for new products and a goal statement for product updates.
Name states the name or version of the product.
Personas describe the target group using fictional users and customers including the goals to be met and the problem to be solved. The section therefore explains who we believe is likely to use and purchase and the product and why. (I discuss personas in more detail in my post A Template for Writing Great Personas).
The Big Picture allows you to sketch your overall product. I usually start by identifying epics. 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. I like to write goal-oriented epics, and I include the persona that the epic benefits.
Don’t make the mistake of listing all product functions you can possibly think of. Rather focus on the epics that are 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.
If an epic is very uncertain or exposes a lot of risk, I tend to explore the user interaction or user journey. Scenarios, workflow diagrams, and storyboards are all great technique to capture the details of the user interaction. Choose the one you feel most comfortable with, and ensure that you make the steps of the interaction specific enough to be able to test your assumption. Don’t be shy to update or replace the diagrams, as your understanding changes and you explore new aspects of your product.
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 also 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 emerge progressively as part of the canvas grooming work. This maximises the chances of designing a product with a great user experience.
Constraint stories 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.
Unlike the epics and the design sketches, you should clearly describe the constraints upfront. For example, for a performance constraint, state the type of data being transferred, the number of concurrent transactions taking place, and the system configuration used. This facilitates the right architecture decisions, and it ensures testability A great technique to capture operational qualities are constraint stories: The qualities are written as stories, captured on paper cards, and attached to the canvas.
The Product Details provide just enough implementable items to run the next iteration. I find it helpful to work with a sprint goal that summarises the desired outcome of the iteration, for instance, to address a risk and to acquire relevant knowledge, or to complete a feature. Depending on the goal, I use different techniques to capture the implementable items. For goals that require the implementation of functionally, ready stories are very helpful.
Ready stories are small, detailed stories that feed the next cycle and that help create a product increment or minimal viable product (MVP). They are derived from the epics, and are necessary to reach the sprint goal. I use the following template to connect the ready stories to their personas: As <persona name>, I want to <use functionality> so that <need or problem is addressed>. Make sure you write acceptance criteria for your ready stories.
Order the implementable items from one to n, for instance, first, second, third, and so on, to maximise the chances that you reach your goal. The team should size the items if velocity-based iteration planning is employed or if a burndown chart is used to track the project progress.
The Product Canvas describes the target group and the product features, but not the business model including the revenue sources and the cost structure. While I have intentionally kept the canvas focussed, 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 canvases together, as the following picture illustrates.
There is some 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.
I like to work with a physical Product Canvas placed on the office wall, as this has three main benefits: First, it ensures that the relevant information is visible to the product owner and the team. Second, working with simple, yet effective tools such as paper cards and paper sheets facilitates effective collaboration. Third, having to work with limited wall space creates focus and prevents capturing everything that might be relevant.
If you require an electronic canvas, then consider using a wiki, or try Jolien Coenraets’ Google Drive template. There are also several software tools, which allow you to create a Product Canvas including the BMFiddle Product Canvas, the ProdPad, and the Canvas Model Design iPad app.
If you work with JIRA, I suggest you keep the personas and the big picture in your wiki or project management tool, and manage the product details in your JIRA board.
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. Try it out, and let me know how the canvas works for you! I’d love to learn how using the canvas has worked for you.
You can learn more about the Product Canvas by attending my Certified Scrum product Owner or my Mastering the Product Backlog training course. Please post a comment or contact me if you have a question related to the Product Canvas.