More on this book
Community
Kindle Notes & Highlights
Read between
January 30 - April 30, 2022
The escalation of commitment46 is a bias in which the more we invest in an idea, the more committed we become to that idea.
More often than not, designing and building a testable prototype of each idea will take more time than we have. Instead, we need to learn how to quickly test our ideas through fast iterations.
By explicitly enumerating our assumptions, we can start to look for both confirming and disconfirming evidence to either support or refute each assumption. Additionally, assumption testing is generally quicker than idea testing, and the faster pace helps us to guard against the escalation of commitment.
Story mapping is a popular technique in which teams map out each step end-users have to take to get value from a product or service.49 Story mapping forces you to get specific about how an idea will work and what you expect your end-users will do.
We aren’t story mapping what it would take to build the service—we are story mapping what the key players need to do for our consumer to get value from it.
This solution will address the target opportunity because… Addressing the target opportunity will drive the desired outcome because…
Each assumption lives in one spot on the two-dimensional grid. You want to find the moment in space that represents how important an assumption is to the success of the idea and how much evidence we have or don’t have to support it.
Once we’ve completed our mapping, we are going to start by testing the assumptions in the top-most, right-most corner.
Overly complex simulations. Some teams spend countless hours, days, or even weeks trying to design and develop the perfect simulation.
Many teams ask, “When are we done with discovery? When do we get to send our ideas to delivery?” The answer to the first question is simple. You are never done with discovery.
This is why we say discovery feeds delivery and delivery feeds discovery. They aren’t two distinct phases. You can’t have one without the other.
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.
In addition to instrumenting what you need to evaluate your assumption tests, you also want to measure what you need to evaluate your progress toward your desired outcome.
We started by defining a clear desired outcome, we interviewed to discover opportunities, we visually captured and synthesized what we were learning with experience maps and opportunity solution trees, we prioritized a target opportunity, we brainstormed solutions, we identified our hidden assumptions, we rapidly tested those assumptions, and we continued to measure impact all the way through delivery.
The discovery habits in one sentence
it’s so important not to get bogged down in analysis paralysis when assessing and prioritizing opportunities.
When first getting started, it can be hard to see how starting with a small problem will ever amount to anything. But if you keep at it and work the cycles, small changes start to snowball, and you start to see the collective impact of working across your tree.
One of the hardest challenges with opportunity selection is identifying the right opportunity for right now. However, a round of assumption tests should help you assess fit quickly.
“The more leaders can understand where teams are, the more they will step back and let teams execute.”
It’s not enough to do good discovery if you aren’t bringing your stakeholders along with you.
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.
We are inviting our stakeholders to help us choose the right path. Instead of presenting a conclusion, we are generating and evaluating options. This allows our stakeholders to be a part of the process. We are inviting them to co-create with us, which leads to much more buy-in and long-term success.
Instead of asking for permission or waiting for someone to show you how, start small. Iterate from there.
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.
Work with your stakeholders to identify the impact they expect a given feature to have. Document that conversation. As you implement the feature, be sure to instrument what you need to measure against the expected impact. Start doing post-release impact reviews with your stakeholders. Remind them what impact they expected a feature to have. Share with them the impact the feature actually had.
There is no “one right way” to do discovery. All of the habits in this book can and should be adopted to match your team’s preferences and needs.
Waiting for permission instead of starting with what is within your control.
