Many companies have created customer personas before. A project team meets, gives a persona a memorable name, adds an age, occupation, interests, and a few representative quotes. The presentation looks polished, yet when the team needs to decide which message to use, which feature to prioritise, or which touchpoint to fix first, that document offers little help. The problem is not that the company lacks a persona. The problem is that the persona was not built to answer a specific decision.
A useful customer persona must help the team understand what a customer is trying to accomplish, in what context, what makes them hesitate, and what evidence makes them believe their choice is right. When these questions are answered clearly, a persona stops being a descriptive page. It becomes a bridge between customer data and managerial action.
A customer persona is not a résumé
Demographic information can be necessary, but it is rarely enough to lead to a good decision. Two customers of the same age, income, and location may still choose very differently because they are in different situations. One may buy management software because a month-end report is due for a manager; another may seek a similar tool because a rapidly growing team is making the old process error-prone. They may belong to the same segment, but their motivations, risks, and evaluation criteria are different.
For that reason, the core of a persona is not “who this person is” as a personal profile. Its core is “where this person needs to get to” in a specific job or situation. A good persona should show the connection between context, goals, barriers, information seeking, and the action a company can take.
Start with the decision that needs to change
Before interviewing customers or compiling data, a team should specify what decision the persona will support. It may be the design of onboarding for new customers, the prioritisation of a feature, a change in sales messaging, the choice of advisory content, or the repair of a moment in the journey. Without that decision question, a team can easily collect a great deal of interesting information without knowing where to use it.
For example, a company that provides software for retail stores finds that many customers sign up but do not use the full range of features in the first month. If the question is “how do we increase activation,” the persona must clarify who sets up the system, how much time they have, what they are afraid of getting wrong, what format of guidance they need, and what signals show they are on the right track. A description such as “a store owner aged 35–45 who is interested in technology” answers almost none of these questions.
Applied example. The team discovers that the person setting up the system is usually a store manager, has only about 30 quiet minutes at the start of the day, and is reluctant to change sales data already in use. Based on this finding, instead of sending a feature-introduction email sequence, the company can design a 15-minute setup step, allow sample-data entry, and provide a support call button at the point where errors are most likely. The persona has then led to an experience decision, rather than simply creating more understanding.
Five layers of information create a usable persona
The first layer is role and context. What job is this person doing, to whom are they accountable, and what conditions make the need appear? A marketing director, an operations manager, and a purchasing employee may all encounter the same product, but each has different decision rights, time pressures, and success criteria.
The second layer is the progress they want to make. Rather than asking only “what do you need,” find out what outcome they want to produce, what is not working, and why the issue has become urgent now. This line of questioning distinguishes a surface preference from the result the customer is actually pursuing.
The third layer is the trigger. A change at work, an incident, performance pressure, feedback from a manager, or an unsatisfactory experience can cause a customer to begin looking for a new option. Understanding the trigger helps a company choose the right timing and language, rather than appearing before the customer sees a reason to change.
The fourth layer is perceived barriers and risks. Customers may see a solution as suitable but still delay because they fear losing time, distrust the data, worry about additional costs, or dislike having to explain the decision to someone else. These barriers often determine how a company must demonstrate value, design commitments, and organise support.
The fifth layer is decision behaviour. Whom do they ask, where do they search, which sources do they trust, what do they need to compare, and who can veto the decision? This is particularly important in B2B settings or high-risk services, where the user, payer, and approver may not be the same person.
Move from data to a persona rather than from assumptions to a presentation
A credible persona should be built from traces that are close enough to the actual decision. A team can combine interviews with new and former customers, notes from sales and customer service, product-behaviour data, survey feedback, reasons for complaints, and conversations that take place at the service point. Each source has its own blind spots, but when signals recur across sources, the company has a stronger basis for identifying a pattern of customer situations.
It is important to separate evidence from interpretation. If five customers say that data migration worries them, that is evidence. Concluding that all customers are afraid of technology is an overbroad inference. A persona should state what was observed, which customer group displayed the characteristic, the context in which it appeared, and what data still needs to be checked. This approach keeps the document useful for longer and easier to update as the market changes.
Bring the persona into decision meetings
A persona has real value only when it is used regularly. In marketing, it helps test whether a message addresses the problem customers care about or merely talks about the company. In product development, it helps distinguish a feature that is merely appealing from a feature that resolves a priority bottleneck. In service operations, it helps determine when customers need self-service, when a person should intervene, and what information must be available to frontline employees.
A practical approach is to add three questions to every customer-related meeting: which customer situation does this decision serve; what evidence shows this is a priority problem; and after the change, what indicator will show that the customer has moved closer to the result they want? If the group cannot answer them, the persona is not good enough yet or the decision is being made too far from real data.
Three signs that a persona needs to be rebuilt
The first sign is that the document contains many adjectives but few situations. Phrases such as “values convenience,” “cares about quality,” or “is technologically capable” sound reasonable but do not tell a team what to do differently tomorrow.
The second sign is that one persona is used for too many different decisions. A persona used for brand positioning may need to differ from one used to improve onboarding or handle complaints. A company does not necessarily need to create many complex personas, but it must define the intended use of each one.
The third sign is that no one is responsible for updating it. Markets, information channels, decision participants, and service expectations can all change. A persona should be revisited on a cycle or when the company observes unusual changes in conversion behaviour, customer feedback, or retention.
Conclusion
A customer persona is not a device for “humanising” a slide deck. Its value lies in making a product, marketing, or experience decision more specific, more evidence-based, and easier to test. When a persona begins with a real situation, is built on evidence, and is brought into decision meetings, it helps a company see a customer as a person trying to move forward, rather than as a collection of attributes to classify.
References
Cooper, A. (1999). The inmates are running the asylum. Sams.
Pruitt, J., & Adlin, T. (2006). The persona lifecycle: Keeping people in mind throughout product design. Morgan Kaufmann.
Revella, A. (2015). Buyer personas: How to gain insight into your customer’s expectations, align your marketing strategies, and win more business. Wiley.
