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.
RSS
[...] Product Canvas to facilitate the development of a new product. [...]
[...] a multi-dimensional backlog like my Product Canvas for new products and for product updates aimed at new [...]
[...] the product backlog board has been superseded by the Product Canvas [...]
[...] http://www.romanpichler.com (via @jackmartinleith) – Today, 12:55 PM Rescoop [...]
[...] Product Canvas aus dem Blog von Roman Pichler (Neu 23.07.12) [...]
Roman–
This is very fascinating. I look forward to reading more about your experiences with this with clients as it evolves. It’s definitely something I am going to try out as well. Thanks for sharing it.
Thank you, Mike. Glad you’ve found the post helpful. I am defintley planning to write more about the canvas in future posts. Please let me know how using the Product Canvas works for you.
Hi Roman – informative and I like the product canvas. I’ve been working on a free business model canvas tool at http://bmfiddle.com largely motivated by wanted to encourage learning and use of the canvas.
It has templates for popular canvases and a blank one to make your own.
I know you prefer a physical canvas as you mentioned in your post. However I think online can have benefits. For example with Business Model Fiddle you can snap photos on your device and email (I may work on native device image upload but for now its a cross platform web app) them to your canvas which is really useful for capturing in-field information.
Also I routinely get ideas/thoughts and add them using my iPod touch.
Currently it only supports images/photos (together with formatted text notes) but my idea is that you can create “assets” such as a persona and add those to the canvas in a similar way.
Any copyright requirements other than attribution/linking to your site if I wanted to add the product canvas as a template option?
Thanks
Hi Johan, Your canvas tool look every interesting. I’ll contact you by email to discuss how we can collaborate to provide an electronic version of my Product Canvas.
[...] capture personas on paper, so I can easily visualise them by pinning them on my Product Canvas [...]
[...] prefer to work with the Product Canvas, a structured, multi-dimensional backlog that’s put on the office wall. [...]
[...] http://www.romanpichler.com (via @storyboardingme) – Today, 2:01 AM Rescoop [...]
Roman, I really like this approach…light enough to keep moving forward but detailed enough to give good clarity as to what the group is looking to accomplish. Most important, the understanding that someone can actually define these items at a high level will give a PO and Scrum Team a gauge surrounding the “readiness” of the project to be consumed.
This approach looks to be a perfect fit for some of our needs when setting up a new project or application, and seems to be a good fit for a Sprint 0 deliverable and then subsequently refreshed and referred to as needed. Going to work with this idea in our next new endeavor and we’ll let you know how it works.
Keep it coming!
Michael Jebber
Enterprise Scrum Coach
Fidelity National Financial
Thanks for the feedback, Michael. I am looking forward to hear how the Product Canvas works for you.
[...] Model Generation – Canvas A Product Canvas for Agile Product Management The product backlog is a handy tool that lists the outstanding work necessary to develop a [...]
Roman – this is a great device. It reminds me of what I have always thought of as the most interesting part of a traditional PRD – the intro that says *why* we’re doing this product or release. PRDs are actually terrible places to manage requirements, but you do need a narrative, or narrative-like (I.e., a product canvas), to help everyone understand and maintain the vision.
Thanks, Nils. Good to hear that you find the canvas helpful.
Roman,
After reading your description of what a Product Canvas should be, I have to admit it is much more readable than the previous approach at it:
http://nearshoreamericas.com/test-blog/
While I was critical about the excessive focus given by Ci&T on technology, I think your own canvas might integrate the Strategies block. Such strategies would not be strategies about how to sell the product (to be placed on the BMC) but strategies to turn the product feasible in the first place.
Kind regards,
Alain
Hi Alain,
Thanks for your comment. You raise two important questions: What is the product strategy, and how should it be captured? In my mind, the product strategy communicates who the product is for, why anybody would want to use and purchase it, why the company should invest in it, and what the key product features are.
To sketch the strategy at a coarse-grained level, I use my product vision board: http://www.romanpichler.com/blog/agile-product-innovation/the-product-vision-board/ To detail and refine it, I employ my product canvas and Osterwalder’s and Pigneur’s business model canvas.
Does this make sense?
[...] Canvas (En este artículo lo explican muy requetebien), no deja de ser una especie de Business Plan condensado, y que a diferencia de este, no nos va a [...]
[...] for more info and references). Roman Pichler offers a very interesting tool to evaluate it (the Product Canvas), but it is not a quantitative method that would enable measurement and tracking. Finally a [...]
[...] a digital version of the Product Canvas. The canvas is a multi-dimensional product backlog that allows teams to describe the product holistically [...]
[...] A Product Canvas for Agile Product Management From http://www.romanpichler.com – Today, 10:52 AM The Product Canvas is a powerful tool that helps agile teams create innovative products. It describes the target group as personas and allows capturing the desired user experience including the user interaction and the user interface design. [...]
[...] An Agile Product-Development Framework That Complements Your Business Model Canvas: The Product Can… From http://www.romanpichler.com – Today, 9:13 PM [...]
[...] Read more about it: http://www.romanpichler.com/blog/agile-product-innovation/the-product-canvas/ [...]
[...] Let me show you how this process can be applied using my Product Canvas tool. [...]
[...] my Product Canvas uses a dedicated ready section [...]
Hallo Roman, wenn auf der Canvas auch Ziele platziert sind, dürfen sich diese über den Zeitverlauf ändern? Auch ständig? Danke für eine Meinung…
Hi Jo, I use two types of goals on the Product Canvas: the vision as the overarching goal, and the goal of the next cycle/sprint. I expect the former to stay stable. But the latter should change, as the team addresses different risks, and the team learns more about the user needs and how to meet them. Does this help?
[...] Visite o blog de Pichler para saber mais. Posts Relacionados: [...]
[...] An Agile Product-Development Framework That Complements Your Business Model Canvas: The Product Can… From http://www.romanpichler.com – Today, 12:00 PM [...]
[...] An Agile Product-Development Framework That Complements Your Business Model Canvas: The Product Can… From http://www.romanpichler.com – Today, 6:20 AM [...]
[...]My product canvas tool contains a ready section with items for the next sprint. [...]
interesting article and something I’ll look to try out on a current project we’re kicking off.
The one thing I wonder about is in relation to the Tom and Kai Gilb Evo approach here of qualities and values relating to the stakeholders is how this could be captured in such a model? It would be beneficial to be able to capture that the process (indicated by the user journey) must complete within x minutes of starting with the current measurement being y minutes say. Or capture that all manual data capture must be checked by another user. These aren’t really epics. Maybe they could go in the constraint section as these are constraints of the solution
[...] Roman Pichler – Product Canvas for Agile Product Management. [...]
Hi Victoria,
Thanks for your feedback. I’d love to hear you the canvas works on your project. You can simply attach operational qualities such as performance, robustness, and interoperability to your user journeys / interactions, or as you’ve suggested, you can capture them in the constraint section if they are generic in nature, that is, apply to the entire product rather than individual features. Does this help?
[...] The Product Canvas is a powerful tool that helps agile teams create innovative products. It describes the target group as personas and allows capturing the desired user experience including the user interaction and the user interface design. [...]
Seriously ? I don’t have such a big wall ! Do you have a real life example of such a canvas used by a team ?
Hi Sebastien, I know that getting a room set up to work effectively on a new product or bigger product update can be challenging and that wall space tends to be precious. But I have worked over the last ten years with many teams in different companies – large and small – who were able to use a wall to visualise their product backlog, Kanban board or sprint backlog. Publishing a sample product canvas from one of my clients would be great, but I am sure you understand that my clients wouldn’t be too happy if I shared new ideas for their product with the general public.
[...] The Product Canvas is a powerful tool that helps agile teams create innovative products. It describes the target group as personas and allows capturing the desired user experience including the user interaction and the user interface design. [...]
[...] relevant feedback is used to change the product backlog or product canvas [...]
Very nice Roman.
I love the simplicity and think it opens up the opportunity for a far larger group who do not have Agile/Business Model experience to develop their ideas/products.
With your approval I’ll certainly like to add it as a template to Business Model Fiddle in addition to your earlier Product Canvas which is already available.
Glad you line the new canvas structure, Johan. I’d be great to see it incorporated in your Business Model Fiddle.
Thanks for this valuable resource! I like the simplifications.
Thanks for your feedback, John!
[...] the following tutorial to explain what the product canvas is, and how it can be used effectively. [...]
[...] the Scrum team uses the newly gained insights to adapt the product canvas or backlog. This may result in big, radical or small, incremental changes depending on the sprint [...]
[...] If you employ my Product Canvas, then you should be able to use its scenarios and storyboards [...]
Hi Roman. Just came across this and liked it. Not knowing your version, I created my own Product Canvas several years ago after using the Business Model Canvas and Lean Canvas. I recently shared it on my blog: http://wp.me/pQmRk-7x and http://wp.me/pQmRk-7x. Would appreciate any feedback. Thanks!
[...] I find that a traditional product backlog can be limiting, and I prefer to use my Product Canvas [...]
Hi Shardul, Thanks for your comment. Your product canvas looks interesting. It seems to capture key product strategy and business model aspects, whereas my product canvas assumes that something like a vision board, http://bit.ly/nb2Zi8, and/or business model canvas have been created, and the focus is now on the actual product, the user interaction, the functionality, and the design. Does this make sense?
[...] product vision & the product canvas (also the business model canvas) as explained by Roman [...]
[...] A Product Canvas for Agile Product Management Mar 12 [...]
Hi Roman. I think that “Pig Picture” is a lapsus
Well spotted, thank you! Unintentionally funny mistake.
Dear Pichler,
Product Canvas looks self sufficient and exiting to work with especially to work with smaller products with few features. However, it seems to be difficult to fit the product canvas into Scrum development model. At one point, product canvas seems to be a sprint goal, while at other, product canvas seems to be describing the product backlog. Please advise your thoughts foe effectively using the product canvas with the scrum.
Thank you.
Dear SMPalli, My Product Canvas Tutorial should help you understand better how you can apply the tool.
Dear Pichler,
I did go through the Product Canvas Tutorial. And I still think a piece of information is missing in the Product Canvas. It is not capturing the implemented stories from the previous sprint. There are two option: divide the Ready Stories area into two: upper one captures the completed (successfully implemented) stories and the lower one Ready Stories for the next Sprint. I think this is useful from the backlog management perspective, unless the Product Canvas just represent the current Sprint.
Please advise if I am missing something. Thank you.
Dear SMPalli, Thanks for your question. The Product Canvas follows the backlog convention of removing “done” items. They are therefore no longer available on the canvas. If you have to document which items have been implemented, I suggest you take, for instance, pictures of the canvas at the end of each sprint, or use an end of sprint report to record what was done.
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?
[...] Nutzen bei gleichzeitig geringem Aufwand.Wie wir mit dem Project Canvas arbeitenAngeregt durch den Blogpost von Roman Pichler über das Product Canvas haben wir geschaut, wie wir ein solches Canvas auch für unsere Projektarbeit nutzen können. [...]
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.
[...] The canvas allows me to work with personas, epics, scenarios and storyboards [...]
[...] http://www.romanpichler.com/blog/agile-product-innovation/the-product-canvas/ [...]
[...] tools and methods < meryengland Get flash to fully experience Pearltrees A Product Canvas for Agile Product Management The Product Canvas is an alternative to a traditional, linear product backlog. It describes the [...]
[...] Pichler, in is post originally written in Jul, 16 2012 – http://www.romanpichler.com/blog/agile-product-innovation/the-product-canvas , has proposed a really interesting approach: use canvas to create and share product vision and [...]
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