More on this book
Community
Kindle Notes & Highlights
Read between
January 30 - April 30, 2022
Outcome-oriented: The first mindset is both a mindset and a habit. You’ll learn more about the habit in the coming chapters, but the mindset requires that you start thinking in outcomes rather than outputs. That means rather than defining your success by the code that you ship (your output), you define success as the value that code creates for your customers and for your business (the outcomes). Rather than measuring value in features and bells and whistles, we measure success in impact—the impact we have had on our customers’ lives and the impact we have had on the sustainability and growth
...more
At a minimum, weekly touchpoints with customers By the team building the product Where they conduct small research activities In pursuit of a desired outcome
We aren’t doing research for research’s sake. We are doing research so that we can serve our customers in a way that creates value for our business.
In this book, I’ll refer to customer needs, pain points, and desires collectively as “opportunities”—they represent opportunities to intervene in our customers’ lives in a positive way.
creating value for your business is what ensures that your team can serve your customer over time.
With time, as they address a series of smaller opportunities, these solutions start to address the bigger opportunity. The team learns to solve project-sized opportunities by solving smaller opportunities continuously.
Chip and Dan Heath, in their book Decisive, outline four villains of decision-making that lead to poor decisions. The first villain is looking too narrowly at a problem. This is exactly why we want to explore multiple ways of framing the opportunity space. The second villain is looking for evidence that confirms our beliefs. This is commonly known as confirmation bias. We’ll be discussing this bias often throughout the book. We’ll be exploring several habits that will help us overcome this bias and ensure that we are considering both confirming and disconfirming evidence. The third villain is
...more
Instead of framing our decisions as “whether or not” decisions, this book will teach you to develop a “compare and contrast” mindset. Instead of asking, “Should we solve this customer need?” we’ll ask, “Which of these customer needs is most important for us to address right now?”
Good discovery doesn’t prevent us from failing; it simply reduces the chance of failures. Failures will still happen.
When we learn through testing that an idea won’t work, it’s not enough to move on to the next idea. We need to take time to reflect. We want to ask: “Based on my current understanding of my customer, I thought this solution would work. It didn’t. What did I misunderstand about my customer?” We then need to revise our understanding of the opportunity space before moving on to new solutions.
They use their assumption tests to help them evaluate their solutions and evolve the opportunity space. As they learn more about the opportunity space, their understanding of how they might reach their outcome (and how to best measure that outcome) will evolve. These teams work continuously, evolving the entire tree at once.
The key to bringing stakeholders along is to show your work. You want to summarize what you are learning in a way that is easy to understand, that highlights your key decision points and the options that you considered, and creates space for them to give constructive feedback. A well-constructed opportunity solution tree does exactly this.
“An outcome is a change in human behavior that drives business results.” — Josh Seiden, Outcomes Over Output
Instead of asking them to deliver a fixed roadmap full of features by a specific date in time, we are asking them to solve a customer problem or to address a business need. The key distinction with this strategy over traditional roadmaps is that we are giving the team the autonomy to find the best solution.
The key is to use traction metrics only when you are optimizing a solution and not when the intent is to discover new solutions. In those instances, a product outcome is a better fit.
Product trios tend to fall into four categories when it comes to setting outcomes: 1) they are asked to deliver outputs and don’t work toward outcomes (this is, by far, the most common scenario); 2) their product leader sets their outcome with little input from the team; 3) the product trio sets their own outcomes with little input from their product leader; 4) the product trio is negotiating their outcomes with their leaders as described in this chapter.
Most of us are overly optimistic about what we can achieve in a short period of time. No matter how hard we work, our companies will always ask more of us. Put these two together, and we often see product trios pursuing multiple outcomes at once.
Even when teams intend to choose an outcome, they often fall into the trap of selecting an output. I see teams set their outcome as “Launch an Android app” instead of “Increase mobile engagement” or “Get to feature parity on the new tech stack” instead of “Transition customer to the new tech stack.”
When a team is focused on an optimization outcome, like increasing application submissions, it’s fine to define the scope narrowly. However, when working on a more open-ended outcome, you’ll want to expand the scope of your experience map.
The more you draw, the more you’ll realize drawing is a superpower.
The purpose of customer interviewing is not to ask your customers what you should build. Instead, the purpose of an interview is to discover and explore opportunities. Remember, opportunities are customer needs, pain points, and desires. They are opportunities to intervene in your customers’ lives in a positive way.
“Confidence is a feeling, which reflects the coherence of the information and the cognitive ease of processing it.” Not necessarily the truth.
If you want to build a successful product, you need to understand your customers’ actual behavior—their reality—not the story they tell themselves.
Our primary research question in any interview should be: What needs, pain points, and desires matter most to this customer?
Remember, what matters most to your customer trumps what you need to learn.
With story-based interviewing, you won’t always collect the story that you want. That’s okay. The golden rule of interviewing is to let the participant talk about what they care about most. You can steer the conversation in two ways.
Weekly interviewing is foundational to a strong discovery practice.
The designer has done all the interviewing. It’s easy for the designer to argue, “This is what the customer wants.” Whether or not that is true, the product manager has no response to that. Designating one person as the “voice of the customer” gives that person too much power in a team decision-making model. The goal is for all team members to be the voice of the customer.
Remember, a story-based interview question starts with, “Tell me about a specific time when…”
As you collect customers’ stories, you are going to hear about countless needs, pain points, and desires. Our customers’ stories are rife with gaps between what they expect and how the world works. Each gap represents an opportunity to serve your customer.
our job is not to address every customer opportunity. Our job is to address customer opportunities that drive our desired outcome.
A key concept that drives this structure is the idea of distinctness. We need each opportunity to be distinct from every other opportunity.
If you do your first tree in 30 minutes and think you are done, you are probably not thinking hard enough.
If you are finding that an opportunity should ladder up to more than one parent, it’s framed too broadly. Get more specific. Define one opportunity for each moment in time in which that need, pain point, or desire occurs.
“I wish this was easy to use,” “This is too hard,” and “I want to do everything on the go” are not good opportunities.
For too long, product teams have defined their work as shipping the next release. When we engage with stakeholders, we talk about our roadmaps and our backlogs. During our performance reviews, we highlight all the great features we implemented. The vast majority of our conversations take place in the solution space. We assume that success comes from launching features. This is what product thought leader Melissa Perri calls “the build trap.”
By addressing only one opportunity at a time, we unlock the ability to deliver value iteratively over time. If we spread ourselves too thin across many opportunities, we’ll find ourselves right back in the waterfall mindset of taking too long to deliver too much all at once.
You don’t want to ask, “Should we pursue this opportunity?” That’s a “whether or not” question that leads to poor decisions. It makes us susceptible to confirmation bias, and we forget to consider opportunity cost. Instead, you’ll compare and contrast the set of parent opportunities against each other.
I recommend that teams assess opportunities using the following criteria: opportunity sizing, market factors, company factors, and customer factors.
We want to prioritize opportunities that support our company vision, mission, and strategic objectives over opportunities that don’t. We want to de-prioritize opportunities that conflict with our company values.
We want to prioritize important opportunities where satisfaction with the current solution is low, over opportunities that are less important or where satisfaction with current opportunities is high.
We’ll learn more from testing our decisions than we will from trying to make perfect decisions. The best way to prevent this type of analysis paralysis is to time-box your decision.
creativity research tells us that our first idea is rarely our best idea. Researchers measure creativity using three primary criteria: fluency (the number of ideas we generate), flexibility (how diverse the ideas are), and originality (how novel an idea is).
First, research has found that people tend to work harder when working individually than when working in groups. This is called social loafing. When we are on our own, we have no choice but to put in the work, whereas when we are in a group, we can rely on the efforts of others.
Creativity is a universal human trait. And as a product-team member, there is no one better than you to generate creative solutions to your customers’ problems.
And finally, don’t be afraid to consider wild ideas. Some people don’t like this suggestion, because wild ideas are rarely pursued. But wild ideas can improve more feasible ideas.
First, start by asking for each, “Does this idea solve the target opportunity?” It’s okay if it’s only a partial solution, but you’ll be surprised to find several ideas that don’t solve your target opportunity at all.
This doesn’t mean you have to have consensus on all three options. But everyone on the team should be excited about at least one idea, and each idea should have a strong advocate in the group. If that’s not the case, revisit your set of ideas, and dot-vote again.
“We loosely define an iteration in discovery as trying out at least one new idea or approach…To set your expectations, teams competent in modern discovery techniques can generally test on the order of 10–20 iterations per week.”
Confirmation bias45 means we are more likely to seek out confirming evidence than we are to seek out disconfirming evidence.
