Continuous Discovery Habits: Discover Products that Create Customer Value and Business Value

by Teresa Torres

research shows that fluency is correlated with both flexibility and originality.36 In other words, as we generate more ideas, the diversity and novelty of those ideas increases.

Research shows that while we are better at generating ideas individually, we are better at evaluating ideas as a group.

the only criteria you should be considering is how well the idea addresses the target opportunity. You aren’t voting for the coolest, shiniest ideas. Nor are you ruling out the hardest or even impossible ideas.

make sure that you set the context for ideation by sharing your target opportunity and the customer context in which that opportunity occurs.

deliberately work to identify categorically different ideas. If you get stuck, look for inspiration from analogous products. Analogous products don’t need to be from your industry. In fact, the further away they are from your industry, the more likely you’ll uncover diverse ideas. So, ask, “Who else has to solve a problem like this?” and then investigate how they solve it.

Product teams are particularly susceptible to confirmation bias and the escalation of commitment.

the best product teams complete a dozen or more discovery iterations every week. This pace is possible only when we step away from the concept of testing ideas and instead focus on testing the assumptions that need to be true in order for our ideas to succeed. By explicitly enumerating our assumptions, we can start to look for both confirming and disconfirming evidence to either support or refute each assumption.

the idea will generate more revenue than it will cost to build, service, and maintain. However, some ideas are designed to be loss leaders and instead contribute to another business goal besides revenue. But somewhere down the line, the idea must create enough value for the business to be worth the effort to create and maintain.

Story mapping forces you to get specific about how an idea will work and what you expect your end-users will do. While many teams use story mapping to align around product requirements, it’s also a great technique for helping us to surface underlying assumptions.

Throughout your story map, every time you assume that an end-user will do something, you are making desirability assumptions

Conduct a Pre-Mortem

A pre-mortem encourages you to ask, “Imagine it’s six months in the future; your product or initiative launched, and it was a complete failure. What went wrong?” As you generate reasons for why your product or service might fail, you are exposing assumptions that your idea depends upon that may not be true.

The success of pre-mortems, however, hinges on one key factor—phrasing the question as if the outcome is certain. In our case, that means we have to consider that the product or service did fail, not that it might fail.

story mapping, pre-mortems, walking the lines of your opportunity solution tree, and questioning potential harm will help you start to see your own assumptions.

You don’t need to use every method for every idea every time. If you are struggling to enumerate viability assumptions, walk the lines of your opportunity solution tree. If you are great at identifying feasibility assumptions but often forget about desirability assumptions, take some time to story map the idea. Use the methods that shore up your weak spots.

remember: We aren’t testing one idea at a time. We are testing assumptions from a set of ideas.

to collect reliable data, we want to focus on collecting data about what people actually do in a particular context, not just what they think or say they do in general.

Assumption tests don’t merely give us a go/no-go decision for an individual idea; they help us evaluate sets of ideas.

remember, you aren’t trying to prove that this assumption is true. The burden of truth is too much. You are simply trying to reduce risk.

We stop testing when we’ve removed enough risk and/or the effort to run the next test is so great that it makes more sense to simply build the idea.

Product teams, fortunately, are not creating new knowledge. Instead, we are trying to create products that improve our customers’ lives. When we launch a new product or service, we get to see how our customers interact with it. This is a fantastic feedback loop. We quickly get to measure if our product had the intended impact. We work on much faster cycles than science. It took almost 100 years before we could collect physical evidence to support Einstein’s theory of general relativity.

Our goal as a product team is not to seek truth but to mitigate risk. We need to do just enough research to mitigate the risk that our companies cannot bear and no more. This understanding of the intent behind our research will help us strike the right balance between sound research methods and the pace at which we need to work to get products into our customers’ hands.

If you want to do a deep dive on qualitative tests, pick up a copy of Laura Klein’s UX for Lean Startups. She does a good job of surveying a wide breadth of methods.

Another great reference is David Bland’s Testing Business Ideas.

The world is full of good ideas that will succeed on some level. However, an outcome-focused product trio needs to stay focused on the end goal—driving the desired outcome. We need to remember to measure not just what we need to evaluate our assumption tests, but also what we need to measure impact on our outcome.

Students will start more searches if we ask them easier questions. Students will view jobs that we recommend. Students will apply to jobs that we recommend.

