Continuous Discovery Habits by Teresa Torres: The Science of Measurement and Managing Discovery Cycles — Key Takeaways from Chapters 11 and 12

Niloy T. — Unsplash

Introduction

This article follows on from the previous ones in this series:

1. Continuous Discovery Habits by Teresa Torres: What It Really Means to Discover Products — Key Takeaways from Chapters 1 and 2
2. *Continuous Discovery Habits by Teresa Torres: Where Business and User Behaviour Intersect — Key Takeaways from Chapters 3 and 4*
3. *Continuous Discovery Habits by Teresa Torres: People’s Stories Translated into Opportunity Mapping — Key Takeaways from Chapters 5 and 6*
4. Continuous Discovery Habits by Teresa Torres: Prioritising Opportunities and Brainstorming Solutions — Key Takeaways from Chapters 7 and 8
5. Continuous Discovery Habits by Teresa Torres: Let’s Test Assumptions Instead of Ideas — Key Takeaways from Chapters 9 and 10

Continuing to share my reading journey through Continuous Discovery Habits by Teresa Torres, we have now reached the chapters that give meaning to all the previous work. If the earlier chapters were about structuring our thinking and designing tests, Chapters 11 and 12 are about data and measuring what we have thought through and designed.

As someone who works daily surrounded by metrics and data visualisation, these chapters resonated particularly strongly with me. Teresa Torres reminds us that discovery is neither a leap of faith nor an opinion-driven exercise; rather, it is an endeavour that should be as objective as possible, with measurement playing a fundamental role.

Measuring Impact: The Hierarchy of Signals

Many product teams suffer from what I would call “measurement myopia”: they launch something, look only at the Business Outcome, and forget about the Product Outcomes. Chapter 11 teaches us that, in Continuous Discovery, measurement should happen in layers, focusing first on leading indicators and only then on lagging indicators.

The Assumption Signal

Before measuring whether a product is successful, we must first measure whether the behaviour we predicted actually occurred. Teresa Torres emphasises that we should define clear success criteria in advance. If we fail to do so, we become victims of confirmation bias, interpreting almost any data point as a victory.

In the MediFlow example, when testing the SMS Payment Link, we do not immediately measure monthly revenue — the Business Outcome. Instead, our immediate impact signal becomes:

“Out of 10 SMS messages sent, how many patients clicked on the link within the first 30 minutes?”

If that signal is zero, then the architecture of the solution is flawed, and there is little value in looking at macro-level metrics.

From Signals to Product Outcomes

To measure effectively, product teams must master the distinction between what the business wants and what users actually do.

• Business Outcomes (Lagging Indicators): These are financial or organisational health metrics (for example, revenue, retention, or market share). They are considered lagging indicators because, by the time the data becomes available, the behaviours that generated those outcomes occurred weeks or even months earlier. If we manage products solely through these metrics, we are always reacting too late.
• Product Outcomes (Leading Indicators): These are measurable user behaviours within the product (for example, completing a task or usage frequency). They are leading indicators because they predict business success and remain under the direct control of the product team.
• Traction Metrics: These refer to the usage of specific features. For example: “How many SMS payment links were sent?”

Taking a Deeper Look at the MediFlow Example

Scenario A: Combating Revenue Loss from Missed Appointments

Healthcare clinics lose margin when patients fail to attend their appointments. The Business Outcome might therefore be:

“Reduce financial losses caused by missed appointments by 15%.”

However, product teams do not control patients’ wallets or behaviours directly. The Product Outcome they should measure is:

“Ensure that 90% of patients either confirm or cancel their appointments through the platform at least 24 hours in advance.”

By changing this behaviour, the financial outcome emerges as a consequence.

Scenario B: Improving Insurance Claims Processing Efficiency

Delays in reimbursements are often business-critical. The Business Outcome becomes:

“Reduce the average reimbursement cycle from 45 to 30 days.”

The Product Outcome — where the team can genuinely intervene — is:

“Reduce the percentage of invoices submitted with form-completion errors to less than 3%.”

If usability prevents errors from occurring, payments naturally become faster.

The Trap of Lagging Indicators

Revenue or churn are simply the outcomes of decisions we made months ago. Teresa argues that managing products through lagging indicators is like driving a car while looking only in the rear-view mirror. Our role in Discovery is to identify the human behaviours that predict these financial outcomes.

The real mindset shift is understanding that product teams should not be evaluated on — or held responsible for — “saving revenue” (an abstract outcome), but rather for changing specific behaviours. At MediFlow, if we focus on helping administrative staff make fewer mistakes or enabling patients to confirm appointments earlier, we are creating predictable value.

As data specialists, our role is to ensure that the relationship between behaviour (Leading Indicators) and revenue (Lagging Indicators) is statistically sound.

Managing Discovery Cycles: Navigating with the Compass of “Surprise”

Chapter 12 focuses on the practical management of this entire process. By now, I believe we understand that Continuous Discovery is not a linear process; rather, it is a dynamic one in which we manage Discovery and Delivery cycles in parallel — a Dual-Track approach.

Surprise as a Trigger for Learning

One of the most interesting concepts presented in this chapter is how we react to data. Teresa Torres suggests that we should actively look for “surprises.”

If a test performs exactly as we predicted, we have merely confirmed what we already knew. However, when a test fails or produces an unexpected result, that is where true learning — and, consequently, true discovery — takes place.

At MediFlow, if patients do not click on the SMS payment link (a failure signal), the product team is forced to rethink and refocus its efforts:

• Does the sender look like spam?
• Is the message being sent too early — for example, immediately after the consultation?
• Are there elements of the user experience that are generating unnecessary friction?

This ability to step back through the Opportunity Solution Tree and revisit previous assumptions based on evidence is precisely what prevents us from building technological “waste.”

Conclusion

As a marketer with a strong focus on MarTech and data, this emphasis on signal validity makes perfect sense to me. In digital environments, it is remarkably easy to fall into the trap of measuring everything while understanding nothing. Measurement in Discovery — and indeed throughout the other stages of the Design Thinking and Product Development processes — exists to reduce uncertainty, not to produce beautiful dashboards and reports, many of which are never even read.

A dashboard displaying the metric “number of payment links sent,” using the MediFlow example, is meaningless if there is no assumption test demonstrating that people trust — and consequently use — those links. Measurement should serve one primary purpose: to invalidate flawed theories as early as possible, allowing us to remain “alive” long enough to test the next idea.

This article is part of my shared reading journey through Continuous Discovery Habits by Teresa Torres. The next article in this series will explore the final two chapters of the book — Chapters 13 and 14.