6 Guiding Principles for Effective Product Discovery

Have you heard? My new book Continuous Discovery Habits is now available. Get the product trio's guide to a structured and sustainable approach to continuous discovery.

Download a PDF of this image.

I’m co-teaching a design course at Northwestern with my friend Jeff Merrell. We are teaching business leaders and change agents how to prototype their way to viable solutions.

In this context, solutions aren’t product solutions, but rather internal programs and processes that effect change within the organization. Our students work on challenges like improving employee engagement, encouraging knowledge sharing between teams, making meetings more effective, and so on.

It’s fun working with a co-instructor because Jeff does a great job of synthesizing what he hears from me. It helps me sharpen and refine what I think.

For our final assignment, students have to reflect on the overall design process. When writing this assignment, Jeff distilled our design process down to six key principles. I realized that they perfectly summarized what matters to me in discovery, so I decided to share them with you.

Start with Empathy for Your Audience

We can’t get very far in discovery if we don’t know who our audience is. In the product world, that means our customers and our end-users. For my Northwestern students, it typically means their coworkers or the employees at their client’s company.

Either way, if we want to identify successful solutions, we need to start by building empathy for the people who will use or be impacted by our solutions. We need to understand their needs, pain points, desires, wants, goals, and motivations. We need to work to understand what’s working today and what isn’t. We need to explore divergent perspectives. We need to understand nuance and context. We need to avoid projecting or assuming. We need to quiet our egos so that we can listen and observe.

If we want to identify successful solutions, we need to start by building empathy for the people who will use or be impacted by our solutions. – Tweet This

This is easy to say we do. It’s much harder to do consistently well in practice.

To build empathy for your audience, follow these tips:

• Get specific. Imagine a single person who represents your target user or customer. If you know someone specific, even better. For example, with my coaching business, I don’t want to define my target customer as a head of product. That’s too broad. My target customer is a head of product who already understands modern product discovery (i.e. Agile, Lean, design thinking, OKRs, etc.) and is looking for help to up-skill their teams in those practices. I’m not looking to sell anyone on this way of working. I’m not a missionary. If you’re already on board with modern product discovery and just need help getting there, you are my ideal client.
• Ignore everyone who doesn’t match your ideal user or customer. This is the hard part. I hear from people every day who want help with product management who aren’t my ideal client. If I spent time working with them, I wouldn’t have time to follow the next tip.
• Obsessively learn about your target customer’s needs and challenges. Do the work to understand their context. What’s their typical day like? What do they struggle with? What do they love doing? What would they rather not do? Talk to them every week about their life, not just about your product. Do this week over week and you’ll understand your target user or customer better than anyone else.

Explore the Problem Space Indefinitely

Too many people frame discovery as a linear process. You start a new project, you learn about your target customer, you map out the problem space, and you move on to generating and evaluating solutions. If only the world were that neat and tidy.

Discovery is messy. It’s non-linear. Good discovery is continuous. The day we stop being curious about our customers is the day our competitors start catching up.

Good discovery is continuous. The day we stop being curious about our customers is the day our competitors start catching up. – Tweet This

No matter how much discovery we do, we’ll still get things wrong. We can’t fully understand the life or experience of another human being. We’ll never be able to do some research and then call it done. There’s always more to learn. There’s always another nuance or another exception to uncover. This is why adopting continuous discovery practices is so important.

It’s easy to fall into the trap of focusing on delivery once we’ve identified a target solution. But we need to always keep the door open to other opportunities. We need to continuously ask, “Are we still working on the most important opportunity? Do we fully understand the problem we are solving? Have we learned anything this week that surprised us?”

That last question is a great indicator that our mental model of our customer doesn’t yet line up with their reality. And if you are feeling proud of yourself for not being surprised very often, it’s more likely that you are falling prey to confirmation bias than that you truly understand your customer’s world.

Stay curious. Explore divergent perspectives. Keep defining and shaping the problem space.

Stay curious. Explore divergent perspectives. Keep defining and shaping the problem space. – Tweet This

Here are some tips to get you started:

• Keep interviewing. If I’m dogmatic about anything, it’s that product teams should conduct weekly interviews with their customers. This pace scares some people. But I’ve seen it over and over again. When teams adopt this weekly habit, all other discovery habits follow suit. Interviewing is one of the best ways to explore the problem space.
• Actively listen for what you got wrong. Once you get a good foundation of knowledge about your customer, it can be easy to fall into the trap of thinking what you’ve learned is truth. But odds are you got some things wrong. So I teach teams to look for surprises. This helps to counteract confirmation bias.
• Reframe, reframe, reframe. Framing the problem space is one of the hardest things we do. And as we continue to learn more about our customers, we need to continuously reframe our understanding of the problem space. How you identify and group opportunities on your opportunity solution tree is a great way to play with different ways of framing the problem space.

Map Your Way to Clarity

Visual synthesis is an underdeveloped skill for most of us. But when we develop it, it quickly becomes a super power. Human brains are exceptionally good at spatial reasoning and tapping into this unlocks some powerful insights.

I like to map everything. Maps come in all shapes and sizes: experience maps, customer journey maps, life of the customer maps, story maps, process maps, network maps, and so on.

I’ve written before about how drawing helps us think. It also helps us align as a team around a shared understanding. It’s easier to digest a visual than to comprehend an essay. Maps force us to get more specific than language. Mapping helps us clarify our communication.

To better use mapping on your team, try these tips:

• Start with individual maps. Have everyone on your team take the time to draw their own maps. This helps to surface everyone’s individual perspectives. We all see the world differently and we want to leverage our unique experiences when creating together.
• Align around a shared map. After exploring the distinct perspectives on your team, use the exercise described in this video to create a shared map. This is one of the most powerful exercises I’ve come across for quickly getting to a shared understanding.
• Map at different scopes. Don’t stop at one map. Maps work well at different scopes. Map the life of your customer. Map a typical day. Map a specific experience. Map their journey through your product for a specific use case. Map out a behind the scenes process that supports that customer journey.

Use Theory as Inspiration (Draw from first principles)

It’s easy to get caught up in the hype around innovation. We reinvent new ways of doing things because we can. We need to avoid reinventing what isn’t broken and remember to learn from those who came before us.

If our innovation leads to a better solution, great, but too often it merely leads to a different solution. Different isn’t necessarily better.

Too often, innovation leads to a different solution, not a better one. Different isn’t necessarily better. – Tweet This

Google recently redesigned Google Calendar. It looks different and we all had to learn a new user interface, but I can’t think of a single thing that works better as a result of the redesign. Can you?

Now don’t get me wrong, calendars are ripe for disruption through innovation. There are a million things I wish my calendar did better. But Google didn’t address any of them with their “innovative” new design.

So how do we avoid innovation for innovation’s sake and instead innovate to better meet our customers’ needs?

At Northwestern, we teach our students to use theory as inspiration. What we mean by this is to draw from the concepts and theory they learn in their classes to inspire how they frame an opportunity or what solutions they might generate.

For example, they take a class on creating and sharing knowledge and they learn the difference between explicit and tacit knowledge. Explicit knowledge is factual knowledge (e.g. knowing that Paris is the capital of France), whereas tacit knowledge represents knowing how to do something (e.g. knowing how to swing a baseball bat). If one of our students was working on helping teams better share their knowledge with other teams, they might use this theory to inspire what they see in discovery. Perhaps an employee is reluctant to share their tacit knowledge, but is more than willing to share their explicit knowledge.

This same theory can be used to inspire different solutions. The student might ask, “How might we encourage employees to share their explicit knowledge?” as well as asking, “How might we encourage employees to share their tacit knowledge?”

The first question might inspire solutions like “lunch and learns” or the sharing of white papers or blog articles, whereas the second question might inspire solutions like apprenticeship programs or pairing.

In the product world, we might not draw from academic literature in the same way that our Northwestern students do, but we do often draw from first principles. This is an analogous idea.

First principles are fundamental concepts or truths that we can base our solutions on. For example, an engineer might base their solutions on first principles from physics. In the product world, we often base our solutions on first principles from psychology. If you’ve ever used cognitive biases to inspire solutions, this is an example of drawing on first principles or using theory as inspiration.

Theory and first principles help us frame the problems that we see, ensuring that we don’t innovate merely for innovation sake, but instead solve real problems. They also can inspire solutions providing value throughout the discovery process.

For those of you who don’t have experience drawing from first principles or using theory as inspiration, try these tips:

• Read broadly. You can’t use theory as inspiration or draw from first principles if you don’t know any theory or first principles. I encourage product teams to read broadly. Read about human behavior. Pull from many disciplines: psychology, biology, sociology, linguistics, anthropology, philosophy, and so on. This not only builds up our repertoire of theory and first principles to draw from, it also gives us rich context to feed our analogical reasoning and will help us find more creative solutions.
• Don’t reinvent the wheel. Be careful that you don’t fall into the Google Calendar trap. Before you redesign something, get clear on your desired outcome. Make sure it’s measurable. Identify specific opportunities (i.e. needs, pain points, desires, wants) that you want to address with your redesign. Hold yourself accountable to addressing those opportunities and driving that desired outcome. Don’t make changes simply because you like them. Innovate in places where better solutions are needed, reuse and borrow from others everywhere else.
• Distinguish between human truths and technology truths. Human truths are things like cognitive biases and theories about human behavior like reciprocity and social contagion. Technology truths are things like our preference for mobile over desktop or our propensity to create internet memes that involve combining words over images. Human truths are slow to change. Technology truths are fast to change. Use human truths as inspiration. Account for technology truths in the short term, but don’t expect them to hold stable over time.

