Skip to main content

Personas: make it personal

I’m working in a digital delivery team at the moment and that means we are always obsessing about “the customer”. We talk about the customer needs, ensuring we are thinking about their experiences and we build features we think they will 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.  

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 on-line ice to eskimos very successfully, however they said something that shocked me: akin to “Nobody wants to buy clothes from shops that are only on-line”. “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.

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
  • She highly values job flexibility, time with her children and value for money
  • Pain points are 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
  • 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.
  • She highly values time with her children and being able to have enriching experiences with her family in her non-work time.
  • Pain points are about being time-poor and balancing ‘having it all’ i.e. career and family, and people and things that waste her time.
  • 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:

  1.   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.
  2.  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.
There’s also a one very powerful workshop activity that will allow you to prioritise your features and build only what your customers – who now have personas – will need.

I will blog about this next in “The journey the customer has to have”

For inspiration for this blog, I credit Nadir Khan who ran this personas exercise for us and opened my eyes to the problem of building for unknown customers.

*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!


PeeVee said…
Great little reminder that we build systems for real people, not "users" or "actors".
Thanks Alex

Popular posts from this blog

Business Requirement Documents are just no good and should be abolished from the world of creating software

I had hoped the world could have wholeheartedly rejected Business Requirement documents by now. For too long I’ve seen the repeated scenario of only commencing the creation of a new initiative with a requirements document.Unfortunately most organisations that have teams developing software still use these flawed anathemas to creativity as the status quo. Despite agile approaches maturing and customer-centric modes of design emerging, requirements documents still persist. 
If you work in an organisation that doesn’t use business requirement documents any more, read no further. You are lucky; sense has prevailed at your place however in my experience, you are still the minority.
Let's face it; addressing this issue is not always the point you want to start your improvement work when there's much that could be dysfunctional with how a team is delivering software. But now, I find myself as mad as hell, and I'm not going to take business requirement documents anymore. I want to …

Gamify your children

Inspired by James Ross’s LAST conference talk on The Shamification of Lamification and the Reclaimification of Gamification I was motivated to try and “Gamify” the school holidays for my three children, Leo aged 8, Chloe 9 and Max 10.
Buy-in is everything, so the first thing we did was a quick workshop to extract the kids ideas. I asked them to write their ideas for good rewards on sticky notes, with a few examples for context, such as ‘trip to the movies or ‘play date with a friend’ . They had 5 minutes to come up with their ideas – one idea per sticky note (as always).
They then read out their ideas for all of us to hear, there were a few duplicates and also a few comedy suggestions. Even though we had ruled out crazy stuff, such as rewards of a million dollars, Leo had written down ‘A unicorn for the back yard’ reading it out with gleeful giggles.
Then they spent 5 minutes writing down tasks that they could do to earn rewards. By now they had the hang of it and quickly came up with t…

Agile Australia 2011 Series - Agile Governance

If you are in an industry that is heavily into governance you need some structure and process around your projects or you could find your Agile projects getting usurped by the culture of command and control. So it’s important not to shy away from the topic but to work with the entities that enforce and monitor governance. In this way you can create something that is fast and easy and not laborious to work with.I work for an Apra regulated organisation and we made keenly aware of our obligation under Apra to evidence documented change when audited. However in all organisations I’ve ever worked in, there are boundaries that bend quite a bit, ways to change things and ways to get by that satisfy governance process without crippling your agile process.There’s almost two alternating schools of thought here which are ‘work within process’ and ‘decide to change the process’. It’s actually pretty easy for my team to work within process. Project approvals, mandates and PIDs that are important …