The best way to understand the Product Canvas is to look at an example. Imagine that we want to develop a game that helps children learn about music and dancing. A canvas for such a game could look like the one below.
The sample Product Canvas above contains the product name, the product (or release) goal and the metrics to measure if the goal has been met. The first bigger section states two 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, a mock-up to capture the user interface design, a storyboard to illustrate the user interaction, and a constraint card to express the platform for which the game is developed. The section on the right provides a goal for the next sprint and the details necessary to reach the goal.
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 the sections of the canvas. You can download the canvas template for free from romanpichler.com/tools/product-canvas or by simply clicking on the picture below.
Name simply states the name or version of the product.
The Goal is the product or release goal, the objective that should be met, for instance, to acquire, activate or retain users. If you use the GO product roadmap than you can simply copy the relevant goal stated on the roadmap.
The Metrics provides the measure to determine if the goal has been met, for instance, number of downloads or daily active sessions. If you use the GO product roadmap than just copy the relevant roadmap metrics.
The Target Group describes the target customers and users as personas. The section explains who we believe is likely to use buy and use the product and why. I discuss personas in more detail in my post A Template for Writing Great Personas. Choose one primary persona – the persona you mainly create the product for. Employing a primary persona helps you make the right prioritisation decisions and create a product with a great user experience. Your primary persona should be at the top of the building block to signal its importance.
The Big Picture describes what is takes to meet the persona goals. It captures the user journeys, and the visual design required to create the desired user experience. As its name suggests, it wants to describe your product holistically at a high-level. The section is similar to the outline of a book: It captures the contents without discussing the details.
Scenarios, storyboards, workflow diagrams, and story maps are great techniques to describe the user journeys on the Big Picture. Each journey shows how a persona interacts with the product and the steps the individual has to take to meet a goal. The product functionality on the Big Picture is best captured as epics, which are big and coarse-grained user stories. Epics allow you to describe your ideas without having to commit to the details. This saves time, and it makes it easier to update the canvas with new insights. Constraint stories help you capture the nonfunctional requirements that impact the user experience and the software architecture. You can capture your visual design ideas on the Product Canvas as design sketches, mock-ups, screen-shots, and photos. The Big Picture design artefacts should focus on the critical design aspects of your product—for instance, the design of selected screens or pages.
None of these techniques are mandatory, of course. They rather provide you with a starting point. Choose those techniques that are appropriate for your product. Use additional ones as it suites your needs.
The Product Details provide a goal for the next iteration and just enough implementable items to reach the goal, 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 coding, ready stories are very helpful. These 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. 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 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. I explain in more detail how you can create you canvas in my post “The Product Canvas Creation Workshop“.
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.
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. You can use the two canvases together, as the following picture illustrates.
As the picture above suggests, I use the Business Model Canvas to capture the market and value proposition at a high-level, and I state the details for a 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. To create your own paper-based canvas, download and print out my free Product Canvas template.
If you require an electronic canvas, try the Canvas Model Design iPad app, or simply re-create the canvas in your favourite electronic tool. When working with Jira, I suggest that you keep the personas and the big picture in Confluence, and manage the product details in your Jira board.
OKRs—objectives and key results—are a popular goal-setting technique. But can and should you use OKRs…
For any business to succeed, it is crucial to make the right strategic choices. To…
Being empowered can make all the difference in doing a great job. Sadly, not all…
Products often don’t exist in isolation. Instead, they are part of a product portfolio. Think…
Product discovery has become increasingly popular in recent years as a way to determine the…
Strong product leadership is crucial to offering successful products and enabling product-led growth. Unfortunately, there…
View Comments
Hi Roman,
Love the simplicity of the Product Canvas. I was wondering where you specify Key Value Indicators can this be under the business goals?
Hi Corinne,
Thank you for your feedback and comment. I use another canvas, the Product Vision Board, to determine the user/customer needs and business goals. Based on those I select the appropriate key performance indicators (KPIs). I look at my Product Canvas as an alternative to a traditional product backlog, rather than a strategic planning document.
I therefore first create the product vision and strategy, derive the product roadmap from the validated strategy, and then populate the Product Canvas using the appropriate roadmap goal and features. The metrics on the canvas are hence related to a specific product goal like acquisition, retention, or conversion.
Does this help?
Hi Roman,
I'm thinking about using the Product Canvas for capturing an organisation's vision for a new reporting environment. We intend to conduct two workshops, one focusing on business needs, one dealing with more technical aspects as the organisation is rolling out a new it-infrastructure. At least I have two questions: first, do you think it may be useful to use two seperate Product Canvas (one for business needs, one with technical focus), or might it be more helpful to build the "Business" Canvas first and take this result in order to enhance it in the technical workshop? And second: as these workshops should focus on the vision, what would be your recommendation for gathering Product Details, keeping in mind that first steps for implementation will be initiated three months after visioning at the earliest?
Thanks in advance and best regards
Juergen
Hi Juergen,
Thank you for your question. I've designed my Product Canvas as an alternative to a traditional product backlog. It is therefore intended to describe the functionality of a new product or a new product version together with the user interaction, UI-design, and non-functional requirements.
If you want to describe the business needs and value proposition of your product, I recommend using my Product Vision Board.
The following articles explain how the Product Vision Board and Product Canvas/product backlog relate:
Leading Through Shared Goals
Choosing the Right Planning Horizon for Your Product
Hope this helps!
Hi Roman,
very good explanation of the product canvas - that helps a lot.
You state that the product details section should contain the ready stories for the next iteration (i.e. sprint) but at the same time the product canvas should focus on a release (that's why it connects to the GO roadmap). When a release consists of several sprints, should the details section then contain all the stories planned to fulfill the release goals or should it be like kind of one product canvas per sprint?
Best regards from Germany,
Nicolas
Thanks for your feedback Nicolas. I recommend that you populate the details section just in time and create new detailed stories only for the next sprint--particularly when your product is young or experiences a bigger change. This makes it easier to incorporate the insights you derive from the user feedback and data you gather. Hope this helps!
Dear Mr. Roman Pichler,
I have one question which I hope you can help me with. At the beginning of this post, there is an image of a canvas on what appears to be a wooden table. I enlisted the help of a close associate, and we can't for the life of us determine if it is a photograph or a painting. Our inspection of the image provided no clue either way, and we were wondering if you have any insight on the matter. Thank you.
It's definitely a photograph. The photographer Tamarcus Brown, and the image is published on Unsplash. Hope this helps!
Hi Roman,
Following the hierarchy for items epics -> user stories, it's ok. But what if my hierarchy is epics -> Features-> user stories -> tasks. How to present the product canvas?
Thanks for your comment. I recommend list your "features" underneath the epic they belong to so that the big picture section on the canvas does not become too complex. Features are then decomposed into user stores. (I view features as product capabilities such as "search and navigation" or "reporting" rather than larger user stories btw.)
Does this help?
Then must i put the features glued above the epics (together)?
No, you don't. But it may make your canvas easier to understand. To see how you can visualise a hierarchy between functional requirements, take a look at the predecessor of the Product Canvas, the Product Backlog Board: https://www.romanpichler.com/blog/product-backlog-board/
Hummm.....:D!
Got IT, I'll do an illustration of a product canvas and put here to see you.
Hi Roman, is there ever a situation when you would used more than one product canvas for a single product?
For instance if the target group had quite different needs.
Thanks
Hi Dave, Thanks for your comment. Great question! If you can identify groups with different needs, then you should consider creating a product line. You could keep your current product and introduce a new one that addresses the needs of one of the groups, for instance, like the iPhone 5C or Coke Zero, or you could spilt your current product into two more specialised ones.
If you decide to offer more than one products, then you should create a canvas for each product. You may want to use my Product Vision Board to capture the market, the value proposition, and the business goals of your product(s) at at high level: https://www.romanpichler.com/tools/vision-board/
Does this help?
Hey Roman,
I just drop in this post looking one way to approach UX in our product. I am looking for finding more info to talk with one of PO I am coaching.
So far, I will point him and the team here and see what we could do in our team.
Very useful post.
Thanks,
Omar
Thanks for your feedback, Omar.
Hi Roman,
your work has inspired me and I've used with success bot Product Vision and Product Canvas. I think that this tools is really useful and therefore I've published a post about my experience and a step-by-step demo.
http://isolasoftware.it/2013/05/18/product-canvas-step-by-step/
If you have time to send a feedback to improve the presentation I really appreciate it.
Thanks for sharing!
Giulio
Hi Roman, I agree - especially for smaller projects themes or epics are absolutely sufficient. Here is a blog post I wrote (unfortunately only in German) that describes how we apply the canvas idea to the context of projects:
http://blog.sybit.de/2013/04/project-canvas-ziel-und-rahmen-fuer-ihr-projekt/
Hi Thomas, Great post! Thanks for sharing how you apply the Product Canvas.
Hi Roman,
thanks for your this great idea! We often use a Product Canvas in stakeholder workshops in combination with a Story Map. Using these two techniques together enables us to create a shared view on the new product version very fast and easily.
Cheers, Thomas
Hi Thomas, Thanks for your feedback. I am glad to hear that you find the canvas helpful. For some products, I use story maps / storyboards / workflow diagrams quite extensively; for others, themes and epics are sufficient. Does this match your experience?