The importance of user personas in product management cannot be understated.
Well, that’s not true, because for the most part, subject to the rules of grammar, I can assemble words in any manner I please, so I could tell you user personas are total bullshit , but I would be lying.
The Importance Of User Personas In Product Management
Anyways, enough with semantics, the role of users personas in product management is central to the existence of your product and company itself because if you don’t have an idea of whose problems you are solving, how do you know if you are building something useful.
User personas are a tool for helping you figure out:
- Who are the customers for your product,
- Why are they buying your product?
Once you have these answers, you can optimize your products for these people. The goal is to segment your market by focusing on common problems.As a product manager, you will find yourself creating multiple personas for the same product as often the person using the product and the person actually purchasing it—aren’t the same. Consider items as diverse as a video game aimed at 5 year olds (Parent buys/kid uses) or heavy duty manufacturing equipment (finance department buys, so they will be considering the financing options available to them while the manufacturing department will be looking at product specs).
The Role Of User Personas In Product Management
From a practical point of view, most products have different types of customers, as different people buy the same product to solve different problems.
Cataloging all of these people and their problems is an infinitely complex task (and potentially precisely imprecise to be honest) so product managers abstract this information in user personas. Another way to think of this is that a persona is simply a bucket that contain information about users who share a common trait that we deem as relevant to our product.
What's In The Persona?
First off, remember that personas are simply tools understand your customers, and not actual end customers. They are fictionalized, “typical” customers that let you segment your target market by highlighting the characteristics of your product that appeal to different groups of customers
Personas are created by abstracting the various common traits we care about in our potential customers into customer archetypes.
In a more literal sense, a persona starts off as a file that contains:
Fictional name: The name often captures something about the user’s relationship with the product. So if you are building out personas for a networks security tool, you may have personas named:
- Nancy Network
- Sara Security
- Harry Hacker
Picture: Again you want to find user persona images that capture the persons sentiment if possible. Finding user persona images shouldn’t be too hard if you know where to look.
Demographic details: Age/gender/income/education/psychographics
Common Tasks: Does this group engage in any common activities/tasks over all?
Problems to be solve: Why is the persona in need of your product? What issues are they having with current solutions? How do they currently solve their problem?
Priorities: Flush out the persona priorities associated with your product. What are the things he must have from any solution you create? What problem is a given persona trying to solve, what does he do when he tries to solve it, and what happens as a result?
Social/Emotional Considerations: Include relevant ones obviously.
Propensity to Adopt: We will be discussing this later in the article, but know we are talking about the user adoption curve.
As we stressed in the Ten Commandments of Product Management, never assume you know your customer and make sure all of this information is accurate or you risk building your product off of fake use cases. Although it should go without saying, ensure your personas align with what your product does.
The Mechanics of Building User Personas
After you’ve finished validating that your product hypothesis is valid (If you missed our gem of an article “How Do Product Managers Validate A Product Hypothesis?, stop what you are doing now and read it. NOW!!!), take your findings and start building out your personas with something that approximates a Name/Picture/Details/Goals sort of format.
Do not be surprised if there is nothing written down at your company as there is a good chance the personas are still “wetware“, so you will have to squeeze them out of someone’s brain.
So some industry luminaries say it’s not mandatory to have pre-existing customer knowledge to build a persona, my response to that belief is best depicted by both the image below and referring your to a quick overview of the Dunning Kruger effect.
If you don’t have any pre-existing customer knowledge by the time you reach the persona building stage, after you developed and test your hypothesis, there is only one answer:
While yes your personas, just like your software product roadmaps and your product requirements documents are living documents that start out rough at first and get refined over time, they do not start out by sticking your finger
up your ass in the air as the starting point. If your company really has nothing concrete to put on paper, I would be worried.
Quick Tip: Knowing Who To Fire
If a someone you’ve hired in a product management capacity responds that “everyone” is a potential customer for your product, fire them, on the spot if you can. “Everyone” is not a persona and cannot help your decision making process.
How User Personas Help Prioritize Product Development
As we’ve discussed so far, as a product manager, your first thoughts should be about who the target personas are and what pains they are looking to solve. The next step to understanding the path to product success is getting people to use your product and this requires understanding two overlapping ideas:
- Where you product is in its stage of life, is it brand new, has it been around for a while? has it been a category leader for 25 year?
- Where do your target customers/personas fit on the user adoption curve.
Knowing and understanding these two points with regards to your product aids in knowing how to prioritize features for your product roadmap so you launch features that generate benefits for users most likely to adopt them.
While you may have a product that solves a particular product, if it doesn’t sync up with where a customer sits on the user adoption curve, they will not buy it.
If you are making a bleeding edge technology product, do not be building out features to attract personas that you consider to be part of the “Early Majority”, as this results in a disconnect between the product itself and its intended user.
People like to buy/use products that are consistent with their internal picture of themselves. So if they are not the risk taking early adopters , it is pretty unlikely they will overlook what they consider missing features in exchange for. the esteem of being seen as cutting edge.
Scenarios: Putting User Personas To Work
You build on user personas using them to construct user scenario/, (at this point you probably need to start keeping the concepts of scenarios, user stories and use cases in product management straight or risk working on the wrong deliverable). These user scenarios eventually become a foundation of your product requirements document. These scenarios are an effective way to get your team to see the customers’ perspectives as they operationalize the problems they face (and the ones you are looking to solve), so your team members can take the place of the customer as they build the product out.
Scenarios are compiled by combining personas with the information you gathered when you were validating your hypothesis ( maybe your ran a customer survey too) with some empathy sprinkled on top, to write paragraph
stories scenarios about how your customers will use your product to solve their problems. Before describing what should go into a scenario, let me tell you the 3 items you want the scenario to accomplish
- Like true love, it should be real: Make readers feel like they’re using the product in each scenario. Provide the relevant detail so that the reader steps into the customer’s place when using the product. As you write, include details relevant to helping a reader imagine the situation you’re describing. Start writing a detailed story and then eliminate details that do not change the overall meaning of customer need or how the product addresses their need.
- As we have said before, beware the fake use case, and in this situation, fake scenario. Being authentic helps eliminate unnecessary product features. If you find yourself trying to force what you thought was a key feature into the story, that’s a great hint that the feature isn’t essential.
Write your scenarios so that if a customer in your target persona were to read it, she’d go, “I’ve been in that situation before, and this product sounds fantastic!” Being authentic extents to being realistic about the impact using your product is going to have on people.
A realistic statement is along the lines of “Because he customer was happy with their initial trial, they committed to a 12 month subscription at a 15% discount”.
- Keep out of the weeds, other people get paid for that. Unless you are a team of one, do not use too much detail when outlining what a solution looks like.
For the sake of consistency, all scenarios should have the same structure and avoid using jargon as much as possible to eliminate ambiguity.
For a user scenario, who’s the persona? Remind us quickly about the customers that persona represents.
What are the key details we need to know? Make sure to include the problem causes the persona to need your product, or to need a specific feature in your product if he was already using it in the setup?
- Why does he think to use your product?
- If he’s a new customer, how will he find/buy your product?
This is where the persona is using the product the product you envision. Important points to cover include:
- What roadblocks/conflicts do they encounter while using the product.
- What product features help eliminate those roadblocks?
- Justification as to why various other features are important.
- The outcome of solving the problem, how does their world change?