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.
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.
Personas prove to be beneficial 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.
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.
The latest, 174 pages strong version of “Agile Transition — A Hands-on Manual from the Trenches” is available right here, and it is FREE!
If personas are a worthwhile investment, what are the prerequisites of a persona team workshop? It turns out we need:
Please click the “clapping hands” 👏_, if you found this post useful–it would mean a lot to me!_
A personas template for a B2B product could comprise a subset of the following elements:
Additional questions for the persona template could be:
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.
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:
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:
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:
“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:
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.
‘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.
28 Product Backlog and Refinement Anti-Patterns
Product Discovery Anti-Patterns Leading to Failure
Download the ’Scrum Anti-Patterns Guide’ for Free
Please click the “clapping hands” 👏_, if you found this post useful–it would mean a lot to me!_
Do you want to read more like this? Well: