STAKEHOLDERS, USERS AND PERSONAS

Newsletter sent on Tuesday, Aug 22, 2023

Distinguishing between stakeholders, users, and personas early in your project or product design efforts is crucial – it prevents conflicts and misunderstandings, improves adoption and engagement, reduces waste and streamlines prioritisation. Let’s unpack this together.

A way to capture the difference:

Stakeholders are those, who are directly influenced by the outcome, but typically don’t have a direct influence on the process.

Users are the individuals or groups who directly interact with the product or benefit from the project’s outcomes. They are the end consumers of the product or the recipients of the transformation effects brought about by the project.

Personas are fictional representations of specific user segments. They are created based on user research and data, embodying real users’ characteristics, goals, challenges, and behaviours.

What’s important to remember is that Stakeholders and Users are both influenced by the outcomes, but the User’s effect is a necessary precondition of the Stakeholder’s effect. In a primitive case, Stakeholder and User can be the same (e.g. manager making a spreadsheet to automate some calculations to save time). But Stakeholders can only meet their goal (e.g. save time and have an audit trail) by addressing the spreadsheet user’s needs for correctness, cross-device availability, support of a particular data format, etc. This separation remains true, and it becomes trickier to keep the focus of a product designer when stakeholders are different persons.

Personas are theoretical models we can derive from learning about actual or prospective users, existing workflows, goals, and challenges. Users with similar goals and challenges represent the same Persona.

Having well-established and accurate Personas in place allows you to:

• Map features and check their soundness against the purpose of solving users’ problems and enabling them to achieve goals.
• Assess and size your iterations – obviously, the more Personas you target – the more complex your (minimum viable) solution will become.
• Maximise impact and isolate experiments – you’ll get more accurate feedback and measurements by making something that solves 80% of pain points for one Persona rather than 20% for each of four Personas.
• Balance multiple personas by recognising connections between each other’s goals, actions and goals of stakeholders. Solving an overlapping (even small) segment of the needs of two Personas whos interaction is crucial for Stakeholder’s goal will probably have much more impact than designing and building anything else.

For existing business processes, there is typically a clear connection between the Stakeholder’s business-level goals and Persona’s operational-level goals and challenges. Exploring those is the best thing you can do at the beginning of an improvement process. On the other hand, this connection needs to be explicitly designed and validated for greenfield projects via value stream mapping, alignment activities, MVPs and user interviews.

To summarise – each of these concepts: Stakeholder, User, and Persona, represent different aspects of the people who interact with your product, and understanding their roles and needs helps guide the design process effectively. Design decisions that align with stakeholder goals can prevent conflicts and misunderstandings later. Understanding Users’ needs and behaviours is crucial for good adoption and engagement. User insights captured in Persona create focus, reduce waste and guide feature development by addressing the most common and essential user needs.

It makes the most sense to perform the analysis in the same order I mentioned here, but disregarding either of the concepts would be a mistake. Reply to this email if you have any questions about some practical aspects of the discovery process that should precede any architecture, planning or implementation work.