“The actual method that works sounds trivial, but it is tremendously powerful and effective in every case: We make up pretend users and design for them.”
From “The Inmates are Running the Asylum”
by Alan Cooper
When designing new products, it is difficult to get the combined marketing and development team to agree on decisions. Poor decisions result in poor products that are too expensive and not sufficiently useful. Poor products destroy brands, fortunes, companies and careers. The use of personas can help us to make better decisions by helping us to keep our customers in mind throughout development.
A persona is a hypothetical archetype of a real person. They are defined by their “job to be done” (JTBD). That is, they are defined by their objectives. The persona will represent the individuals within a market who seek to accomplish the same job. They seek to accomplish the same task, solve the same problem, or achieve the same goal. But rather than calling them “Design Engineers” or “Soccer Moms” we assign them an identity. This makes them seem real to us so that we might empathize with their troubles. So rather than solving a problem for the oil drilling industry, we are solving a problem for Karl. Karl is a fracking technician from Tulsa, Oklahoma. He spends 70% of his time on the road, traveling to remote corners of Texas – trying to coax stingy oil reserves out of their prehistoric hutches. The US government will not actually find our Karl in the tax register since he is, well, fictitious. And yet, he lives and breathes within our imaginations. Living the pain and frustration that actual customers do, in fact, experience.
We created Karl. We began with his “job to be done” (JTBD) which was opening oil wells via fracking – and then we continued his development with demographic descriptors (age, race, appearance, etc.) and of course, with his name.
The personas technique arose from software development as savvy product managers realized the difficulties that an experienced developer had trying to understand the expectations of technically challenged customers. It would ultimately prove useful for both B2B and B2C. In time, practitioners of design thinking would eventually add this tool to their boxes. It has since been adopted by many others.
Here are four best practices for using personas for B2B growth:
Seem counter intuitive? Think about breakfast cereals. Ron the runner is male, 42 and active.
His JTBD for his breakfast is to maintain energy throughout long runs each day. Meanwhile, Barbara the busy mom is 30, she struggles with her weight and she barely has time to get the kids off to school each morning. Her JTBD is to lose few pounds. If we were going to create a breakfast cereal for a generic “user”, we would average these objectives somehow. Combining the high-energy needs for Ron with the low-calorie requirements for Barbara, we end up with a result that neither wants. Trying to please everyone, we have pleased no one.
After defining the JTBD, we assign our personas with names, races, genders, nationalities, etc. with the goal of making them as believable as possible. Think about a common B2B scenario, healthcare. If we were doing a Blueprinting project for a new medical device, we might have Dan the Doctor and Nancy the Nurse as personas since they both could use the device. By listing these genders, should we be concerned about stereotyping? From Alan Cooper’s treatise on personas within The Inmates are Running the Asylum, “My goal here is not to be politically correct but to get everyone to believe that my personas are real.”
Precision reduces uncertainty during development. It keeps the design team aligned – working towards the same outcomes. A sub-optimal decision in which a team acts cohesively is preferred to the perfect decision executed with doubt and vacillation. In American football, a team on offense will call a play. They could call a running play or a passing play. What’s more important, however, is that all 11 team members execute the same play. When we say, “precision,” we mean a precisely defined person and a precisely defined job. No wiggle room. No opportunity for confusion. We call a play – and we execute it together – as a team.
Imagine that we develop chemical pesticides and would like to better understand landscape contractors. For this market, we create personas for the worker who applies the chemicals as well as the onsite supervisor who is responsible for the results. These are the users.
Realistically, in B2B, we know we have other purchase influencers as well. And so, we will also create buyer personas. In this case, we could create one for the company owner who purchases the chemicals. Though, for larger customers, we might also have personas for safety directors, procurement folks, quality management, and whatnot.
Arising from customer advocates within software development, the technique found allies with design thinking pioneers and finally, the broader product development community. Despite differences between product development cultures across industries, all have customer needs to address. By helping a business to develop a common understanding of its customers, the personas technique has broad application.
For B2B leaders, it can accelerate development by driving alignment around key findings from Blueprinting projects. In this sense, it is a communication tool to amplify what was learned.
Blueprinting practitioners can develop them as part of the Product Objectives step (after Preference Interviews). Created from the qualitative and quantitative insights, the personas will live on through development and even product launch.
For a quick overview, try Cooper’s book The Inmates are Running the Asylum. For a more complete treatise, I recommend The Persona Lifestyle by Pruitt and Adlin. Do you use personas? What advice would you give in their application? We’d love to hear your thoughts!