Why Empathy Matters

Possibly the most profound challenge in product management is to understand the needs of users and customers. Without developing the right understanding, our chances of creating a successful product are slim.

While there are numerous techniques available to uncover user needs—think of direct observation, problem interviews, focus groups, surveys, and MVPs, to name just a few—none of them is truly useful, if we do not empathise with the people that will use our product, if we do take a genuine interest in the individuals, and want to help them.

Otherwise, we run the risk of pushing out feature after feature, MVP after MVP, without ever knowing why some features or products stick and others don’t. In the worst case, we build digital products that are harmful and encourage addictive behaviour, as we don’t see the humans behind the analytics data and financial numbers.

Empathy in a Nutshell

Empathy is our capacity to relate to each other on a very fundamental level: to understand other people’s feelings and to take the perspective of the other person. Say a friend tells you how sad she is after splitting up with her partner. Your natural reaction will be to feel sad for her, to mirror her feelings. Or another friend shares with you how happy he is after finding a new job. You are then bound to feel happy for him. The best explanation of empathy I have found is the one below. 

While it is in our nature to empathise, there are some conditions that increase our ability to be empathic, while others decrease it. The following tips want to help you empathise with users and develop a deeper understanding of their needs.

Empathy Tip 1: Meet Users Face to Face

Meeting real users on a regular basis should be part of every product person’s job. Unfortunately, that’s not always the case. As product people, we are sometimes shielded from the users by management, sales, or support.

But without meeting the beneficiaries of your product, you cannot truly understand their feelings and needs. In the worst case, you create an ineffective empathy map or persona based on hearsay and half-knowledge, but not on personal experience and insight—which is a common mistake in my experience. And while it’s great to have analytics and quantitative data available, I for my part find it impossible to empathise with numbers.

Therefore, make sure that you meet users face to face and preferably in person, at least once every three months. While a video call call might work, I wouldn’t recommend it if you haven’t met the individual before, as it’s harder to empathise with the person if you are not in the same room.

Empathy Tip 2: Take a Genuine Interest in the Person

Understanding another person requires a friendly, kind, and open attitude. Be respectfully curious about the individual’s thoughts and feelings, no matter if you find the person likeable or not. Now, that’s easier said than done for me, as I can be critical about others and myself. But I know that having the courage to openly engage with a “difficult person“—someone I find challenging to relate to—helps me see the individual for what she or he is: a fellow human being with hopes and dreams, worries and fears just like me.

Additionally, appreciate the opportunity to meet users, and be careful not to view the meeting as a tick-box exercise, as this might instrumentalise the other person: You might be more interested in collecting the right information as quickly and efficiently as possible rather than engaging with the individual. But such an approach significantly reduces your ability to empathise and consequently collect the missing information.

At the same time, be kind to yourself. Recognise that being worried, stressed, tense, tired, or restless will make it harder to be empathic. If you are not reasonably content, then it’s difficult to reach out and connect with others, as you are likely to be caught up in your own thoughts, emotions, and concerns.

Similarly, if you are primarily concerned about your own success, if you are mainly motivated by meeting a business goal or improving a product KPI, then this is likely to get in the way of developing empathy. While every product has to provide a business benefit, you should try to let go of your own and your company’s ambition to understand the person in front of you. Remember that only when a product addresses a real user need, will it be possible to achieve the desired business benefits.

Empathy Tip 3: Cultivate Open Mind and Stay Present

Most of us are so used to evaluating, analysing, and judging other people’s views, emotions, looks, attitudes, and behaviour that we are hardly aware of it. Unfortunately, a judgemental, critical mind is an empathy barrier. Let’s look at an example.

John, one of the users you are meeting, tells you that the latest update is rubbish. But your data suggests that the majority of users think the opposite. It’s easy then to become defensive and label John’s view as an outlier. While this might be correct, it is a judgement. Thinking that the person’s opinion is non-representative or wrong is likely to prevent you from understanding John’s reason for preferring the old product version and possibly enhancing the latest one.

Alternatively, you might find that John’s feedback triggers a thought process. Your mind wanders and you evaluate how you could fix the issue. You might start identifying improvements for the product, possibly even redesign the user experience, while you are still sat in front of John.

If your mind is critical or not focused on the present, then you lose some of the connection with the other person; you are likely to empathise and understand less. What helps me is being mindful, paying attention to what’s happening inside me, how I respond to what I see and hear, and catch myself before I get lost in my own thoughts and feelings.

Empathy Tip 4: Ask Clarifying Questions to Deepen Your Understanding

