Personas: Make it Personal
I’ve worked in digital delivery teams where we were obsessing about “the customer”. We talked about the customer needs, ensuring we were thinking about their experiences and then built features we thought they would love.
However it’s very easy in any organisation to convince yourselves you know who your customers are and what they want and get it wrong, that is, build things that they don’t need or want.
It’s also an area where a team can be working on the same initiative, but carrying conflicting beliefs in their heads about the customer needs. Dangerous! In this paradigm, who will win the argument about building feature X over feature Y? Having a dedicated and knowledgeable Product Owner is one strategy for solving this problem, however, adopting this approach adds another risk of single point of failure, i.e. always needing the Product Owner to be available to make decisions about features.
“...a team can be working on the same initiative, but carrying conflicting beliefs in their heads about the customer needs... who will win the argument about building feature X over feature Y? ”
Listening to one person’s view, such as a Product Owner, has another inherent risk, illustrated by a surprising conversation I had not long ago with an expert in digital commerce. This person could sell online ice to eskimos very successfully, however they said something that shocked me: akin to “Nobody wants to buy clothes from shops that are only online”. “OMG” I thought to myself “ I do!” And then my head swam, much in the manner of Indiana Jones in the “They’re digging in the wrong place!” scene. Listening to one persons view, even an experienced one, in relation to a requirement can be dangerous and can cut off paths to value for our organisations.
The mechanism of having Use Cases inside requirements documents doesn’t come close to solving this problem*, and if you find yourself reading a requirement document that describes customers of your product as ‘actors’, ‘users’ or ‘registered users’ then your organisation doesn’t know your customers very well, and you will likely end up building them the wrong thing, too much of what they don’t want, or missing what they really do want, completely.
User Stories that use the familiar “As an X, I want Y, so that Z” format are not much better. One word to describe who will use your solution does not guarantee a desirable user experience.
So if dedicated Product Owners, Use Cases and User Stories can’t help us, how can we really get to know who our customers are and faithfully represent their needs?
Here’s one simple and straightforward technique you can add into your workshop repertoire when deciding on features, that will help you build for customer needs and solve their problems.
“So if dedicated Product Owners, Use Cases and User Stories can’t help us, how can we really get to know who our customers are and faithfully represent their needs? ”
In a workshop ask each attendee to create a persona for the customer in the context of your product. Below is some suggested information to include. My suggestion is to make it personal, and encourage creativity. For example draw a picture of what the person's face looks like, name their family members, don’t shy away from including some emotion. This first step is done solo, and everyone contributes a persona.
Person: Persons name, Age, Occupation, Family Members etc.
Goals: Personal / Professional
Desires: What they value most
Pain points: What problems could they have in relation to your product
Scenario: A Scenario that describes why the person will use your product
Home Loan example:-
Person: Joanna, 25, Part time office worker, 2 school aged children no husband, sole provider for her children
Goals: To own her own home rather than rent, and to stay at her employer and steadily increase her wage/hours over time
Desires: She highly values job flexibility, time with her children and value for money
Pain points: Qualifying for some products due to single parent status, making ends meet and the time to invest in researching and applying for a loan, and buying a house
Scenario: Joanna has come to our product because it offers, in simple language, information on how she can qualify, she can research the product simply on-line, in her own time, she can receive information about it and can nominate a time that’s good to talk about it on the phone. She can see the rate is comparable to other loans.
The home mortgage example tells us a lot about what the features that attract Joanna might be.
Christmas Lights website example (described in the Solving Customer Problems blog):
Person: Carol, 42, Full time busy IT manager, 3 school aged children. Married to Stevie who also works full time in a busy IT role
Goals: Balance work and life, live comfortably, have success in work.
Desires: She highly values time with her children and being able to have enriching experiences with her family in her non-work time.
Pain points: Being time-poor and balancing ‘having it all’ i.e. career and family, and people and things that waste her time.
Scenario: Carol wants to browse our product on a smart phone as she will be mobile while trying to track down Christmas lights to see with her children – an annual event. She has all the latest gadgets for helping her manage her busy work/home life and is frustrated when things don’t ‘just work’ as she is in an IT job. She wants to travel locally and get around using maps functions that are quick & easy to use while her husband is driving.
The Carol example tells us about what features may or may not appeal to her person, e.g. this product must be accessible on a smart phone. It may also have a feature that emails Carol prior to Christmas every year.
*
As a group, share all of the personas for your product’s context by sticking them on a wall and talk the group through each person, this promotes collaboration and allows the group to own the newly created set of personas. Allow time for attendees to ask questions about the people, and get to know each person. I find this part of the workshop the most fun, meeting other people’s personas is always more interesting than just knowing your own.
Now you have a set of people you are building your product for. Ask each other if there are any people/personas missing and create some more if necessary. For example, internal users that interact with your product and perform back-office functions are often the forgotten customers of a product, but they are customers nonetheless.
You may be thinking, “But people are all different. Aren’t there as many personas as there are people in the world?”
Yes there are! But many of them have similar needs and values, so you can reduce the number you are building for. Take some time to group the personas if you see that a number have very similar goals, pains and value the same things, this lets you whittle personas down to your key demographic. Noting, that if you start your persona workshop unconstrained i.e. go broad rather than narrow first, it may uncover a new customer demographic that you weren’t considering before. Opportunity!
Once you’ve done the personas exercise two distinct and important advantages tend to emerge:
Your eyes will be open to how often we enter into expensive and lengthy projects, building software for unknown customers. You will start to notice that it happens everywhere, on websites and products you use and projects you are close to. The insight provided by personas allows you to interrogate the relevance of features and cut out the useless ones.
When the team can be involved in a workshop to create personas for the product they are building, their focus can shift away from being ‘order takers’ for a product manager, and become more meaningfully engaged in the product they are building, voicing the needs of their now better-known customers and ultimately building a better product.
So now you have a wonderful set of personas that you all agree are important customers of your product. What to do next? I would suggest creating them into large sized long lived artifacts that are stuck up on your team wall, giving them faces (actual photos rather than your hand drawn cards) and really getting to know these people while you are building for them.
Next you will need to prioritise your features and build only what your customers – who now have personas – will need. But that’s a blog for another day!
***
*This is another reason why requirements documents are just no good in any situation and must be abolished from the world of creating software. Though this blog isn’t about panning requirements documents, I make a note to self to write one that is about that!