Co-Create Solutions that Meet the Unique Needs of Your Audience

Too often we jump to the first solution that comes to mind. Our brains are remarkably good at closing the loop—when we hear about a problem, we jump to solve it. But if we want to find good solutions, we need to take the time to make sure that our solutions are tailored to our customers’ specific needs.

That last sentence sounds obvious. But it often takes more work than we think to ensure that it happens.

It’s easy to fall in love with our ideas. As we gain more experience in our domains, we tend to cling to things that worked for us in the past. We forget to ask, “How is this situation different?” We forget to start with assessing what makes this situation unique. Even when we do, we have a strong bias toward our original ideas, even if they aren’t a good match for this particular situation.

As we gain more experience in our domains, we tend to cling to things that worked for us in the past. We forget to ask, “How is this situation different?” – Tweet This

To avoid this pitfall, try these tips:

• Map your solutions to specific opportunities. I like to use an opportunity solution tree to visually match solution ideas to real opportunities that we heard in discovery interviews. This guarantees that we are addressing real needs. Taking the time to visually match ideas with needs ensures that we don’t get sidetracked by distractions and it helps us fine-tune our solutions in a customer-centric way.
• Get feedback early and often. Don’t wait until it’s too late in the process to get feedback from your customers. Get their feedback every step of the way. Don’t spend three weeks redesigning your mobile app, only to get customer feedback when you are all done. Get feedback two or three times a week as you design the mobile app. Don’t be afraid to get feedback before you are ready.
• Let your customers design with you. Don’t limit your customers’ role to feedback. Let them create with you. Don’t worry if their designs aren’t viable or feasible. You aren’t looking for your customers to tell you what to build. You are looking to uncover how they think about the problem. Co-creating with your customers allows you to see how they would solve it for themselves, which is powerful inspiration for your own solutions.
• Learn more about co-creating. See this article on co-creating and this Tom Chi video to learn more.

Get feedback early and often—don’t be afraid to seek it out before you feel ready. – Tweet This

Surface and Test Underlying Assumptions

Whether you were inspired to experiment by The Lean Startup or if design thinking has convinced you to prototype your way to solutions, both encourage you to test your assumptions, not your ideas.

This distinction is often lost on product teams. It’s why we see A/B testing as our most popular form of experimentation. We build our idea to test it. But you’ll save a ton of time and energy and learn more from your experiments and prototypes if you take the time to test the assumptions that need to be true in order for your product to be successful.

This takes more thinking upfront, but should save you valuable time and energy in development. You’ll also learn how to fix faulty ideas rather than simply learning that something won’t work.

Seeing your own assumptions can be hard. Here are some tips to get you started:

• Story map your idea. It’s hard to see our own assumptions when we haven’t gotten specific enough. Story mapping forces you to get specific. Our product ideas need various actors (users and customers) to take action. Your story map will help you identify those key actions and each action is an assumption that if the actor isn’t willing to take, can put your whole solution at risk.
• Start with desirability assumptions. If somebody critical to the success of your solution isn’t willing to do their part, your idea will fail. The product graveyards are littered with excellent technology that was easy to use that nobody wanted. Start with desirability to avoid this fate.
• Don’t forget about viability, feasibility, usability, and ethical assumptions. Many teams have a bias toward usability assumptions. We are getting good at asking, “Can people use this?” But we need to ask a much broader set of questions. Our ideas hinge on viability, feasibility, and ethical assumptions as well. Make sure you are surfacing and testing assumptions across these areas.

And One More Guideline Specific to Product Teams

Our business environments encourage us to specialize and to work in silos. We expect product managers to manage stakeholders, designers to design, and software engineers to write code. And while it’s true all three of those things need to happen, they aren’t sufficient for building good products.

Product development is a team sport. While we each bring a unique set of skills and expertise to the team, we’ll only win by working together. This is another area where I see most teams claim they are better than they actually are.

Product development is a team sport. While we each bring a unique set of skills and expertise to the team, we’ll only win by working together. – Tweet This

If your product manager makes all the decisions or you continually get into opinion battles about what to build, you need to work on your team collaboration skills. I advise my teams to divide and conquer when it comes to getting the work done, but to come together when it’s time to make decisions. That’s the sign of a truly collaborative team.

And if I had to bet on which teams were most likely to build great products, I’d bet on the collaborative team every time.