John’s feedback clearly tells us that he does not like the latest product update. But why is that? Why is he unhappy with the product? To deepen your understanding, ask open, clarifying questions.

For example, you might want to say to John: “It seems to me that you are disappointed with the latest update. Can you please share why that is?” This should move on the conversation to uncovering the reason for John’s negative feedback, which is likely to be an unmet need. This in turn may lead to the opportunity to innovate.

Give John the necessary time to answer your question. Tolerate silence and don’t jump in with suggestions (“it’s probably because you wanted …”). Allow yourself to be patient; developing empathy can take time.

Empathy Tip 5: Eat Your Own Dog Food

Using your own product will also help you empathise with the users: You are likely to experience the shortcomings virtually every product has. This allows you to better understand the negative feelings and actions that the product might trigger, for example, users becoming impatient or frustrated and consequently not completing a user journey or possibly stopping to use the product.

While you may want to ensure that your product does a great job for all its users, be aware that you cannot please everyone. Empathy, therefore, may require saying no so that your product continues to have a clear value proposition and addresses a specific problem for a particular group of people.

Maximising Value

I often get asked how much product owners and product manager should know about user experience (UX) design and who should do the UX work on an agile team. To answer this question, let’s reflect on what product people re responsible: to ensure that your product creates the desired value for the users and for the business. Your job is not to design a great user experience. Does this mean that product owners and product managers should not care about the user experience? Of course not!

Many digital products must provide a great user experience to achieve product success. Take for example Monument Valley, a beautifully designed computer game. If the user interaction, the graphics, the animations, and the music of the game were not right, then it would not be enjoyable to play it. As a consequence, not many people would make in-app purchases, and the product would not generate enough revenue for Ustwo, the company that develops the game. For some products, creating a great user experience is the main differentiator, the quality that sets it apart from the competition and that helps it become a success.

Designing the User Experience

If the user experience design is important but if it’s not a core responsibility of the person in charge of the product, whose job is it? I prefer having one or more qualified user experience designers on the team, the cross-functional team that designs, builds, and tests the product. In a Scrum context, that’s the development team in the picture below.

As the picture above shows, I view it as the job of the development team to offer design and technology leadership and to own the user experience design.

As the person in charge of the product, you should know enough about the users so that you can guide the development team and explain who the product is for, why people (would) buy and use it, what makes it stand out, and what the desired business benefits are. A great way to do this is to create personas including a primary persona.

Collaboration

While it’s great to explain the users’ characteristics and goals to the development team, it’s even better to involve the development team members in carry out the product discovery and user research work out. I have therefore placed the user research work between the product owner and the development team in the picture above.

This allows you to benefit from the individuals’ experience–UX designers are great partners to determine the right user research techniques and carry out the research work–and it allows the team members to acquire firsthand knowledge about the users and empathise with them. This, in turn, makes it more likely that the dev team can create a product with a great user experience.

1. Get to Know the Users

Any persona description should be based on knowledge gained from direct interaction with the target customers and users. This is necessary to build a connection with the beneficiaries of your product, develop empathy, and understand their current wants, needs, and circumstances.

Before you create your personas, you should therefore get to know your audience, for example, by observing how they currently get a job done and by interviewing them. Otherwise, your characters may not accurately represent your target group. In the worst case, they are based on ideas and speculation, not real people. Involve (some of) the team members in the user research work, including UX people and developers. This allows you to leverage their knowledge, and it establishes a shared understanding of the users and their goals.

Put aside any ideas about the desired user experience and the product features when you develop your personas. Describe the characters according to your market insights. Do not make them fit your ideas and assumptions!

2. Keep your Personas Concise

While every persona description should help the team members understand who the beneficiaries of the product are and what the goals they pursue, I recommend that you make and keep your personas concise so they fit on an A4 sheet of paper.

Be careful not to bloat them and don’t add irrelevant details, for instance, another spare time activity or a cute pet. While your personas have to contain enough information to be usable, too much detail makes them difficult to work with. Only include information that helps you make informed decisions about the user interactions, the visual design, and the product functionality. Leave out the rest.

My simple, minimalist persona template wants to help you write concise personas. You can download the template by clicking on the picture below.

3. Distinguish User and Buyer Personas

Create separate user and customer personas whenever the users and the customers are not the same people. This allows you to capture the user and the customer-specific needs, and it makes divergent or conflicting goals easier to see.

