A lot of people stand up a variation of “If you build it, he will come” (from Field of Dreams) as a copy-writing hook for whatever they are about to tell you about creating products/services/whatever. We’re no better. We’re going to tell you that there is a big difference between the people who buy your product and the people who use your product.
If you build what he thinks he wants, he will come.
Actually, we need two catchy quotes.
If you build what he actually needs, he will come back.
For good measure, let’s plug my recent article in The Pragmatic Marketer, Maximize Your Word of Mouth Marketing: Turning Users Into Fans with a gratuitous quote.
If you build it right, he’ll bring his friends.
These quotes (the first two) highlight the differences between buyer personas and user personas.
Personas Are Not Personas
It can be incredibly confusing to anyone not already entrenched in product management or marketing, to hear someone talk about personas. The buyer persona is a very different person than a user persona. Understanding one influences how you sell a product, understanding the other is key to getting insights about how people will use your product. There’s a bit of a catch-22 here – you have to sell the product (even free products have to be “sold”) before anyone ever uses the product. And if you sell someone a product they hate, you’re worse off than if you never made the sale.
If you want to “test out” of the rest of this article, here’s the crux:
- A buyer wants a product that has capabilities that match his mental model of what is required to solve valuable problems.
- A user needs a product that solves her valuable problems.
Peony Problem
You are part of a booming florist business that has a problem. Your profitability is too low on the flowers you sell.
One of your store managers, Eunice, looks at what you pay for flowers (very little), and what you sell them for (a lot). She also determines that overhead (rent, salaries, etc) costs are reasonable. However, Eunice notices that you throw away half of the flowers you buy.
[Note: Check out our article on defining problems to see how and why to create an Ishikawa diagram like this one.]
Your company policy is to throw away flowers after you’ve had them for 2 days, because they wilt as soon as your customers get them home if you don’t.
Amaranth Analysis
Eunice also reviews orders and purchases of flowers – there’s no regularity in ordering. The average number of flowers purchased every day is about the same, but the individual amounts vary wildly. If you ordered fewer flowers, you would save on waste, but you would lose out on some sales, and risk damaging relationships with loyal customers. She decides that the solution isn’t to just order fewer flowers (you need that inventory on hand), but to make the inventory last longer, so that you can have the same amount on hand, but order fewer flowers. Eunice gets approval from the owner of the florist to purchase a walk-in cooler for storing the inventory, and then asks Fiona, the head of operations, to make it happen.
Brenda runs operations. She handles accounting, and ordering of supplies, payroll, all the things that keep the business running. She doesn’t know flowers, but she knows the flower business. Brenda now has a problem – she needs to purchase a walk-in cooler.
Eunice is your user.
Brenda is your buyer.
This is the important distinction. Eunice has a problem that is solved by using your product. Brenda has a problem that is solved by purchasing your product.
Helping The User
If you’re a product manager, you already know how to help Eunice the user. You define a user persona and her problems and goals. You prioritize those problems, build a product roadmap, and make sure your software process benefits from the user persona you’ve defined. Of course, don’t overdo your persona development.
But what do you do with a buyer persona? If you apply product management first principles, you recognize that the buyer has a problem (Brenda needs to buy a solution for Eunice’s problem). So, create a solution for that problem. Marketing experts might not think about it that way, but that’s what they do. They understand the perceptions in the minds of buyers, and design marketing campaigns – and influence product development – to make sure there is both a product and a campaign that addresses the buyer persona’s problems.
Helping The Buyer
Shaun Connolly sums up his approach with two quotes from a recent article:
For both proprietary and commercial open source software, the Product Manager needs to focus on creating a product that people will actually buy! Plain and simple.
For any new product offering, one of the first places I focus is on understanding and documenting the Buyer Personas. After all, how the heck are you going to create real value for customers if you don’t know who’s buying? User personas, while not the same, are also useful to understand.
Product Managers: Chief *Holes or Value Creators?, Shaun Connolly
Shaun is definitely stressing the importance of one side of our catch-22, getting that initial sale. Note that Shaun also links to a good article by Gopal Shenoy, Build Products That Customers Will Buy…
OK, so what is a buyer persona? Adele Revella has an entire blog dedicated to buyer personas (and an article devoted to answering the question “what is a buyer persona?”
Don’t Confuse The Buyers With The Users
Adele has a great article lambasting some marketing work that Microsoft has done for their CRM product – apparently posting videos of their buyer personas, and treating them as if they are user personas. Adele is being gracious, I think, in suggesting that the mistake was merely in sharing the buyer personas externally, when they should be for internal use only. I suspect that this team has mixed the concepts, since the “buyer persona” Adele uses as an example is describing her problems as a user.
In any case, it is disheartening to see anyone have (and share!) such a disparaging and condescending idea of who their users and/or buyers are.
When Your Buyers ARE Your Users?
David Meerman Scott just posted an article, How well do you know your buyer personas?, where he shines the spotlight on Kadient, a SaaS (software as a service) company. Kadient helps sales people manage their sales collateral (RFPs, white papers, proposals, etc). David’s article is the latest in his theme of the importance of focusing on buyer personas. He and Kadient share a couple buyer persona examples for us. As it turns out, the personas they shared happen to be both buyers and users. There are probably also buyer-only personas that they could have picked, but this choice is great. It acknowledges for us that your buyer can also be your user.
Considering that Adele’s article just warned us not to mix them up, consider this as a corrolary to the maxim – Don’t confuse buyers and users, except when they are the same person.
One of Kadient’s combination buyer + user personas is Anya. Check out David’s article for the full details. One thing David shares with us is Anya’s goals. Remember from our example with Eunice and Brenda – Eunice (the user) has goals to solve problems with her work, and Brenda has the goal of solving Eunice’s problem. With Anya, she has both user-goals and buyer-goals.
David’s example captures both, but it might be tricky to tease them apart. As a buyer, Anya is trying to match a mental model of what will work. As a user, she has specific objectives. Here’s the goal section from Kadient’s persona:
Anya needs to bring in the numbers every quarter, to remain secure in her position at the top of the sales performance chart. To do this, she knows that if she can spend less time doing administrative duties and looking for information and creating materials for her buyers, she can work more opportunities and maximize her face-time with customers. The service offerings she sells change frequently, and she knows she needs to be armed with the latest, most accurate messaging and content.
Breaking it down into two goals, half-buyer and half-user:
- Buyer Goal: “she knows that if she can spend less time doing administrative duties and looking for information and creating materials for her buyers”
- User Goal: “she can work more opportunities and maximize her face-time with customers”
And
- Buyer Goal: “she knows she needs to be armed with the latest, most accurate messaging and content”
- User Goal: “The service offerings she sells change frequently”
This is a buyer persona example, and the buyer goals are explicit – “She knows..” is a clear indicator of her mental model of what she believes she needs to solve her problems. That is the key information for properly marketing to Anya.
The user goals are not crisply defined, but support a statement from Anya’s “bio” – “Anya wants to ensure she always remains at the top of the team.” One way she could do that is by maximizing face time with customers and working more opportunities (as a means to close more sales). Anya also acknowledges a nuanced goal – her service offerings change frequently – and those changes presumably can negatively impact her ability to sell. It is ok, for a buyer persona, that the user goals need a little more inference. But that’s ok – the team at Kadient will be using this persona primarily to sell their services to Anya, not to design them.
Ideally, your buyer’s mental model of the needed solution will align well with the user’s problems. That isn’t guaranteed, even when the buyer and the user are the same person.
Summary
- Buyer personas make purchases when products appear to address their internal view of what the problems are.
- User personas love products when those products solve the real problems.
- Don’t confuse buyers (who need to buy products to solve user problems) with users (who need to solve their own problems).
- When buyers and users are the same people, acknowledge the buyer-goals distinctly from the user-goals.
Latest Articles
Comments on all Articles
