Browse topics

Sharing customer interviews as part of your product design process

You've talked to customers and taken copious notes – now what?

By Sherif Mansour

Sherif Mansour has been in software development for over 20 years. He is currently a Distinguished Product Manager for Atlassian. As a long-tenured Atlassian, he has responsible for Confluence, trying to solve problems across all of Atlassian’s cloud products and establishing a new product incubator inside Atlassian. Sherif also played a key role in developing new products at Atlassian such as Stride, Team Calendars and Confluence Questions. Today, he leads product strategy for Atlassian’s newest product, Team Central. Sherif thinks building simple products is hard and so is writing a simple, short bio.

Get the free product discovery template

Align your team from idea to delivery. Prioritize ideas, create custom roadmaps, and ensure full visibility across all stages.

Use template

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:

Customer Interview Pyramid | Atlassian agile coach

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

Our customer interview template follows a simple structure:

Background 

  • 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

For each problem:

  • One-line problem statement – Be concise. Articulate the users intention, not their feature request.

  • 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.

Want to give it a try? Sign up or log in to confluence >>

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.

Browse topics

Sharing customer interviews as part of your product design process

You've talked to customers and taken copious notes – now what?

By Sherif Mansour

Sherif Mansour has been in software development for over 20 years. He is currently a Distinguished Product Manager for Atlassian. As a long-tenured Atlassian, he has responsible for Confluence, trying to solve problems across all of Atlassian’s cloud products and establishing a new product incubator inside Atlassian. Sherif also played a key role in developing new products at Atlassian such as Stride, Team Calendars and Confluence Questions. Today, he leads product strategy for Atlassian’s newest product, Team Central. Sherif thinks building simple products is hard and so is writing a simple, short bio.

Get the free product discovery template

Align your team from idea to delivery. Prioritize ideas, create custom roadmaps, and ensure full visibility across all stages.

Use template

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:

Customer Interview Pyramid | Atlassian agile coach

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

Our customer interview template follows a simple structure:

Background 

  • 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

For each problem:

  • One-line problem statement – Be concise. Articulate the users intention, not their feature request.

  • 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.

Want to give it a try? Sign up or log in to confluence >>

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.

Recommended for you

Templates

Ready-made Jira templates

Browse our library of custom Jira templates for various teams, departments, and workflows.

Go to Jira templates

Product guide

A comprehensive introduction to Jira

Use this step-by-step guide to discover essential features and the best practices to maximize your productivity.

Go to Jira Product guide

Git Guide

Understanding the Basics of Git

From beginners to advanced experts, use this guide to Git to learn the basics with helpful tutorials and tips.

Read More