Using Stakeholder Personas to Increase the Chance of Success

Building great and useful software is hard. Doing it within the enterprise comes with its own unique set of challenges. When there are an endless number of potential landmines, how can we maximize our chance of survival and success? These challenges are exacerbated because the people controlling the purse strings often have different goals from the people we are building the software for.

It would be nice to believe that we could simply follow the principles of Human-Centered Design and focus exclusively on the pain points of our users, we need to understand the environment we are designing within. Critically, if we design the best solution for the end-users, but it never is released because it is killed by political entanglement, then can we really state it was the best solution for the users? And unlike a startup, where once you raise funds you typically get to spend it all, in the enterprise you can have your funding pulled (or more granted) with a single phone call or meeting.

While collaborating on a number of enterprise engagements with our colleague Greg Larkin, we created Stakeholder Personas to help our teams and our clients’ teams align and empathize with the key players in the ecosystem beyond our core users.

Personas and proto-personas are great tools to help teams empathize with the people we are building solutions for. Personas are a way to communicate user needs and motivations identified through research. Proto-personas aka “provisional personas” are based on the inherent knowledge of the team and can be a good starting point to help a team get away from self-referential thinking. Even if we think we are the ‘user,’ we are not – personas help the team differentiate your customers from the people on the team and be empathetic towards them. We’ve found that teams that use personas create more usable and user-friendly solutions.

When we created Stakeholder Personas we based them off of the traditional proto-persona template, but we extended the template to more accurately reflect what is important for us to understand in a stakeholder’s world.

When creating stakeholder personas, we use the categories “Actions / Day to Day”, “Aspirations for Self”, “Aspirations for Company”, “Fears for Self” and “Fears for Company”. Given that we are designing a solution within an inherently political organization (every enterprise is political, deal with it!) we must factor in what is important for our stakeholders personally as well as for their organization. We occasionally will expand the categories within our personas to more specifically align with a project.

Here’s our stakeholder persona template:

(Download Template PDF)

Actions / Day to Day – We start by trying to understand each stakeholder’s role and responsibilities. What does their day look like? Who reports to them and who do they report to? What are they measured on?

Aspirations for Self – To be successful in today’s dog-eat-dog world, we must understand an individual’s goals. What motivates them and what do they want to personally accomplish? Why are they at this company? Some stakeholder needs exist solely to help these individuals advance in their careers. Understanding and aligning to stakeholder aspirations can help our product succeed.

Aspirations for Company – Self-advancement is frequently, but not always, tied to company performance. At the senior stakeholder level, there can be many distinct desires or goals for the company. We need to learn what each stakeholder believes is most important for the company’s future success.

Fears for Self – The flip side of aspiration is fear. What keeps these individuals up at night? When things go south, self-preservation sets in. Almost everyone will eventually try to cover their ass (CYA) and limit their fall. We must understand what each stakeholder is scared of, as this insight can help us know what to steer clear from or what solutions or OKRs could alleviate these fears.

Fears for Company – Ultimately the fears for self are typically grounded on a desire to not lose their job, most senior stakeholders are proud of the company they work for and want to see it flourish. Like understanding where their personal potential pitfalls are, it is important that we know what they feel are the biggest risks for the organization. Your product should either tackle these risks head-on or avoid them altogether.

In our experience, crafting stakeholder personas helps teams better understand why certain product decisions may exist and why a stakeholder may request a certain feature. Keep an eye on where differences lie between stakeholders. These conflicts are often the areas where projects can get stymied in political quicksand.

Once we’ve begun to understand the stakeholders motivations, we can include some Stakeholder Stories alongside our user stories in our Kanban board for each sprint. These may be explicitly requested by a stakeholder or we may preemptively create some based on our understanding of the stakeholders. We recommend limiting the number of Stakeholder Stories per sprint – the overwhelming majority of your stories should be driven by user needs.

We’ve found that by using a similar format to user stories, the team understands that we might need to build a feature that isn’t necessary for the end-user, but it is critical for the overall funding success of our project. And in the end understanding the stakeholder personality increases our chance of launching a product successfully in the enterprise.