As a product manager, it's very easy these days to get caught up in the quantitative side of customer feedback with all the analytics tools that we have. As a result, we often forget the importance of balancing out our number crunching with qualitative research – namely, customer interviews - as part of our product design process. We are all in the business of building software to solve problems. As teams grow, our biggest challenge isn’t going to be technical (we break barriers here without even breaking a sweat, it seems). Our biggest challenge will be building a shared understanding of our customers.

Once you have that, everything falls into place. Roadmap alignment and prioritization is understood. Every feature you build hits the sweet spot. You fix potential customer support issues before customers even know they exist. Your interaction with evaluators has a prescient understanding of their needs and deep empathy with their problems. Your website is informative and clear.

In short, you design and build simpler and better products.

I’ve written before about the many different ways of building a shared understanding. (If you haven't yet, go give that a read first. Go on, I'll wait... Ok, let's continue.) Before you go ahead and start writing a product requirements document, have a think about the other techniques you can deploy to build this common understanding. One we use at Atlassian is customer interviews.

Customer interviews can be an enlightening part of the product design process. I’ve had several of those “light bulb” moments during interviews. And it's especially encouraging when you're conducting the interviews with other members of your team (engineering, marketing, design, etc.), and they reach those same conclusions for themselves.

There are tremendous resources available on how to conduct interviews – the logistics, methods and techniques – so I won’t reiterate that here. In contrast, I’ve found very few resources on communicating those interviews to your wider team and turning interviews into action. How can we take the customer interview stories and tell them in a way which helps connect problems with opportunities, and ultimately take action?

The customer interview pyramid: a framework for communicating interviews

Over the last few years we’ve formed a simple framework to help us do this at Atlassian: the customer interview pyramid. It looks like this:

The idea is simple. Let me walk you through this pyramid and describe the intention of each phase. To do this let's use an example.

Imagine it's 2002. A world before Twitter and Facebook. (*gasp!*) The "like" button didn't exist. The word "tweet" was only used to describe to your children the sound a bird makes. You're working on the next big thing... A social network.

Resist the temptation to write observations

It’s very tempting to finish a customer interview, “copy and paste” your bulleted list of notes that you’ve taken on your laptop and just share that with your team. Done & dusted, right? Wrong. No one wants to read through a list like that, and it doesn't really contribute towards a shared understanding of customer problems and opportunities. So how do we avoid this? A few quick tips:

Never share your interview notes with your team straight away

Schedule time for yourself to analyze your notes, think about observations you have made, and group them into patterns.

Spend some time making sure your problem statement isn't a feature request but rather descriptive of the customers' intention. Reflect on the patterns you identified… what is the user trying to do? There's the problem you need to solve.

Connect the problem with opportunities – what could you do to solve this problem?

Finally, it's worth spending some time establishing a process with your team to agree on how it's best to communicate what you've learned.

Implementing the customer interview pyramid for your team

There are many ways you can go about implementing this framework. An easy way to get started is to create a simple document which templates this process. Within the product management team at Atlassian, we've simply created a page template in Confluence (our team collaboration platform) which helps us follow this process. We group all our customer interviews in a single Confluence space to help us centralize all the knowledge in one place.

The homepage for our customer interviews space looks like this:

We've set it up with a dedicated search to make it easy to find past interviews and a list of popular topics so product managers can browse all the interviews that cover those subjects

What's in the customer interview template

How this interview came to be. Who is the person you are talking to? Background on their role, how they use your product etc. The goal here is to provide some context for the person you are speaking to.

​About the company

In this section, the goal is to give readers more context for which the person you are speaking to works in. What does his or her company do?

Problems observed

We typically use a table of contents to list all the problems observed in the interview

Observations that lead you to conclude that was a problem – Be sure to include screenshots, recordings or practical examples to help provide context for those reading.

Opportunities you have to solve that problem – Link to related epics, tasks or feature requests in Jira Software or whatever you use to manage your team's backlog. One big advantage here is that next time you open up your Jira Software task you immediately get context from the interview to help build this shared understanding.

The bulk of the interview write-up should be lots of little "Observations → Problems → Opportunities" statements. We've found this framework to be really helpful in clearly articulating what you experienced and taking interviews and turning them into action.

Customer interviews are one of the most valuable resources for any product manager if you take the time to go beyond simply observing problems to connect them with opportunities for your product. Sharing these insights with your team in a consistent and coherent medium is the final step in making interview feedback actionable.

Share this article

Sherif Mansour

I'm a "recovering coder" and love my role in product management, which I've been doing for about 6 years now. Off the job, you can find me teaching my newborn son how to write product requirements. I think building simple products is hard. So is writing a simple bio. Find me on Twitter! @sherifmansour