Skip to main content

Tapping into tacit knowledge with stakeholder interviews

A pattern representing affinity diagramming.

One of the most common conversations I hear amongst designers is which tool they like working with the most. They’re usually referring to graphic editing software like Figma, Stretch, or Adobe but when I was asked the other day, and that wasn’t specified, I gave a different answer. Over the years, I have come to learn that the quickest way to learn anything is to speak to people. Whether it’s talking to subject matter experts so you can ramp up on a new topic or with customers to evaluate the qualities of a design, I always walk away feeling more prepared to deal with what comes next.

This was recently the case when I joined the domains team — a new area of the product for me. I was brought on to help lead efforts in improving our domain management tools but knew very little about domains or the problems our customers were having with them. As a first step, I interviewed my colleagues which gave me everything I needed to create a vision for the team and roadmap to go along with it. For the rest of this post, I’d like to share the steps I took to turn those conversations into actionable next steps for the team.

1. Start with the why

Doing research for the sake of doing research is never a good idea and for that reason, I try make sure I know what questions I need answered before I get started. When I joined the domains team, the consensus was that we needed to build a new domain manager but what wasn’t clear to me was what exactly that meant. That sort of ambiguity almost always leads to those never ending projects that nobody likes. Faced with this challenge, I believed that if we could identify the problems that people were running into then we could break the mythical domain manager into discrete projects that could be incrementally worked on and delivered to our customers on a more frequent basis. This belief and clarity of purpose formed the basis for my stakeholder interview research project.

2. Identify your stakeholders

Over my career, I have come to learn that you need to speak to a minimum of five people before you start seeing repeatable patterns. Luckily for me, we have a couple more than that on the team and they all bring valuable knowledge about the domain industry, the problems our customers face with domains, and the technical infrastructure we use to offer our customers domains. I have also had the pleasure of working with these folks in the past so it was easy for me to put together a list that I shared with the team lead for a quick gut check.

3. Write a script

It’s important for people to feel comfortable in order to open up and share their most intimate thoughts with you. I find the best way to do that is to try and make the conversation feel as natural as possible. This is hard to do when you’re reading everything you say from a script in front of them. For that reason, I prefer to use a bulleted list of points because it provides a less rigid format for you to follow and it’s easier to scan so you can adjust your conversation on the fly. This approach works best for me because it allows me to be more fluid and create a more natural flow to the conversation. Here’s a list of questions I used in my latest round of stakeholder interviews:

  • What are the biggest problems that the domain manager would solve for us?
  • Are you aware of any constraints we have to work with?
  • Which competitors would you recommend that I take a look at? What do you think they’re doing well?
  • Can you share any metrics or funnels that you use to measure how well domains are doing?
  • Is there anyone else that I should be speaking to for this project?

4. Conducting interviews

Before my interviews, I like to take a couple minutes to prepare by going over my questions and reminding myself that I’m about to have a conversation with another person — which in my case means I have to listen more than I speak. In the past I have recorded my sessions so I can take notes later but I had a certain familiarity with these colleagues which put me at ease enough to type my notes during the sessions. In the past, I have also had people sit in on the interviews and take notes for me but you can’t always count on being that lucky all the time. Something I thought might be cool to try in the future is to hire someone to transcribe the recordings after the fact. I think it would capture the most detail out of all these approaches and would provide the most information when you’re ready to analyze everything you have collected from all your interviews.

5. Synthesizing the results

After I have conducted all my interviews, I take some time to review all my notes and and start looking for looking for patterns. Any variety of affinity mapping exercise is good for grouping similar themes and drawing conclusions once you have everything organized. Most times I use a virtual Mural board but this time I did it all in a Google doc by copying and pasting phrases into bulleted lists of similar topics.

All in all, I was very happy with the outcome of these sessions. I learned a ton speaking with all the subject matter experts on my team and formulated a list of the top challenges we face with domains. That list helped my me create a new vision for the team, define metrics to measure our efforts, and, thanks to the support from my colleagues, assemble a roadmap for the next couple months.


Signup for occasional updates from my blog.