Deliverables / Process and Methods / Reading List

The General Stakeholder Interview

Posted by

This is an excerpt from from Kim Goodwin’s excellent Designing for the Digital Age. It is quite long, so we’ve broken it into several sections. Many thanks to Ms. Goodwin and Wiley for allowing us to share this with our readers.

Topics applicable to most stakeholders

Try to keep the interview conversational rather than reading from a list of questions, but consider writing a list of topics on the inside cover of your notebook where you can glance at them when you get stuck. These are some questions applicable to most stakeholders; topics specific to particular stakeholder roles follow. Note that it’s as important for in-house teams to ask most of these questions as it is for consultants; you may know one answer, but do you know this particular stakeholder’s answer?

What’s your role with respect to this product?

If you’re a consultant, the reason for this question is obvious, but even if you’re an insider, you or one of your teammates may not understand someone’s role as well as you think you do. It’s also an easy, non-threatening way to get the conversation started.

What did you do before this?

Answers to this question will tell you whether this person has some unexpected expertise to share and will give you some clues about how this person might view the world; a product manager who has a background in the domain but not in product management won’t have the same concerns as an experienced product manager who doesn’t know the industry.

What is this product or service supposed to be?

It’s interesting to see what aspects of the product or service each person emphasizes. One of the key things to look for in the response is any hint of functionality no one has mentioned before, since this is important not only in helping the product team achieve consensus, but also in keeping the project timeline within bounds. Some stakeholders will answer you with an impenetrable wall of buzzwords: “It’s a distributed, service-model three-tier architecture that will leverage existing technology,” and so forth. In such cases, ask them to break down what that means by asking how they would explain what it does for the average user.

You’ll also want to ask the reverse of this question: What is the product not meant to be? Some stakeholders have difficulty being realistic about what they can accomplish, so it’s important to build consensus about boundaries as well as goals.

Expect a wide range of answers. With respect to software, this diversity is usually due to what people think will be in the first (or next) version versus what will be in later versions. You may be able to clear things up by asking each interviewee to compare the immediate release to what the product will eventually become.

Who is this product for?

Although the marketing or product management people have the most informative answers to this question, the range of answers from other stakeholders can highlight issues your research will need to address. It’s also important to know what assumptions there are about users so you can test them and see if they’re true.

There may be variation due to a poor understanding of who the users are. On a recent project, for example, one stakeholder told us the product was going to be so indispensable that executive users would want to log in remotely from the airport, while another told us executives would only consume monthly reports generated by subordinates. Both agreed that executives were the targets for the information, but they had differing opinions about whether executives would see the information as so mission-critical that it had to be accessible at all times. This sort of variation doesn’t mean the organization is dysfunctional; it just means people need better user data to clarify things.

When is the version we’re designing going to be released?

It’s normal to hear optimism from the marketing and sales people and pessimism from the engineers, but if the answers to this question differ by more than a month or so, mention it to your project owner. Also, don’t forget to ask why the timeline is what it is. Sometimes there’s a serious mismatch between goals and timeline—stakeholders may say this project is going to be the basis for all of their products in the next ten years, but they want to launch it in just a couple of months. Don’t just let this slide; it will bite you later. Instead, point out the apparent contradiction and ask about it. “You’ve said the product has to be all things to all people. You’ve also said it has to ship by the end of this year. Those two things are potentially conflicting. Which is more important and why?” A reasonable executive stakeholder will clarify what the priorities are.

What worries you about this project? What’s the worst thing that could happen?

This is a good topic for the later part of the interview, after the stakeholder has relaxed a bit. Sometimes the anxieties will be things you can help with, such as worries that the product won’t have the right functionality. In other cases, the worries may point out organizational weaknesses you need to be aware of. While engineers always worry that there won’t be enough time to build the product the way they’d like to (and they’re always right), listen for truly unrealistic expectations. You may hear concerns beyond the usual level of grumbling that one part of the company is not up to doing what it needs to. If you hear that the marketing team is largely inexperienced in the product development world, you may be able to help by educating as you go. If it appears the engineering team is less capable than most, you’ll either need to suggest some additional engineering resources if you’re in a position to do so, or you’ll need to be fairly conservative in your design.

What should this project accomplish for the business?

In a highly functional company, most stakeholders can answer this question to some extent, but it’s amazing how often a senior executive is the only one who can do so. When this happens, you can help the organization by disseminating the business goals during the design process.

If stakeholders struggle with articulating this, try asking more specific questions: How will this product generate revenue? How will this product save money? How should this product affect the company’s brand and position in the marketplace? What should the company be able to accomplish with the product that it hasn’t before?

How will you, personally, define success for this project?

Many stakeholders will simply reiterate the business goal, or they’ll say the thing they’re most worried about won’t happen. Some will give you insight into other things that worry them or what will get them excited about the design. You might hear things like, “If we just avoid this problem we’ve had before, I’ll be happy,” or “Other people in the company will finally see the value my team can offer.” Understanding these issues is essential in building support for the design.

Is there anyone you think we need to speak with who isn’t on our list? Who are those people?

Ask this one toward the end of the interview. Check in with the project owner later to see if discussion with any of the people mentioned is really a good idea.

How would you like to be involved in the rest of the project, and what’s the best way to reach you?

This is a good one to save for last. It’s an especially good opportunity to make sure the senior people stay involved at key decision points. If you have a middle manager who’s reluctant to involve senior management, this gives you room to say “The CEO specifically said she wanted to be involved in that meeting.”

See also

Excerpted with permission from the publisher, Wiley, from Designing for the Digital Age: How to Create Human-Centered Products and Services by Kim Goodwin. Copyright (c) 2009.

About Kim Goodwin

Kim Goodwin is the author of the bestselling book, Designing for the Digital Age. Kim is currently consulting for clients in varied industries including aviation, consumer electronics, and retail. She spent most of the last decade as Vice-President, Design and General Manager at Cooper, leading an integrated practice of interaction, visual, and industrial designers and the development of the acclaimed Cooper U design curriculum. Kim has led projects involving a tremendous range of design problems, including web sites, complex analytical and enterprise applications, phones, medical devices, services, and even organizations. Her clients and employers have included everything from one-man startups to the world’s largest companies, as well as universities and government agencies. This range of experience and a passion for teaching have led to Kim’s popularity as an author and as a speaker at conferences and companies around the world.