Understanding the Business

Identifying Stakeholders and Scheduling Interviews

If you’re an insider, you may already have a good idea who the influential stakeholders are. You may also think interviewing them is not necessary, but avoid this trap; hearing that executive’s point of view filtered through middle management isn’t the same as hearing her thoughts in her own words. If you’re a consultant, ask for your designated project owner’s help in identifying stakeholders. Give that person the list of roles that are usually important to involve; then advise him to include anyone else who has information you might need or whose opinion has the potential to derail the project later.

The number of stakeholder interviews varies quite a bit from company to company; a small startup may only have two or three, whereas a large corporation might have 50 stakeholders for a highly visible, political project, such as an intranet or corporate Web site.

In reality, you’re not likely to have 50 people who have significant influence on the direction of the project, but some organizations don’t do a good job of distinguishing between interest in the project and influence over its direction. If you don’t have time to interview them all, prioritize individual meetings with the decision-makers, top influencers, and people who have vital information, then conduct a brief group session with the rest.

Prioritize individual meetings with decision-makers, top influencers, and people who have vital information.

Conduct stakeholder interviews in person when possible; it’s easier to develop a rapport when you’re face-to-face. Also, it gives stakeholders a chance to assess your credibility and good will, which are important to establish early on.

Try to speak with stakeholders individually. When it’s necessary to group a few stakeholders together, keep them grouped by role (e.g., talk with several engineers and then several salespeople, but don’t mix the engineers and sales people). You need to hear about who is frustrated with whom and what the range of viewpoints is.

When scheduling stakeholder interviews, plan on having the whole design team attend, since every one of these discussions is likely to contain vital information. Allow for about an hour with most stakeholders, sometimes two hours with a technical lead or subject matter expert. Also plan on longer interviews if you and the stakeholder are not fluent in the same language; you will at least experience some long pauses as you both think through your communication, even if you don’t require a translator. Ask the stakeholders ahead of time to gather any white papers, specifications, or other information you think might be useful. The following sample invitation provides an example request for stakeholder participation.

Example of an invitation to stakeholders

As you may know, my colleagues and I are responsible for the product’s design. We understand that you are ultimately responsible for marketing Product X. We’d like to schedule a one-hour meeting with you next week to discuss the project. We’ll ask questions about your vision, goals, and concerns, as well as the role you expect to play in the project. We’d like to take advantage of your expertise, too, so we’ll have plenty of questions about XCorp and the industry. We would also appreciate it if you could share any useful documents, such as MRDs, white papers, or competitive product information.

Within your team, outline the key topics you want to cover with each stakeholder. After each team member has done several projects, you’ll find that preparation is minimal, since the information you need from each sort of stakeholder is fairly consistent from one project to another.

Beware invisible executives. A friend of mine calls them “torpedoes”—previously unseen stakeholders who can sneak up at high speed and blow the project out of the water. The product manager may seem to have total authority, but that’s only true as long as the CEO or other senior manager agrees with the project’s direction. If an executive sees something he doesn’t like or understand, the project could experience a 180° turn at any point.

Identifying the final authority can be difficult; the project owner is often oblivious to the potential for executive intervention. Listen closely in stakeholder interviews to identify likely issues. For example, “We tried to go that direction, but Dan hated it,” should prompt you to ask, “Who’s Dan? I haven’t heard his name before….” Another option is to ask each stakeholder you interview if there are any key influencers not already on your list.

Once you have identified these people, it can still be tricky to get the project owner to let you talk with them. I use examples from past projects to make my case.

On the negative side, I describe a couple of projects in which senior executives who were excluded for months disliked the final design because they hadn’t been part of the thought process that got us there. In one case, we smoothed things out within a few days, but the other took several months of comparative usability testing before we could move on.

On the positive side, I describe another project in which the client’s internal project team had shown idea after idea to an executive, only to have him reject every one of them. As a result, they tried to “protect” our design team by excluding that executive from our interview list. We insisted on doing something the internal team hadn’t done: we spent an hour asking him about his concerns, objectives, and ideas. It didn’t take long to understand why he had rejected the earlier designs. When we later presented our initial concept, he said, “That’s what I was looking for!” If we had not understood his concern, we might have gone down exactly the path he didn’t want to see.

Officially “Kicking Off” the Project

For some reason, the business world is rife with military and sports-related language: deploy a product, kick off a project, employ tactics…perhaps it’s because in business, just as in sports and the military, we have to rally the troops and get everyone on the same page of the playbook? Regardless of what we call it or why, an official project kickoff meeting is useful for several reasons. It:

1. Draws everyone’s attention to what may be a major effort.
2. Sets expectations about how much of their time will be required and when.
3. Gets all of the key stakeholders in the same room at the same time to discuss goals, deliverables, assumptions, and timelines.
4. Exposes the whole team directly to the executives’ vision, often for the first time.

Depending on how familiar the project is and how large the team is, a kickoff meeting will take anywhere from one to two and a half hours. After introductions, start by re-capping your understanding of the project’s goals and parameters, then walk everyone through the project plan and a high-level overview of the method. Often, there are multiple people in the room who weren’t involved with defining the project’s parameters (or the decision to hire a consultant, if you are one), so chances are this is information they need. Highlight the dates of critical meetings (such as the presentation of findings, personas, and requirements, as well as the design framework discussion) and ask everyone to reserve them, since you’ll need a full complement of stakeholders involved at each key decision point. See Figure 5.1.