Say we want to develop a new, advanced X-Wing Fighter, admittedly a highly implausible but fun scenario. The Rebel Alliance pilots would want a plane that’s easy to fly and well protected. But the purchase department of the Alliance is likely to be concerned with its price and maintenance cost. Employing two different personas allows you to model the user and the buyer, and to state their different goals.

4. Choose a Primary Persona

Whenever you create several personas for a product, choose one primary persona. The primary persona is the character you mainly design and build the product for. Say we choose Luke, a pilot, as the primary persona in the X-Wing Fighter example above. Then meeting Luke’s goal—creating a plane that’s easy to fly and well protected—becomes our top priority. But if we choose John, a purchase team member, as the primary persona, then the resulting product would be very different.

If you find it difficult to choose one primary persona, this may indicate that your target market is too large and heterogeneous, or that your product has become too big and complex. If that’s the case, then consider re-segmenting the market, unbundling the product, or introducing product variants.

5. Make your Personas Believable

Your personas should help the development team empathise with the users and view the product from their perspective. To achieve this, your personas must be believable. The following three tips help you with this:

• Base your personas on first-hand user research (as discussed above).
• Choose a representative name and picture.
• Create and update personas together with the development team.

6. Focus on the Main Benefit or Problem

I frequently see personas that contain a lengthy list of goals. While is it is perfectly OK that a persona description states more than one problem that should be addressed or benefit that should be offered, I recommend selecting one main problem or benefit—the true reason why the persona would want to use or purchase the product. This creates focus and facilitates effective decision-making. If you feel that the other persona goals are too important to omit them, prioritise the goals and put the primary one at the top.

7. Connect Personas and User Stories

Make the most of your personas, and use them in the scenarios, the storyboards, the workflows, and the user stories you discover: your primary persona should be the protagonist in your stories. The template below puts the user or customer modelled as a persona into the user story (based on by Rachel Davies’ user story template).

As <persona> ,
I want <what?>
so that <why?>.

8. Involve the Development Team Members

The best persona descriptions are worthless if the people who should use them don’t understand or accept them. I therefore recommend that you involve (some of) the development team members in creating the personas. Ideally, the individuals should participate in the user research on which the personas are based.

If that’s not possible, then review the initial persona descriptions together with the team members and be open to feedback. Don’t add unnecessary or speculative details, but be willing to adjust the descriptions so that they are easier to understand for and resonate with the team members.

9. Don’t Forget to Update Your Personas

Adjust your persona descriptions, as you lean more about the users and customers and their needs by building prototypes and product increments. This is particularly useful in an agile context, where you want to minimise the amount of initial market research and start with provisional, good-enough personas to quickly test your crucial ideas. Adjust and refine your personas based on the insights you generate. Rewrite your personas or start with brand-new ones if you have to pivot and change your product strategy.

10. Recognise when Personas are not Appropriate

While personas are a powerful tool, there are instances when they are not appropriate. If you create a bespoke product that serves a small user group, then working with personas may not be necessary. Similarly, if your product does not have any end users, employing personas is not advisable.

Take a client of mine that develops a physics engine, software responsible for the clever animations in computer games. The users of the software are games developers who integrate the engine into their code. Creating personas for the physics engine is not beneficial in my mind. But for the entire game it is, of course.

Overview

The Product Canvas creation workshop wants to kick-start your product definition activities. It helps you change the focus from discovery and 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. You can also apply the technique to a traditional product backlog. The following picture summarises the workshop, and the rest of this post explains the details.

Attendees

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.

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 my Product Vision Board, 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.

Outcome

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!

Duration

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

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.

Scenarios

Scenarios and storyboards are great to explore and describe how a user interacts with a product. When we started to work on the re-launch of our website, for instance, I wrote the following scenario:

1. It’s Tuesday morning, and Mary is working on her computer. She wants to book Roger Smith on a public Certified Scrum Product Owner course taught by Roman.
2. Mary visits romanpichler.com and chooses a public CSPO class.
3. She enters the participant information including first name, last name, email address, special dietary requirements.
4. She then chooses a payment option and enters the payment details.
5. Mary accepts the terms and conditions, and confirms the booking.
6. Mary sees that her booking has been successful. After a short while, Roger receives an email confirmation with the booking details.

The scenario above describes the steps Mary has to take to book a seat on one of our public training courses. Mary is a persona who represents a user of our website: an HR employee of a large company, and who’s main goal is to book one or more employees on a training course.

Note that I have tried to make the scenario descriptive and engaging while focussing on the key aspects of the interaction.

Storyboards

Storyboards are similar to scenarios: They illustrate the interaction required to achieve a goal. But instead of using a list of steps, a storyboard visualises the interaction similar to a comic strip. Here is a sample board I created to explore another interaction for our new website:

The storyboard above describes how the persona Mary books several employees on the same training course. The board consists of a series of frames. Each frame shows sample data. Underneath it, I added a brief description of what Mary does at each step.

Note that I have done my best to describe the functional aspects of the interaction, and not to design the user interface: When I was working on the board, we did not have any design sketches and mock-ups available. I generally find it good practice to capture the product functionality necessary to meet the main user needs before designing the user interface.

What about User Stories?

User stories are another technique to describe the user interaction. A large story or epic allows us to summarise the interaction acting as placeholders for more detailed stories. I like to think of an epic is as a scenario rolled up into a brief narrative: it hides all the specifics of the user interaction. Detailed stories correspond to individual steps in a scenario, and describe a specific piece of product functionality.

The first thing I usually do when working on a new product is to write epics. To discover the right ones, I use the needs of the personas. Starting out with epics helps me quickly sketch the new product functionality, and it keeps the Product Canvas or product backlog concise and manageable.

But working exclusively with epics can be problematic, particularly when the epic carries risk: If we only have a coarse-grained description available, then it’s difficult to test our assumptions about how the users interact with the product. I therefore prefer to create a scenario or storyboard for risky epics, as the picture below shows:

Creating scenarios or storyboards for selected epics allows me to explore the user interaction in more detail, to describe the necessary steps and their relationship. This helps me test my assumptions, for instance, by creating a paper prototype that implements the scenario in order to carry out an early user test.

This is, of course, not the only way to combine scenarios and user stories. You can also derive stories from a scenario, and you can use a scenario to illustrate the relationship between different stories. The following diagram illustrates the three options:

Choose the options that are most helpful in your context, and combine them, as it makes sense. You can, for instance, start with the first option (as I did above), then derive new stories from your scenario or storyboard, and finally capture the relationship between the new stories in a new scenario.

A Sample Canvas

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.

The Sections Explained

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.

Putting the Users First

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

Learning and Emergence

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

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.

Tools

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.

Personas in a Nutshell

A persona is a fictional character that represents a subset of the market we want to address. A persona typically has a name, a picture, relevant characteristics such as age or income group, behavioural traits, common tasks, and a goal that describes the problem the persona wants to see solved or the benefit the character wants to achieve. This information is traditionally based on direct observation, interviews, and other qualitative market research.

Personas should help you develop empathy for your users and customers. They encourage you to embrace a user-centred approach: Putting the users first, and building a product that that truly benefits them. This avoids the fallacy of a solution-centric approach: worrying more about the product and its features and technologies than the reason people would want to buy and use it in the first place.

Alan Cooper pioneered  personas in product development in the 1990ies. Today every product manager and product owner should be able to create and work with personas.

A Minimalist Persona Template

While personas are a powerful technique to capture knowledge about the users and customers of a product, it can be tricky to write effective personas: Some persona descriptions I have seen were too detailed and bloated; others lacked important information. That’s particularly true when agile and lean practices are applied, and good enough persona descriptions are appropriate, which are updated and refined as more knowledge about the users and customers becomes available.

Using personas for my own products, I have found that there are three pieces of information that are particularly valuable to creating effective personas: the persona’s picture and name, the persona’s details, and the persona’s goal. I therefore use the template below to write personas. Simply click in the picture to download the template as a PDF.

The first two sections in the template above describe who the persona is. The last one is particularly important, as it makes us ask why the persona would want to purchase or use our product.

An Example

Here is an example of how the template can be applied. It features one of the personas of a new book I recently started to work on:

Notice that I have tried to make the persona description as relevant as possible. I have left out information that is not essential to understand who the character is and why the person would want to read the book. For instance, I decided not to include Peter’s marital status.

At the same time, I have tried to be as specific as I can right now about the persona, so I can validate my assumptions. As I find out more about the target readers of the book, I will undoubtedly iterate over Peter’s description, and update it.

While refining your persona, ensure that the character is believable and that its description helps people empathise with the users. You can do this, for instance, by adding pictures, likes and dislikes to the characteristics.

Visualising the Personas

I prefer to capture personas on paper, so I can easily visualise them, for instance, by putting them on the Product Canvas, as the picture below illustrates. An A4 paper sheet usually works well.

Another advantage of using paper-based personas is the limited space available. This helps us focus on the relevant information rather than writing everything down we believe to know about the user.

The Big Picture

