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

by Teresa Torres

I’ll refer to the work that you do to decide what to build as discovery and the work that you do to build and ship a product as delivery.1 This distinction matters.

In the years following the Agile manifesto, teams worked to adopt these principles. We saw a rise in the adoption of Scrum and Kanban, two popular Agile frameworks, to manage delivery work. In parallel, we saw the growth of user-experience design and user research as means for collecting customer feedback.

In the years following the Agile manifesto, teams worked to adopt these principles. We saw a rise in the adoption of Scrum and Kanban, two popular Agile frameworks, to manage delivery work. In parallel, we saw the growth of user-experience design and user research as means for collecting customer feedback.

Leaders struggled to give up ownership of discovery. Even with shorter cycles and more customer feedback, business stakeholders still clung to their original ideas.

And finally, teams continued to be measured by what they delivered, not whether anyone used it or if it created any value for the customer or the business.

We started with who should make those decisions. We started to push decision-making from business stakeholders to product managers and eventually to the whole product team. We started to question how we made discovery decisions.

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).

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 of our business.

Businesses do need to make a profit. That’s required for their survival. However, profit should not come at the cost of serving the customer.

Rather than obsessing about features (outputs), we are shifting our focus to the impact those features have on both our customers and our business (outcomes). Starting with outcomes, rather than outputs, is what lays the foundation for product success.

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 letting our short-term emotions affect our decisions. In the product world, this often shows up when we fall in love with our ideas. The fourth villain is overconfidence. This, too, is common in the product world. We are often sure our ideas will be runaway successes.

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?”

FOCUSING ON OUTCOMES OVER OUTPUTS “An outcome is a change in human behavior that drives business results.” — Josh Seiden, Outcomes Over Output “Too often we have many competing goals that all seem equally important.” — Christina Wodtke, Radical Focus

Product teams often have to do some discovery work to identify the connections between product outcomes (the metrics they can influence) and business outcomes (the metrics that drive the business).

A business outcome measures how well the business is progressing. A product outcome measures how well the product is moving the business forward. A traction metric measures usage of a specific feature or workflow in the product.

Assigning product outcomes to product trios increases a sense of responsibility and ownership. If a product team is assigned a business outcome, it’s easy for the trio to blame the marketing or customer-support team for not hitting their goal. However, if they are assigned a product outcome, they alone are responsible for driving results. When multiple teams are assigned the same outcome, it’s easy to shift blame for lack of progress.

This then sets the stage for the two-way negotiation. If the business needs the team to have a bigger impact on the outcome, the trio will need to adjust their strategy to be more ambitious, and the product leader will need to understand that more ambitious outcomes carry more risk.