Product discovery interviews
A Guide and Framework For Effectively Talking to Users
Understanding a user’s problems and delivering a valuable solution is what product management and user experience are all about.
But how do we do that first part? How do we really understand a user’s problems? How we uncover what's beneath the layers of what they say?
That is where we need to do product discovery. If you aren’t familiar with product discovery, or just want to dive deeper, let me recommend a few articles for you:
Product Discovery: The Beginning of Good Product Development
Product Discovery — What You Must Know
How we set up our Team for Continuous Product Discovery
Product discovery is really about uncovering things. It is discovery to us, in that we may not have known about it. But our users know. So we have to get them to tell us and show us what their problems are. It’s partly like discovering a new land (which was really only new to us, not the people who were already there) and partly like slowly unearthing a dinosaur fossil or hidden artifact.
We won’t dive into the full process of product discovery here, but let’s continue talking about product discovery interviews.
What is a Discovery Interview?
Product discovery interviews differ from other customer interviews in that they help us understand our users and their problems.
I see user interviews as a continuum. On one end are product discovery interviews. These types of interviews are broader, more open-ended. They are meant to understand users, define problems, generate (or dispel) ideas, and overall help us and our teams empathize. They are not about presenting solutions to users. They are for us to understand.
On the other end, we have more structured interviews. These are more UX focused interviews. These types of interviews are when we have product solutions we’ve created and we want to refine and verify them. This would include putting a prototype in front of a user to get feedback, or having a user walk through a specific workflow.
This is, of course, a general guideline. User interviews can be anywhere in between.
Why Do Discovery Interviews
But why should we do discovery interviews?
Discovery interviews help inform the problems we are solving. This goes for startups with no traction to products that have been in the market for a decade. You can’t know if you’re solving the right problems without talking to your users and customers.
Additionally, it is easy to fall in love with our ideas and our solutions. But there are far too many solutions out there searching for a problem to solve. Not that these are bad (some are great and we may love them as our pet projects), but most of them cannot be viable businesses or successful long-term.
You’ve probably heard the phrase “fall in love with the problem”. We repeat it often in product development, because our solutions will often change (the products we build), but we can always come back to the problem we’re solving and who we’re solving it for. And that is why we do discovery interviews — to keep us focused.
When To Do Interviews
There are several times to do product discovery interviews.
First, when you are trying to understand anything. If you are working to understand users and a market space, you should do product discovery interviews to gain understanding. If you are building something new or have a new idea, you need to gain understanding as well. If you are new to a space or new to a company or product, you also need to gain understanding. Before you try to create solutions or solve problems, you need to get out there and understand.
Next, when you are trying to answer specific questions about problems or assumptions that you have. We all have questions and we all make assumptions. You should answer those questions and try to disprove your assumptions.
In our team right now, we have a specific set of problems we are trying to understand. We’ve also made a few assumptions and hypotheses that we are testing out. But before we build anything, we know we need to understand what problems our users (and potential users) are facing and why those problems exist. So we’re doing product discovery around a targeted problem set, focused on understanding what customers are doing right now to solve problems, if they are genuine problems or not, and why they’ve done things in certain ways.
Finally, you should have a regular cadence for general discovery and understanding. When you are building a business or building a product, set aside regular time to talk to your users and understand their problems, how they are solving them, and how they are using your solutions. These conversations don’t need to be overly formalized or specific to your business or product. But they should keep you in touch with your users and the people closest to the problems you are solving.
Some of the best ideas and interesting solutions come from these types of conversations.
In one product I was working on, I had regular meetings with users to discuss their problems and how they were using our products. These were typically informal and just allowed me to see our users in action in their environment. In one case, I noticed several users skipping one of the initial steps we had put in place to help them. I casually asked about it, and they mentioned it wasn’t really important to their work. Well, we had thought it was very important to their workflow (because it was important to our business). But our users didn’t care that much. While we couldn’t take it out (legal stuff), we knew we didn’t have to dedicate loads of time towards optimizing something that few people cared about.
I would have not seen that if I hadn’t spent watching people work and asking questions. It wasn’t on my list of things to review, but just came up during a discovery interview. Which is why it pays to do them, and to keep time for general discovery.
How To Do Interviews
Alright, now that we’ve what, why, and when, let’s dive into the “how”.
Plan
First, it’s important to understand your goal(s) for your product discovery. What do you hope to accomplish? What do you want to learn? This could be very general, as discussed above, or more targeted. But you should create some goals or questions you want to answer as you do your product discovery.
I like to have some overarching questions I’m trying to answer in my product discovery. Things like “how are companies returning to the office?”. This gives a framework for questions you can ask, and gives you something to return to. A goal for your discussion.
You also need to plan who you are going to talk to. Do you have certain customers or users you are trying to target? What segment of users do you need to reach? If your answer is “everyone”, you need to do some more work. You need to be specific about the attributes that will be helpful. Demographics will probably be a poor choice, so don’t get caught in that trap, but “users with less than half of their workforce back in the office” would be a better start. Keep getting more specific.
You can also plan out the questions you’d like to ask. This isn’t a requirement, but can be a helpful tool if you’re trying to standardize across a team and are focused on a specific area for discovery and want to ensure everyone is getting similar information. See the template I provide below.
Execute
Once you’ve planned, it’s time to execute. You need to actually talk to your users or potential users.
Not all discovery interviews/discussions need to be formal. Some of the best discussions I’ve had have been very informal chats that have happened as I’ve caught up with former colleagues or after “formal” calls have ended and we’ve just been chatting.
You can, of course, be more formal. This may mean setting up formal discovery calls and following a template that you’ve created. That is fine. Remember, you want to focus on the goals you’ve created, the important question or questions you are trying to answer, and what the problems really are.
Importantly, you need to ask really good questions.
As I discussed in my review of The Mom Test, asking good questions is really hard. Most of us ask bad questions, or at least questions that lead to bad answers.
We need to focus on questions that lead to concrete answers. “Would you buy a product that solves XYZ problem for you?” is a bad question because everyone will say they would buy a product like that. Why wouldn’t you? A better question is “What solutions have you tried to solve XYZ problem?” That gets to a concrete answer.
Keep your questions open-ended so your users can talk. Ask them to give you examples or show you examples of what they do or have done. Talk as little as you can. Remember, you are there to learn, not to show or tell.
Reflect
Once you’ve planned out your interview and executed, take some time to reflect on what you’ve learned, make notes, and share that with others on your team or in your organization, especially if they haven’t been involved.
This is a critical step. I like to get others involved in discovery as much as I can, because it helps everyone understand why we are building products and what we are trying to accomplish. But not everyone can be on every call or in every discussion. So take time to walk through what you learned and why.
This teaching has been critical for me. Often it helps others understand the user problems and pain. Other times it pokes holes I didn’t see, or brings up other questions I may not have noticed, so I can add those to my list for subsequent discovery interviews.
In one case, I had a discussion with a few customers about some problems they were facing on a specific issue. I brought that back to our product team so I could walk through and we could all discuss. One of our engineers raised a few great questions about how they were using our product and why they were facing those challenges. I didn’t have a good answer because I hadn’t considered it from that angle. So in subsequent calls, I was able to dive deeper into those questions (also a great reason to have your engineers join you whenever you can).
If you keep everything to yourself or just write up notes and send them around, you’re missing a really great opportunity both to share and improve later conversations.
A Template
I mentioned above that we’re currently working on product discovery. I’ve created an interview template to help facilitate this. I’ve changed it somewhat and linked it below so you can see how it’s possible to structure a discovery interview.
This is just one way, and focused on a specific problem set. But you can use the principles for your own product discovery.
Conclusion
Product discovery is critical for building excellent products. And doing good product discovery interviews is critical for good product discovery.
To do that, you need to understand your goals, create a plan, talk to your customers, and share what you’ve learned in order to improve your future discussions and ultimately the solutions you offer.
Discovery is an ongoing process. While you may focus on specific areas for a time, it’s something you should always do as a business and product person. You never know what you’ll learn or uncover.
*I only recommend books and products I’ve read or use myself and all opinions expressed here are my own. This post may contain affiliate links that add no additional cost to you, but may earn me a small commission if you purchase them (though Amazon will get most of your money).
You can follow me on twitter here:
