Tag Archives: product definition


When I talk to product owners about capturing ideas and requirements for their products, the conversation often focuses on users stories. While stories are great to describe the product functionality, they are not enough to create a great user experience.

Creating a Great User Experience

I like to think of a product description as a four-piece jigsaw puzzle: One piece describes the functionality, another one the user journeys and interactions. There is a third piece that captures the visual design, and a final piece for the nonfunctional properties such as performance. All four pieces have to be present and fit together to create a product with a great user experience, as the following picture illustrates:


The four pieces are best covered by different techniques: User stories work well for the product functionality. Scenarios, workflows, and storyboards are great to describe the journeys. Sketches and mock-ups capture the design, and constraint stories describe the nonfunctional properties, as shown in the picture below. No single technique can handle all four pieces well.


You can employ further techniques, of course, including screenshots and photos, context and activity diagrams, value stream maps, story maps, and so fourth. You can also combine different techniques, for instance, providing a design sketch for each step in a scenario. Use the techniques that work best for your product, and that enable you to describe your ideas so that they are easy to understand and to validate.

(Note that I have placed storyboards between “User Journeys” and “Visual Design” in the picture above as the technique can cover both aspects.)

Identifying Assumptions and Risks

There is another reason why a holistic product description is beneficial especially for new products and new features: It helps you identify all relevant assumptions and risks. If you only write user stories, chances are that you are unaware of the interaction and design risks. This may result in late failure or a poor user experience.

For instance, every now and then when I shop online, I come across a website that asks me to select the payment type before allowing me to enter the payment details on the next page. Unfortunately, I typically forget to make the right choice in the first step. As a consequence, I have to go back to the initial page to correct my selection and then move on to the details page. As my payments details are lost, I have to re-enter them. While this experience may be good to test my patience, it certainly does not make me want to use the website again. Considering and validating the user interaction could have easily resulted in a better design and in a more pleasant user experience.

Visualising and Managing the Four Aspects

A handy tool to capture and manage the four aspects is the Product Canvas. The canvas provides three major sections: The first section is called “Target Group” and describes the users and customers with their needs in form of personas. The second section named “Big Picture” outlines the desired user experience and describes the important user journeys, product capabilities, design ideas, and nonfunctional properties. The third section called “Product Details” captures the goal or hypothesis of the next cycle together with actionable items, which may be written as ready stories.

The Big Picture section plays a key role in capturing the four pieces, as the following sample canvas shows:


The picture above is an extract of the Product Canvas I used to create the current version of my website, romanpichler.com. The Big Picture section in the middle contains epics to describe the product functionality, storyboards to capture the user interactions, design sketches to illustrate important design ideas, and a performance constraint. It provides a coarse-grained but holistic description of the product. For more information on the canvas, please visit the Product Canvas tool page, which also provides downloadable template.


When you create a new product, take a holistically holistic approach. Describe the relevant user journeys, the product functionality, the visual design, and the nonfunctional properties. Neglecting one of them is likely to result in a suboptimal user experience, which may well have a negative impact on the success of your product.

You can learn more about the approach and techniques described in this post by attending my Certified Scrum Product Owner and my Product Canvas training course.

Product Canvas Creation Workshop Overview

The Product Canvas is a simple, yet powerful tool that helps you create a product with a great user experience and the right features. This post explains how you can create your initial canvas using a collaborative workshop.

Note that many of the recommendations below also apply to other agile and lean product definition tools including a traditional product backlog.


The Product Canvas creation workshop wants to kick-start your solution validation and product definition activities. It helps you change the focus from problem validation – exploring if there is a need that the new product addresses – to building a product with the right features and the right user experience. The following picture summarises the workshop, and the rest of this post explains the details.


Everyone tasked with creating the product should attend the canvas creation workshop: the product owner, the team developing and testing the product, and the ScrumMaster or coach. This creates shared ownership, and it is likely to result in better decisions, as the entire team’s creativity and knowledge are leveraged.

I generally recommend that the stakeholders – the users, and customers as well as the internal stakeholders – do not attend the workshop, but share their ideas and feedback based on prototypes and product increments, for instance, in the sprint review meetings. This allows the product owner and the team to be creative before the stakeholders provide input.


Before you start the workshop, you should be able to confidently answer the following questions:

  1. Who are the product’s users and who are the customers?
  2. What problem does the product solve? What benefits does it generate for its users? What is the product’s value proposition?
  3. What business benefits does the product creates? Why should the company invest in it?
  4. What kind of product is it? What are the three to five features that make it stand out?