The image below depicts the design process I like to employ. It’s user-centric, iterative, and collaborative. The process starts with capturing the design concept in form of a rough mock-up. Then the detailed design for one or more user stories is created and implemented as a throwaway prototype or as shippable software. The result is exposed to the users to understand if the design contributes to a great user experience. If it does, the design is refined, and the design for the next stories is created; if it does not, the design concept is reworked.

High-level Design

To get started, develop your design concept. The concept should sketch your key design ideas and communicate the essence of what you believe the product should look like. This includes the shapes and the colours you intend to use. Keep the overall product vision in mind together with the desired user experience: the kind of product being developed and the reason why people might want to use it. Focus on the critical aspects and don’t worry about the details right now.

For instance, the high-level design below shows how the structure, shapes and colours of our new homepage together with a photo of a bald guy with a beard and sticky notes.

Capture your design concept as a mock-up. Consider using a paper sketch similar to the one shown above. Paper sketches require less effort than wire-frames or other mock-ups; they are usually good enough to communicate the design idea. Make your sketch visible and put it on the product backlog board as shown below.

You may also want to explore the anticipated interaction of a user with the product, and to capture it as an interaction diagram or workflow. Put the resulting artefact on the board’s model area. (You can find out more about the backlog board in my blog post “The Product Backlog Board“.)

Detailed Design

With your design concept in place, create the design for each user stories you want to implement. This is best done as part of the product backlog grooming work. Developing the detailed design should hence be a collaborative exercise that involves the developers and testers. This allows you to leverage the team’s collective creativity and to quickly discover which design options are difficult and expensive to implement.

Sketch the user story-specific design on a paper card and attach it to the story card, as the image below illustrates. The design depicts the details of one of the boxes on the homepage:

Then implement the design either as a throwaway prototype or as shippable software, and expose the result to the users. Note that paper prototypes are often sufficient to test your initial design ideas. Resist the temptation to create a perfect design straight away: An unpolished implementation tends to generate more valuable user feedback than a super slick design.

Learning

Leveraging the user feedback to validate your design ideas does not mean that you don’t require a vision of what the product should look like. The opposite is true. You have to innovate for your users and cannot expect to be told what the product should look like.

Take the redesign of our website for example: Our customers, the organisations that pay for our training or consulting services, are important users of our website. Most of our customers are mid-sized to large enterprises. Having worked for large companies myself, I know that bigger organisations often prefer a more conservative look. But we wanted to create a website that that looks cool and that we like, not a boring corporate design. The challenge is hence to synthesise the wants and needs of the users and your own vision and ideas into a great design.

Use the feedback to experiment and discover which design ideas don’t work and which do. Don’t be a slave to the feedback, but don’t cling to your ideas either. Analyse the feedback with an open mind and decide what to do: take it on board or discard it. Then either rework your design concept or adjust it, and create the detailed design for the next story.

Means to an End

Some product owners I work with worry too much about how to write a certain user story or what the detailed design of a screen should look like. Whenever this happens, I find it helpful to step back and ask the following questions: Why would anybody want to use the functionality? Why would a certain design be helpful?

Exploring how a story or design idea benefits the users means viewing the product as a means to an end: to serve the users as well as the organisation creating it. As marketing guru Theodore Levitt famously put it, “People don’t want a quarter-inch drill, they want a quarter-inch hole.” What really matters are the benefits the product provides.

While serving the user should be the primary purpose of your product, you shouldn’t forget about the value the product has to create for your organisation. To do so, reflect on its business goals. A product typically generates revenue directly like Microsoft Office, indirectly by helping sell other products and services, think of the Amazon website and mobile app, or by saving cost, for example by automating business processes–many in-house built digital products fall in this category.

Additionally, Consider the business model required in order to meet the business goals. This includes identifying the revenue streams, the sales channels, and the cost structure. Be aware that your business model can have an impact on the product functionality: For instance, if you plan to generate revenue through online ads, then this requires the capability to place ads. As a consequence, an ad epic will appear in your product backlog.

The Extended Product Vision Board

To capture your ideas about user needs, the product, and the value created for the company, you may want to try my Product Vision Board. The extended version of the board shown below captures assumptions about the target group, the user needs, the top three features, and the key business model elements.

If you find it difficult to balance meeting the user needs and creating value for your organisation, then focus on the user. If your product is desirable, you are likely to find a way to make money. Users should come first, money second.

Next time when you get stuck in the product details, zoom out. Ask yourself how a feature adds value for the users and your organisation. Then implement it, gather the relevant data, and check if the benefit has been realised.