The customer interview pyramid
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.
But 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. In our data driven world, we often get carried away with the ‘what’ but we never spend enough time answering the ‘why’. As a result, we often forget the importance of balancing our number crunching with qualitative research to help answer the why.
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 conducing 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. I call this the ‘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.
Layer 0: Communicate observations
What is it? At the bottom of the pyramid we’ve got the absolute minimum. We should all come back from an interview and be able to write a list of observations — just regurgitate what you’ve seen.
In our example: You’re interviewing a customer for this awesome social network idea and you observe the following:
- Lots of people are sharing photos
- There are plenty of comments on the photos
- Comments contain a mix of discussions with plenty of “looks great!” and “+1”, “THIS!”, statements.. and lots of smily faces.
Layer 1: Interpret problems
What is it? The next step up from communicating observations is interpreting users’ behaviors and grouping them together with over-arching problem statement.
In our example: All these observations lead you a hypothesis. You conclude that your users want to quickly express their feelings about a shared photo, and that there are a lot of common expressions which people have to type manually.
Layer 2: Connect opportunities
What is it? At the peak of the pyramid is where we get the most value — connecting the problem with potential opportunities. This helps influence our discovery roadmap and decisions for what problems we might tackle.
In our example: To help reduce friction for expressing a response to a photo your team brainstorms ideas like favoriting photos, adding a button that says “+1” (crazy idea, I know), or heck, brace yourselves… even something more radical like a “I like this” button (mindblown!).
Observations → Problems → Opportunities
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.