I like to capture the insights above using the Vision Board. But you can also employ other tools including Ash Maurya’s Lean Canvas and Alexander Osterwalder’s Business Model Canvas, as the following picture shows:

Being able to answer the questions above means that some problem validation has taken place prior to the workshop, for instance, by carrying out user observations and problem interviews. Note that the strength of the Product Canvas is solution validation – building the right product – and not discovering if the product should be built in the first place!

To ensure a smooth workshop, use a facilitator, for instance, the ScrumMaster. Organise an appropriate room with lots of wall space. Have the necessary materials available including paper sheets, paper cards, adhesive notes, masking tape, markers, and pencils. Starting out with paper and pencil is effective and fun in my experience, even if you intend to use a digital canvas.

Steps to Create the Canvas

To create your initial Product Canvas take the following three steps: Create personas; outline the user experience and the features; determine what to do in the first sprint, as the picture below shows:

The first step creates personas based on the insights gained in your problem validation work. The personas allow you to connect with the target users and customers. Their needs enable you to discover the right product features. I also recommend using a primary persona, as it creates focus and facilitates decision-making. You can read more about personas in the post  “A Template for Writing Great Personas”.

The second step describes the product comprehensively but at a rough, coarse-grained level. Helpful techniques to capture the user experience and the product functionality include scenarios, storyboards, epics, constraint stories, and design sketches / mock-ups. Make sure that the product features you identify address the need of a persona, or support the business model.

The third step determines what should be done in the first sprint. As you are about to start building the first product increment, you should address the greatest risk or the biggest uncertainty. This could be a lack of knowledge surrounding the user interaction, the user interface design, a product feature, or the architecture and technology. See my post “Effective Sprint Goals” for more information on choosing the right goal or hypothesis. Finally, determine what needs to be done to reach the goal, or to test the hypothesis, for instance, creating a scenario and a paper prototype to learn more about the user interaction.

The three steps above form a breadth-first approach: The product is sketched holistically, but the details are determined on a sprint-by-sprint basis. This keeps your canvas concise, and allows you to make changes quickly and effectively.


At the end of the workshop you should have a Product Canvas that is good enough to start sprinting: to start building product increments/MVPs, gathering feedback, and integrating the insights gained, as the following picture shows:

Make sure you create a good-enough canvas, but not a perfect one. Your Product Canvas will change and evolve anyway based on the feedback you receive!


Four to eight hours should be enough time to create your initial canvas. If you require more time, then this may be a sign that you haven’t got enough information available and may have to carry out more problem validation and market research.


Employing a collaborative workshop, and following the process described above creates an initial Product Canvas that allows you to focus on solution validation – building the product with the right user experience and features. Make sure you understand the product’s value proposition before you enter the workshop, describe the product holistically at a coarse-grained level, and don’t worry too much about the product details: These will emerge incrementally based on the feedback you gather.

You can learn more about the Product Canvas creation workshop by attending my Certified Scrum Product Owner training course. If you would like me to help you run a Product Canvas workshop, then please contact me.

User stories are great at capturing product functionality from the perspective of a user or customer: Each user story describes a piece of product functionality, for instance, “As an application provider, I want to register with the application centre so that I can use its services.” By focusing on a distinct area of functionality, the story allows the team to understand, implement, and test the requirement. This strength is also a weakness: User stories are not well suited to express the relationships between different features and to describe workflows.

To show how different stories fit together, I have found it useful to complement user stories with lightweight models, originally invented for use cases: context and activity diagrams. I also add important diagrams to the product backlog, as I explain in my post The Product Backlog Board.

Context Diagram with Epics

A context diagram that depicts user roles and epics, large and coarse-grained stories, is great to provide an overview of the product’s functionality. Let’s have a look at an example, a diagram that sketches an online application store called “Application Centre”:

The diagram above depicts three user roles: provider, user and administrator. It shows how the roles interact with epics that describe Application Centre functionality. It tells us, for instance, that the user and the administrator both review applications – to enable end user and staff ratings.

Note that the diagram does not list all epics contained in the product backlog, and it does not state all user roles. It rather focuses on the product backlog items relevant for a conversation between the product owner and the team, or the Scrum team and the stakeholders. This results in a diagram that is simple and easy to understand rather than complex and overwhelming.

Activity Diagram with Stories

To get a job done, users often carry out several steps and interact with different pieces of functionality. Activity diagrams are great at capturing sequences and workflows by connecting individual user stories. They also support the creation of complex test scenarios that go beyond a single story.

Let’s have a look at an example, a diagram that elaborates the epic “Register” on the context diagram above. It shows the key steps required for a user to register with the Application Centre:

The diagram above visualises the steps of the registration workflow by connecting three individual stories. It starts with stating the details of the provider company, continues with entering a user name and password, and if successful, accepting the usage terms and conditions.

User Story Modelling Tips

User stories modelling is a handy tool in the product owner’s toolbox. But like any tool, it wants to be applied properly. The following tips help you create great diagrams:

  1. Model collaboratively: User story modelling serves to create a shared understanding of the desired product functionality. Use context and activity diagrams to capture the essence of a conversation, not to replace it! Create and update your diagrams collaboratively involving the team and as appropriate, the stakeholders.
  2. Focus: Apply modelling selectively and only describe relevant aspects. Focus on the relevant product backlog items and leave out the rest. Don’t include too much information or unnecessary details.
  3. Keep it simple: Keep your diagrams simple and easy to understand. Rather use additional diagrams to illustrate further aspects than cluttering a model with too much information. Complex diagrams are usually not helpful.
  4. Use whiteboards and flip charts rather than electronic tools. Simple, physical tools encourage participation and collaboration. They avoid the impression of perfection and completion.


Collaborative, lightweight and focussed user story modelling can help you create a shared understanding of the desired product functionality. Context and activity diagrams complement user stories, put them in a context and connect individual epics and stories. Any model related to user stories and epics should be the outcome of a conversation – and never replace it.


1 Start with the Users

As its name suggests, a user story describes how a customer or a user employs the product. You should therefore tell the stories from the user’s perspective. What’s more, user stories are particularly helpful to capture a specific piece of functionality such as searching for a product or making a booking, as the following picture illustrates.  UserStoryOverview

2 Use Personas to Discover the Right Stories

A great way to capture your insights about the users and customers is to use personas. But there is more to it: The persona goals help you discover your stories. Simply ask yourself: What functionality does the product have to provide to meet the goal of the personas? You can download a handy persona template for free from romanpichler.com/tools/persona-template and you can learn more about this technique in my post From Personas to User Stories.


3 Write Stories Collaboratively

A user story is not a specification, but an communication and collaboration tool. Stories should never be handed off to the development team. They should rather be part of a conversation: The product owner and the team should discuss the stories, or even better, write them together. This leverages the creativity and the knowledge of the team and usually results in better user stories.


4 Keep your Stories Simple and Concise

Write your stories so that they are easy to understand. Keep them simple and concise. Avoid confusing and ambiguous terms, and use active voice. Focus on what’s important, and leave out non-essential information. The following template puts the user or customer modelled as a persona into the story and makes its benefit explicit. Use the template when it is helpful, but don’t feel obliged to apply it. Experiment with different ways to write your stories to understand what works best for you and your team. StoryTemplate

5 Start with Epics

Epics are big, coarse-grained user stories. Starting with epics allows you to sketch the product functionality without committing to the details. This is particularly helpful for new products and new features: It allows you to capture the rough scope, and it buys you time to learn more about the users and how to best meet their needs. It also reduces the time and effort required to integrate new insights. If you have lots of detailed stories, then it’s often tricky and time-consuming to relate any feedback to the right stories.

6 Decompose your Stories until they are Ready

Break your epics into smaller, detailed stories until they are ready: clear, feasible, and testable. Everyone should have a shared understanding of the story’s meaning; the story should not too big, and there has to be an effective way to determine if the story is done. EpicVsReadyStory

7 Add Acceptance Criteria

As you decompose epics into smaller stories, remember to add acceptance criteria. Acceptance criteria complement the story’s narrative: They allow you to describe the conditions that have to be fulfilled so that the story is done. The criteria enrich the story and make it more precise and testable, and they ensures that the story can be demoed or released to the users and the other stakeholders. As a rule of thumb, I like to use three to five criteria for detailed stories.

8 Use Paper Cards

Paper cards are not only cheap and easy to use. They facilitate collaboration: Every one can take a card and jot down an idea. Cards can also be easily grouped on the table or wall to check for consistency and completeness and to visualise dependencies. Even if your stories are stored electronically, it is worthwhile to use paper cards when you write new stories.

