Who Is This For?

Part five of the product owner toolbox. The leave tool has a vision and a first epic. Before we break the epic into features, we need to know the people we’re building it for.

Personas

A persona is a fictional but concrete member of a group of users, with personal traits, intentions and emotions.

Good personas come from data. You collect it with interviews or questionnaires, then group it with segmentation or cluster analysis, and condense each group into a persona. A persona that was invented in a workshop by people who have never met a user is a stereotype with a name. It’s worse than having no persona at all, because it looks like evidence.

A persona makes a group of users tangible. The team can imagine how that person thinks, which keeps the team from building past the user. Personas also help when you prioritise: “Does this help Sandra?” is a question that ends discussions.

A persona has four parts:

• Who: name, age, job, role, tasks, training, knowledge
• Needs and behaviour: What does a typical day look like? What problems do they struggle with?
• Goals and expectations: What do they want to achieve?
• Values and fears: What feelings come with their daily work? What guides their decisions?

Start with one primary persona. Add one or two more for the wider scope, but no more than that. With five personas, every feature serves someone and the personas no longer help you decide.

The leave tool’s primary persona

Sandra, 41, team lead in the warehouse. She leads 14 people in two shifts. She trained as a logistics specialist and has been at the company for twelve years. She plans shifts in a separate spreadsheet that she built herself, and she’s proud of it.

• Needs and behaviour: She approves requests on her phone, standing between two shelves. By the time she sees an email, two other people have asked for the same week.
• Goals: In August, the warehouse can’t drop below nine people per shift.
• Values and fears: “I don’t care about the tool. I care that August isn’t empty.” She’s afraid of saying no to someone because she didn’t know the week was already full.

The secondary persona is Marco from HR, who currently retypes every approval into the master spreadsheet.

In this series Sandra and Marco are illustrations. For a real product, they’d be the result of talking to a dozen team leads and the whole HR team.

User journeys

A user journey describes how a user moves through a process, a system or a product. It can cover the whole experience, or just one part of it. What matters is the user’s perspective: what they notice, do and feel at each step.

For each step, record four things:

• Context: Where is the user? What’s distracting them?
• Progress: What do they have to do to get to the next step?
• Emotion: Are they engaged, bored or annoyed?
• Functionality: What do they expect from the product? Is that possible? What’s missing?

Also mark the pain points, the moments where the user might give up.

Keep the level coarse and usually stick to the happy path. The journey is a communication tool for the product owner, developers, testers and stakeholders, and it keeps the user’s point of view at the centre of discussions about functions and priorities. The more it covers the complete flow of screens, the better it works as the basis for a story map. Combined with the personas, it’s also a good basis for user acceptance tests.

The leave tool’s journey

Here’s the journey of an employee on Sandra’s team, requesting a week in August:

Step	Context	Emotion	Functionality	Pain point
1. Check balance	At home, evening	Unsure	Remaining days, at a glance	Today: has to ask HR
2. Check the team	Same	Hopeful	Who is already away that week	Today: no way to know
3. Request	Phone, couch	Neutral	Pick dates, submit
4. Wait	Next day at work	Impatient	Status of the request	Today: silence for days
5. Get the decision	Anywhere	Relieved, or not	Notification with the reason	A “no” without a reason
6. Plan the trip	Booking site	Happy	Absence shows in the team calendar

Two of the biggest pain points (steps 1 and 2) happen before anyone requests anything. A tool that just digitises the request form would miss both.

Next

The journey’s steps become the backbone of a story map. Next time: features, and how a story map turns a journey into a release plan.