This is a condensed extract about stakeholder interviews from a chapter of Joe Natoli’s book ‘Think First’ that he’s generously allowed us to re-publish. Scroll to the end for an exclusive discount for UX Mastery readers.
Conducting stakeholder interviews
Business goals come primarily from the folks who are carrying the most responsibility and risk for the project’s success: the stakeholders.
The unfortunate reality is that success for one stakeholder may not be the same as success for another. And should those goals be diametrically opposed, you may find yourself caught in the middle of a political battle.
One of the first critical steps for any project is to get the lay of the land; find out where each stakeholder is coming from and what they expect to happen.
Asking the right questions
In some cases you will be in a room with a lot of sharp people who already know they need to give you a thorough tour of what they’re doing and why.
But in many cases, you’ll need to ask for details. Because quite often, they may not understand why you need to know something. So unless you ask, they may never share some mission-critical knowledge.
There are more than a handful of questions that you should ask of every business stakeholder, every time. This includes defining customers, business goals, and where the product sits within the company’s overall business strategy. (see the book for a list of questions)
Evaluating answers (when to keep asking questions)
You want specific, measurable answers, and you have to keep pressing until you get them. The measurable part is important here — because If you can’t measure something, you probably can’t achieve or manage it. Why? Because you’ll never know if you’ve reached it.
Specific, measurable answers should sound something like this:
“We want to cut the time it takes customers to sign up by at least 30%.”
“We want to cut the number of calls to our call center in half within six months.”
“We want to decrease our shopping cart abandonment to less than 3%.”
Those kinds of answers point to the places you need to begin looking at in order to understand the problem. The more specific the goal, the easier it is to figure out what kinds of things will contribute to reaching it.
Pushing for specific answers like these also goes a long way in avoiding an all-too-common situation where you’ve got a lot of people on a team and none of them see the project the same way. They have very different ideas about what success means, very different ideas about what needs to be done.
What’s more, each person has very different motivations for their perceived goal. Some of those motivations are personal, some are political, and some are directly related to the harsh reality of someone simply trying to hang on to his or her job. You want to uncover as much of that motivation as possible so that you can properly frame each person’s input.
A good friend of mine related a story a while back that has always stuck with me. It’s a simple, understated exchange or words that on the surface may not seem like much. In reality, however, it’s the equivalent of an ear-splitting air raid siren, warning you that you are headed into dangerous territory. And it also suggests that there are more than a few questions to be answered. Here’s how the story goes:
Years back, my colleague was partnering with an IT firm, building a services portal for a large financial services client. The IT firm was handling all aspects of design & build; my friend was on board as a consultant. During that time they had dozens of conversations that went like this:
CEO: How long will it take you to make this feature list reality?
PM: This is a long, complex list. We need 14 months, at bare minimum. And to be honest, we’re not convinced that our current server environment will support half of what’s on this list.
CEO: WHAT!?! No. No way we can wait that long. This has to be live in six months.
When that deadline wasn’t met, the project ended in disaster. The IT firm was subsequently fired, and the resulting bad blood was hard on everyone. Some of you are shocked, and some of you are laughing knowingly. This happens more often than any of us would care to admit. The Project Manager immediately caved into the CEO’s demand, despite the fact that (a) the delivery date was logistically impossible and (b) absolutely nothing in that exchange of words made the CEO’s deadline any more achievable.
So when you’re in this situation, in my colleague’s shoes or the Project Manager’s shoes — or just an observer — you want to push for a much more realistic approach and outcome. In other words, ask more questions, such as:
What is the worst thing that happens if we don’t deliver by this date? You’re trying to find out whether the proposed schedule is actually driven by a specific event or consequence, instead of personal fear or desire. Or by the knee-jerk need to answer everything with “ASAP.”
If the date can’t move, which features & functions absolutely have to be in place by then? More often than not, everyone will come to the realization that only certain things have to be accomplished in the initial time frame. And that having those features in place and working will buy the team more time for everything else.
Can we get more time, money or resources? Can we expand the budget to hire a few additional people? Are there internal folks we can pull from other projects to help us? Will expanding the schedule by two weeks cause any major consequences? Something has to give; you have to figure out what that is.
Does it have to work or look perfect by that date? Quality is another thing that can be sacrificed (within reason) in a compressed time frame. Consider what things users may overlook if they get something else in the meantime.
To wrap this up, I’d like to share something I heard a consultant say almost a decade ago. It’s always stuck with me, because it’s one of the best pieces of advice I’ve ever received:
Silence equals agreement.
If you say nothing about something you think is not possible, or that you believe is dangerous, you are not only agreeing that it’s the right thing to do — you are also agreeing to do it.
Love what you’ve just read? To keep reading and find out more about the situation mapping template, grab a copy of Joe’s ebook ‘Think First’ to read the whole approach to creating successful products, powerful user experiences and very happy customers.