9 Keep your Stories Visible and Accessible

Stories want to communication information. Don’t hide them on a network drive, the corporate intranet jungle, or a licensed tool. Make them visible instead, for instance, by putting them up on the wall. A great tool to discover, visualise, and manage your stories is my Product Canvas. SampleProductCanvas

10 Don’t Solely Rely on User Stories

Creating a great user experience (UX) requires more than writing user stories. Also consider the user journeys and interactions, the visual design, and the nonfunctional properties of your product. This results in a holistic description that makes it easier to identify risks and assumptions, and it increases the chances of creating a product with the right user experience.

Learn More

Learn how to write great user stories by attending my Writing Great User Stories Workshop. Please contact me for onsite delivery of the workshop.

[This post was last updated on 28 May 2014.]

User stories and use cases are powerful techniques to capture requirements. Even though Scrum is agnostic about how requirements are described, user stories are becoming the standard way to express functional requirements on the product backlog. Before I explain why, let’s briefly reflect on what user stories and use cases have in common.

Both techniques put the customer or user at the center of the development effort. Use cases describe how a customer interacts with the product using one or more scenarios. A use case may consist of a short narrative or of several structured scenarios including main success scenario, alternative scenarios and failure scenarios. User stories describe how a customer or user employs the product. Stories consist of a name, a brief narrative (the story) and a set of acceptance criteria. The latter formulate conditions that must hold true thereby making the story more precise. Uses cases and user stories employ customer roles known as primary actors and user roles respectively. Both techniques can be applied at different levels of granularity: Use cases may be written as business or system level use cases. User stories may be formulated as epics, coarse-grained or detailed stories.

User stories are particularly popular on the product backlog for two main reasons: First, applying the technique is easy (but writing good stories can be hard). There are no complicated templates, no pre and post conditions, no triggers and exceptions to be specified. Since the barrier for writing stories is low, it’s easy to do it together involving the entire Scrum team. Second, decomposing stories is comparatively easy; large stories or epics are broken into smaller, more detailed ones over time to ensure that they can be delivered within a sprint according to the definition of done. Having worked with both user stories and uses cases in Scrum, I do prefer stories over use cases on the product backlog.

If you like to work with business use cases to create the product vision, then derive user stories from your use cases by splitting each use case scenario into one or more stories. The stories are then used to stock the product backlog. And don’t feel obliged to describe every single product backlog item as a user story. User experience requirements, for instance, are best captured using different techniques such as user sketches, storyboards, user interface navigation diagrams, and prototypes. These artifacts complement and elaborate the stories on the product backlog.

You can learn more about stories on the product backlog in my book Agile Product Management with Scrum or by attending one of my upcoming product owner classes.

Agile product management has been en vogue for quite some time. But a clear definition of the term is lacking. Different people associate different meanings with it – from simply using the product backlog to extending Scrum by employing complex new frameworks. I view agile product management as fundamentally different from traditional approaches. To better understand the differences, let’s see how agile and old-school product management compare. The following table – taken from my book Agile Product Management with Scrum – summarizes five key changes.

Old School New School
Several roles, such as product marketer, product manager, and project manager, share the responsibility for bringing the product to life. One person—the product owner—is in charge of the product and leads the project.
Product managers are detached from the development teams, separated by process, department, and facility boundaries. The product owner is a member of the Scrum team and works closely with the ScrumMaster and team on an ongoing basis.
Extensive market research, product planning, and business analysis are carried out up front. Minimum up-front work is expended to create a vision that describes what the product will roughly look like and do.
Up-front product discovery and definition: requirements are detailed and frozen early on. Product discovery is an ongoing process; requirements emerge. There is no definition phase and no market or product requirements specification. The product backlog evolves based on customer and user feedback.
Customer feedback is received late, in market testing and after product launch. Early and frequent releases together with sprint review meetings generate valuable customer and user feedback that helps create a product customers love.

Agile methods embrace an age-old truth: They see change as the only constant. If flux and unpredictability are dominant forces, then our ability to accurately forecast markets and predict customer behavior is limited. Instead of employing a primarily analytical approach with big upfront market research and business analysis and detailed, frozen requirements, agile product management follows an empirical approach: Gathering customer and user feedback on prototypes and early product increments facilitates inspecting the work results and adapting the product accordingly. The product evolves based on customer and user feedback. This not only saves time and money but it increases the likelihood of developing a great product.