Creating valuable software requires knowing the customer—we all agree on that, right? The first question that then comes to mind is how to support this product discovery process in a meaningful manner in an Agile environment. And the second question follows swiftly: who shall participate in the process—designers and business analysts or the engineers, too?
Read on and learn why personas are useful for product discovery purposes, how to create personas, and why the complete team—including the engineers—needs to participate in their creation.
Definition: What Is a Persona?
The term was introduced by Alan Cooper in his book The Inmates Are Running the Asylum (1998). (Source: Wikipedia.)
A persona is a fictitious character based on user research that represents a group of users or customers interacting with the product or service.
Benefits: Do We Need Personas?
Personas prove to be beneficial in supporting your team by understanding: Whom are they building (a product or service) for? Personas create empathy by showing a human “face” and giving an anonymous entity a name and a background. Personas introduce the “customer” to the day-to-day conversations of the product team. In other words: personas are a useful part of a product’s narrative.
Contrary to a piece of literature, though, the narrative of a product is neither “fixed,” nor is it created in advance by an author. It is vague in the beginning, and it may become more concrete over time—if you are lucky to achieve product-market fit. Hence, the product narrative is always subject to change of the life span of the product. Moreover, the best product story is created by a diverse group of observers and authors—the whole team, including the engineers.
Critique: Do We Really Need Personas?
The most common critique is that creating personas would eliminate the opportunity to find innovative use-cases. No one needed Twitter. Hence, no user research, no focus group ever presented this disruptive chance to anyone. Personas thus tend to favor waterfall-ish incrementalism instead of disruptive innovation. Lastly, personas come at a price. Preparing and running the research results at the cost of delay as well as opportunity costs.
Nevertheless, the author is convinced that in a majority of all situations, the advantages of creating personas as an integral part of the product discovery process outweigh the costs.
Make Personas a Team Effort: The Persona Team Workshop
Preparing a Personas Workshop
If personas are a worthwhile investment, what are the prerequisites of a persona team workshop? It turns out we need:
- Upfront market research, both quantitative (➜ surveys) as well as qualitative research (➜ user tests)
- An analysis of the research findings
- Probably, a persona template tailored to support the product discovery process
- All stakeholders need to attend the workshop to eliminate the risk of bias.
Designing a Personas Template
A personas template for a B2B product could comprise a subset of the following elements:
- A persona photo: it is the most engaging part
- A biography: name, age, education
- A quote to provide insight into the feelings and personality taken from user research
- A company: name, size, and industry
- The current role as a unique identifier among all other personas
- The context: where will the application be used?
- A goal: why is the customer hiring our product?
- A journey: To achieve his or her goal, what will the customer do now?
- The motivation and inhibitors of the customer.
Additional questions for the persona template could be:
- The persona’s relationship with other products/brands
- The persona’s previous working experience
- The persona’s most significant failures in previous jobs or projects
- The persona’s career plans.
It has also proven helpful to create a persona matrix that relates all personas of the application to each other.
Lastly, Dave Gray’s empathy mapping has proven to be an alternative route to creating personas instead of using a persona template.
How to Run a Persona Workshop with the Whole Team
People care about what they help create—this principle also applies to every part of the product discovery process. Therefore, it is vital that whole team—is a smaller set-up—or a fair number of representatives from each team participate in the workshop that creates personas. The following workshop agenda has proven to be useful:
- Start by dividing the large group into smaller groups of two to four participants each to introduce either your organization’s persona template or consider Dave Gray’s empathy mapping
- Now ask every group to create “their” persona. Set the time-box to 20 minutes
- After the 20 minutes, all groups shall present their persona drafts by telling that persona’s compelling story. This moment will take two to three minutes per group
- Next, compare all the different personas and identify patterns. For this purpose, all small group come together again as one large group
- Finally, merge similar drafts in a joined effort to form your persona in version 1:
- Merge two draft personas ➜ your persona v1
- Merge four draft personas first into ➜ two draft personas and then those into ➜ your persona v1
- Merge six draft personas first into ➜ three draft personas and then those into ➜ your persona v1.
Making Your Persona v1 ‘Real’
Now that you managed to create version 1 of your persona you must not hide it in a box but make it visible in the office:
- Print its LinkedIn profile on a poster and put the poster up in a prominent spot in the team-space
- Use the persona’s name in daily team discussions
- Based on the persona, reassess both the product roadmap as well as the product backlog regularly
- And most importantly: validate the persona during user interviews.
Note: Ensure that the team iterates on each persona alongside the product development. No persona is a static artifact; personas develop in sync with the product:
Beware of Persona Anti-Patterns, Fallacies, and Self-Fulfilling Prophecies
“I have a killer product idea, and I know exactly what to build for whom. Follow me.” There are many ways to fail at product discovery. However, admittedly, falling in love with your solution instead of the customer’s problem is the one reason all too human. While it is impossible to rule out bias, we can limit the adverse consequences by obeying a few simple rules:
- Never let one individual define personas upfront
- Never limit participation in the persona workshop to business analysts and UX designers
- Always collaboratively merge drafted personas
- Always iterate on personas over time
- Always embed personas in the team’s operational work.
Note: It is essential that you practice checks & balances with the whole team to avoid unconsciously selecting “users” that “validate” your beloved product idea. This is the rationale behind including all stakeholders—even the “expensive engineers“—in the persona creation and iteration process.
Conclusions—Create Personas with the Help of the Engineers
‘Take it to the team’ is a proven tactic that applies to everything related to product creation with a cross-functional team that works in an Agile way. The idea to create personas without the help of the engineers is hence not only counterintuitive. It also reveals that the organization in question seems to be clinging to outdated functional silos. Agile up—the earlier the engineers are involved in the product discovery, the sooner the team will learn to abandon stupid product ideas.
How do you create personas? Please share with me in the comments.
![[Case Study] Lessons from descaling 25 Scrum teams](https://www.agilealliance.org/wp-content/uploads/2024/12/descaling-teams-1200x630-1-150x150.jpg)
![[Case Study] Lessons from descaling 25 Scrum teams](https://www.agilealliance.org/wp-content/uploads/2024/12/descaling-teams-1200x630-1-300x158.jpg)
