Anytime we create a product or service, there are constraints that we must operate within. Some come in the form of laws and regulations handed down by governments. Others originate from a higher power that can make your work significantly more comfortable or more difficult depending on how you interact with it.

Of course, the higher power I’m talking about is the stakeholder.

By definition, a stakeholder is someone whose support is critical to the success of your project. That description is broad and likely to apply to many at the organizations you’ll find yourself working with. Some of the people you’ll need to speak with are apparent, like executives and mid-level managers, but remember that the definition could also steer you to customer support reps because you’re looking for anyone “whose support is critical.”

The key is to cast a wide net. So don’t overlook the sales team and you won’t have a problem later.

Another party you want to seek out are any designers who previously worked on the project. This connection is a potential goldmine of information. While it could lead to an awkward initial conversation, you can gather the critical organizational insight and build strong alliances here. As Mike Monterio points out in Design Is A Job, “Their internal knowledge will be a fantastic resource to someone coming in cold. ... You can both do things the other can’t. Together you’re a stronger team than you are apart.”

You won’t likely start with a complete list of stakeholders to interview — though some names will likely be provided. Stakeholder interviews are is part of the discovery process for a reason, so allow time to perform a second round of interviews with people you didn’t initially identify.

With the people issue addressed, let’s take a moment to discuss the interview itself.

Interview preparation

Before sitting down with anyone for a formal interview, there are several steps needed to ensure the best possible outcome.

This interview provides an opportunity for you to understand the priorities of the organization.

• How do people view this project?
• Is it crucial to the growth plan of the organization, or has it been kicked around for several years?
• Is this project caught up in some form of internal turf war?

Questions like these are typically answered by distilling the answers from several people, as the perspective of people in marketing, development, and sales are likely different.

For you to do your job well, you have to establish credibility with the people you are interviewing. You need these people to trust you, and the easiest way to gain their trust is to come into the interview prepared.

Interrogaing "the requirements"

Almost every project begins its life with a list of requirements. These are typically found in an RFP (request for proposal) or in a similar internal project kickoff document.

Any initial list will likely be limited to high-level business requirements. For example, “Our goal is to expand into market X to better leverage our strategic advantage in Y” does an excellent job of explaining why the project is vital to the company — but it does little more than that.

Regardless of the name on the top of this list, this is a list of assumptions and guesses made by an individual or team associated with the project. Some of the items listed may prove to be very helpful, but this initial list is an incomplete view of the task ahead.

Also, be wary of initial requirements that are heavy on implementation details. Such items should raise a flag that you are being asked to create something a specific way, not determine what should be created. As stated, we’re not even sure what the problem is yet.

That doesn’t mean you ignore this list. In fact, there is a wealth of information that has nothing to do with the product that is illuminated by the contents of the list.

Most lists are devoid of indicators that would make it easy to determine when a project was considered to be successful — or even complete! It’s crucial to uncover these criteria because it helps establish the scope for the endeavor. Without a clear understanding of what the product should do when finished, you could find yourself in a neverending cycle of scope creep as seen below with the Bradley Fighting Vehicle.

While you won’t likely be designing weapons of war, scope creep is real, and your ability to establish requirements for your project is your best defense against it.

Conducting interviews

Aside from being aware of the stated objectives and “requirements” that have been presented, you want to perform some discovery on the people you’ll be talking to. Understanding a bit about their background can be useful to break the ice as an interview begins. It will also signal to the subject that they should be straight with you as they have no idea how much information you already know.

Regardless of the setting, you want your interviews to be relaxed affairs. Inform everyone from the outset that the information you are collecting is confidential and will only be shared as part of a complete analysis later. If possible, provide a document from a manager or the HR team that states this explicitly.

Try to schedule all interviews to be one-on-one. People are far less likely to speak openly in other settings and will often fall into groupthink when interviews are conducted with entire teams. If that isn’t possible, try to limit the size of groups as people won’t have an opportunity to talk once an interview involves more than a few people.

While it might seem obvious, assume that no one knows who you are or what this is about. People are busy and could become defensive if you walk in and begin diving into your questions. Enter each interview in a calm, relaxed manner taking time to introduce yourself, the purpose of the meeting, and the amount of time that it will take.

Always underpromise and overdeliver on the time part. If you need 15 minutes, tell them it will take 20. They’ll appreciate it when you wrap up sooner than your earlier estimate.

Have questions ready

Nothing will derail your interview faster or damage your credibility more than drawing a blank at the beginning of your meeting. You should have at least 5-to-10 ready to use. Based on participant answers, you will likely ask slightly different questions of each party interviewed but try to ask this core group of prepared questions of everyone, so you have a guide to compare common answers against.

Your questions should be open-ended to encourage answers that get the subject talking to you. Below are a few that you could use as a starting point:

• What is a typical day at the office for you?
• How could your company be better meeting the needs of its current customers?
• What is currently the most critical priority for the organization?
• What teams will this project impact the most?
• Will this project force any team or department to change dramatically?
• From your perspective, what would success for this project look like?
• Do you have any concerns regarding this project?
• If this project fails, what do you suspect has occurred?
• How can our team help you going forward?

Finally, as Erika Hall explicitly points out in Just Enough Research, “never ask anyone what they want.” By asking the right questions and listening carefully, you’ll be able to answer that question better than the subject ever could.

Requirements building

As much as your client would like for you to have a clear picture of what should be built by this point, you won’t be able to give them that. You can reflect back to them a clear picture of what success would look like for their organization. Finding the metrics that determine success are the actual business requirements.

The document you produce to share back with your client team is intended to bring everyone into alignment regarding what success looks like and what the scope of the project will be. This is important because once in agreement, all discussions of timing and budget come back to what was agreed upon here. Any changes to the agreed-upon requirements will cost both time and money.

While the business requirements can become a stick, don’t use it as one. A calm review of the requirements is different than shouting “that’s not what we agreed upon.” Always lean toward the calm option.

The requirements you create should:

• Identify the problem or assumption to be researched
• Set clear project goals/success metrics
• Define the scope of the project
• Outline the approval process
• Include a provisional project timeline

In addition to the items listed above, the requirements document should include any known risks or concerns that were identified through the process of your interviews. Getting these items into the documentation will help you and the client through rough patches should any of these issues come to fruition as your project progresses.

The documentation you create should be shared in person with a group of key stakeholders so that you can talk through any issues that might pop up during the review of the document. While it is always risky to send work along to ‘sell itself,’ this particular document should never travel alone as you are just beginning to build trust among the project participants.

Associated Exercises

Article/Video	Source/Author
Active Weekends Project	New Pragmatic
Fresh Market Project	New Pragmatic