The research plan might engender controversy if it’s already been determined. Hopefully, the most knowledgeable stakeholders have had a hand in its creation, but in most organizations, everyone has an opinion. Make a note of any suggested additions or changes to the plan, then check in later with your project owner to determine what, if anything, you should do about them.

Whenever possible, have a group discussion centered on a few basic stakeholder questions. This is easier with some groups than with others. In a small group of stakeholders who are comfortable with one another, a simple facilitated discussion can be very effective. A group that’s large or very conscious of what the most senior person in the room thinks may call for more elaborate facilitation tools.

Write several essential questions on large sheets of paper and tape them to the walls, then give everyone a pen and some sticky notes to use in responding to the questions. Any of the questions from later in this chapter might be useful, but good starting points include:

1. What is the product?
2. Who will use it?
3. What do users need?
4. What customers and users are most important?
5. What challenges do we face?

You can get creative with this and use different colors to distinguish hopes from concerns or facts from hypotheses, but don’t make the color coding so elaborate that people have to think much about it. Once you’ve gathered everyone’s thoughts, walk through them with the group, pointing out where there seems to be consensus. Use contrasting points of view as a basis for discussion with the large group, then pursue those topics further during the individual discussions.

Once the kickoff meeting is done, you’ll proceed into stakeholder discussions. It’s ideal to start with one or more of the executives primarily responsible for the vision, followed by several other stakeholders. Consider saving your project owner or one of the primary vision-keepers until the end, since that provides a good opportunity for clarification if you’ve heard a wide range of responses.

Conducting Stakeholder Interviews

Have one team member lead the discussion so the stakeholder doesn’t feel overwhelmed. All design team members should take notes, though one person should be designated as the primary note taker. This is usually one of the interaction designers, since these two people attend all of the interviews. When the stakeholder is primarily concerned with brand or physical hardware as opposed to product definition or software, the visual designer or industrial designer should lead the discussion. Team members who aren’t driving the interview should, at a minimum, have a chance to ask a few questions before the primary interviewer changes topics, as well as at the end of the interview.

Getting started

Hopefully, each stakeholder has attended the project kickoff meeting and is already acquainted with the basic goals and timeline of the project; if not, that’s a good place to start the discussion after everyone has been introduced. Before you start asking questions, talk about the way you’ll be approaching the interview. One essential disclaimer is something like, “We’re going to ask some deliberately naive questions. That doesn’t mean we haven’t done our homework—just that we want to hear your point of view.” Without this disclaimer, I’ve seen stakeholders go back to the project owner and ask why they hired such dumb designers who clearly know nothing about the business.

You might also reassure interviewees that you won’t quote them to anyone else, although you are obliged to tell the project owner in general terms when you hear significant disagreements. This kind of anonymity is something an outside consultant can insist upon, but is harder to manage if you’re an insider.

Things to watch out for

When it comes to design, everyone has opinions. You absolutely need to hear these ideas from stakeholders for a couple of reasons; first, there may be value in them, and second, telling the CEO you don’t want to hear her design ideas is unlikely to help your career. Of course, you also need to know what everyone’s pet ideas are so you can explain later why you didn’t take that direction with the design.

However, don’t take these assertions at face value—if the stakeholders had the design problem solved, you wouldn’t be there. Keep in mind that some people—especially busy executives—communicate by proposing solutions when what they really mean is, “I see a problem and I want you to fix it.”

One of my clients had a running joke about how an executive would see an idea for the hardware design, sigh, flip open his cell phone, and tell them to make the large, complex device more like the phone. The whole team was frustrated because their complex medical device didn’t have much in common with a cell phone, and the executive was frustrated because his team wasn’t getting it.

What he really meant was that they weren’t exploring any ideas with hinges or moving parts, which would allow the bulky device to take up less space when not in use (resolving a common customer complaint with the existing device). The moral of the story is this: When you hear someone propose a specific solution, listen to the proposal, then ask what problem that solution is meant to solve.

You may also hear long lists of constraints, musts, and deadlines, not all of which are as real as people believe them to be. Always ask why the stakeholder believes an assumption to be true. One of the more common assertions is that the product has to be browser-based—in 2001, I think I heard that on every project I did; today, people seem to be a little less thrilled with the idea, but it still comes up. This belief exists either because the customers are asking for it (and no one has asked the customers why they want it) or to avoid the need for individual workstation installation, which can be addressed in other ways.

Deadlines are another good example. Although some deadlines are driven by external forces, such as the need to show something new at a critical industry event, others are arbitrary targets the management team sets because they’re afraid of the product that never ships. If you know what’s driving a deadline, you’ll know whether it might be flexible.

The other thing to look for in stakeholder interviews is points of difference. In a perfect organization (if there is such a thing), all the stakeholders will say much the same things about the product, the customers, and the timeline, but some variation in views is normal. Pay attention to any extreme differences, as these represent both risks and opportunities. The risk is that such divergent perspectives could cause headaches in your future or derail the project entirely. The opportunity lies in using your later research data to help resolve those issues.

These are all the section in the chapter. We hope you’ll enjoy!

• Understanding the Business
• The General Stakeholder Interview
• The Marketing Stakeholder Interview
• The Engineering Stakeholder Interview
• The Sales Stakeholder Interview
• Interviewing Executives and SME Stakeholders
• A Stakeholder Interview Checklist
• Project Management for Stakeholder Interviews

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.