| back to the List |
As design professionals, our effort is guided by our understanding of the user. Everything we do, we do in the hopes of making someone’s life a little easier. But not everyone involved with the project thinks this way. Although I’m usually working with people who, like me, want to serve the needs of the folks using the product, those people report to stakeholders who rely on a different north star. (I might argue that the emergent tension in the direction for the design is good for the process, but that’s a tale for another book.) With this question, I’m opening the door to talking about stakeholder management. Producing a good product is more than just coming up with a good design: it’s ensuring that the people who affect movement toward an outcome build momentum and not inertia.
In my world, as a design consultant, I usually have one person who is accountable for the outcome of the project – perhaps a product manager or product owner. They’ve brought me in to build the team’s capacity and skillset to produce a good product. I understand that on paper that’s my role. But in practice, my role entails helping the product owner keep the project on track – minimizing disruptions by ensuring everyone has a voice in the process, everyone feels heard, and everyone understands the direction we’re going. This is the person I ask, the one who is ultimately responsible for not just producing the the product, but delivering on the promised outcomes. They’re the ones with stakeholders who are most likely to intervene. At best these stakeholders are concerned about the same things the rest of the team is. Their interventions are disruptive but welcome because they inject useful perspectives. At worst, stakeholders come with a raft of concerns unrelated to the core problem. Best to know about both of these as early as possible so that I, as a contributor and perhaps leader on the project, can support the product owner as they manage these interventions.
In some cases the product owner maintains a rosy view of their stakeholders, assuming they have the same concerns as the rest of the team. Do not take their assertion at face value: The proof is in the pudding. Product owners who are even a little jaded understand that every stakeholder has buttons that need pushing. Perhaps they’ll tell you that a certain turn of phrase needs to be part of the strategy, or that every decision must be supported with quantitative data. A good product owner knows what their stakeholders respond to positively – and what might turn a minor intervention into a major disruption.
You’re looking for insights on what details about the project the stakeholder will pay closest attention to. Perhaps they’ve had personal challenges with certain features on other sites – search or check-out, for example – and this looms large in their imagination as they look at your project. You’re also interested in learning about their potential hang-ups in terms of process or approach. They might have had bad experiences with user research or information architecture in the past.
This is one of those questions that has both a macro view and a micro view. Asking this at the beginning of the project, say in a kickoff, hopefully uncovers the larger concerns of the at-large stakeholders. These larger concerns might be a strategic direction, an aspiration that the product supports the company in some way. But more typically, these “larger” concerns aren’t strategic, but only loom large in the imaginations of the stakeholders – deadlines and budgets, for example. They may have a particular feature that they desperately want to see.
But this question also comes up at moments throughout the process, especially key inflection points like a specific deliverable or design review that the stakeholder themselves is involved in. I ask this question to shape the central message of that moment, the themes that I’ll attempt to hammer home when engaging with the stakeholder.
ALTERNATE
ALTERNATE