Sometimes you’ll want to count people. Other times you’ll want to count actions. A good way to suss this out is to ask, “If one person did many actions, does that create as much value as many people doing one action?” If you need many people to take action, you’ll want to count people. If it doesn’t matter how many people take action, you’ll want to count actions.

Counting people helped us understand how many of our students were having success on our platform. Counting actions helped us understand how hard each student had to work to find success.

In Chapter 3, we distinguished between business outcomes, product outcomes, and traction metrics as a way to help us set the scope for our product work.

team also had the discipline and the wisdom to recognize when they were going down a troublesome path, and they quickly course-corrected. These course-corrections should be celebrated. The fruit of discovery work is often the time we save when we decide not to build something.

While you do want to measure the impact of your product changes, don’t expect to see large step-function results from every change. Oftentimes it takes a series of changes to move the needle on our outcome. We saw this in Amy’s and Jenn’s story at Snagajob. Every time they solved one problem, it opened the door to the next problem. But they kept at it and, over time, had a big impact on their desired outcome.

It’s not enough to do good discovery if you aren’t bringing your stakeholders along with you.

When preparing for a meeting with stakeholders, we tend to focus on our conclusions—our roadmap, our release plan, our prioritized backlog. More often than not, this is exactly what our stakeholders are asking us to share. Even in companies that espouse a focus on outcomes, we still tend to spend most of our time talking about outputs.

Many product trios complain about the HiPPO but miss the role they play in creating this situation.

The Productboard article on the animals of product management - the team's role in creating this situation

When we present our conclusions, we aren’t sharing the journey we took to reach those conclusions. Instead, we are inviting our stakeholders to an opinion battle—a battle we have no chance of winning.

When we take the time to show our work, using visual artifacts like experience maps, opportunity solution trees, and story maps, we are inviting our stakeholders along for the journey with us. Instead of presenting our conclusion—this is the roadmap, release plan, and backlog that will help us reach our desired outcome—we are presenting the potential paths we might take to get there. We are inviting our stakeholders to help us choose the right path. Instead of presenting a conclusion,

We love our ideas, so, of course, our stakeholders will love our ideas, too. We rush into telling our stakeholders everything we’ve learned instead of showing our stakeholders so that they can draw their own conclusions.

There’s a cognitive bias that is coming into play when we do this. It’s called the curse of knowledge.55 Once we know something (like we do in this situation, we have a wealth of discovery work that supports our point of view), it’s hard for us to remember what it was like not to have that knowledge. In fact, our conclusions—our roadmaps, our backlogs, our release plans—start to become obvious. We forget that not only are they not obvious to our stakeholders but also that they very likely have their own conclusions that seem obvious to them.

The key to avoiding this “curse of knowledge” is to slow down. Start at the beginning. Walk your stakeholder through what you learned and what decisions you made. Give them space to follow your logic, and, most ...

Tailor the detail and context to the stakeholder you are talking to. What does this stakeholder, in particular, need to know?

The fastest way to discourage your stakeholders is to shoot down their ideas. Remember, nobody likes the know-it-all.

Instead of jumping straight to why an idea won’t work, use your discovery framework to help the stakeholder see where their idea does fit.

a strong sense of agency.

Instead of asking for permission or waiting for someone to show you how, start small. Iterate from there. I made a career doing that, and I’ve coached hundreds of others to do the same.

What can you do now?

Your guiding principle is simple: How can I include all three disciplines in as many discovery decisions as I can? Make next week look better than last week. Repeat.

Once you have your trio in place, you are ready to adopt the keystone habit of continuous discovery. Start Talking to Customers

When product teams engage with their customers week over week, they don’t just get the benefit of interviewing more often—they also start rapid prototyping and experimenting more often. They remember to doubt what they know and to test their assumptions. They do a better job of connecting what they are learning from their research activities with the product decisions they are making.

Even in the most challenging situations, the teams I’ve worked with have chipped away at getting more access to their customers. They’ve taken a continuous-improvement approach to the challenge.

When you are asked to deliver a specific solution, work backward. Take the time to consider, “If our customers had this solution, what would it do for them?” If you are talking to customers regularly, ask them. Try to uncover the implied opportunity. Even if it’s a wild guess, starting to consider customer needs, pain points, and desires will help you deliver a better solution.

You can apply the same question to your business to uncover the implied outcome, “If we shipped this feature, what value would it create for our business?” Refine your answer until you get to a clear metric—that’s your outcome. By the way, by asking those two questions, you’ve also built your first opportunity solution tree.