Chapter 12: Building a Continuous Practice

Research that happens once is a project. Research that happens every week is a practice. The difference between teams that build products customers love and teams that guess is not talent or budget — it is the habit of continuously learning from the people they serve.

This chapter is about building that habit, sustaining it, and scaling it.

The Continuous Mindset vs. the Project Mindset

The project mindset treats research as a bounded activity with a start date, an end date, and a deliverable ^cdh. You do research before you build, and then you stop doing research and start building. This model has three fatal flaws:

1. The world changes. Customer needs, competitive landscape, and technology all shift while you are building. Research done six months ago is stale.
2. You learn by shipping. The most important research questions often emerge after launch, not before. A project mindset has no mechanism for catching those questions.
3. It creates feast-or-famine cycles. Teams either have "research capacity" or they do not. In the famine periods, decisions get made on opinions.

The continuous mindset treats research as an ongoing operating rhythm — like standups, sprint planning, or customer support. It is not a phase. It is part of how the team works, every week, indefinitely.

Torres frames it bluntly: you are never done discovering ^cdh. The moment you stop learning from customers is the moment your product starts drifting from reality.

The Keystone Habit: Weekly Customer Interviewing

A keystone habit is a single behavior that triggers a cascade of other good behaviors ^cdh. For product teams, the keystone habit is talking to at least one customer every week.

Why weekly? Because weekly is frequent enough to build intuition but infrequent enough to be sustainable. And because the cadence creates pressure to maintain recruiting pipelines, interview skills, synthesis practices, and stakeholder communication — all of which atrophy without regular use.

The weekly interview is not a formal, two-hour research study. It is a 20-30 minute conversation with a real customer or prospect, focused on understanding their context, needs, and behaviors. See Customer Interviews.

What Changes When You Interview Weekly

• Pattern recognition accelerates. After 8-10 interviews, you start hearing the same themes. After 20, you can predict what a customer will say before they say it. That is when your team's intuition becomes genuinely calibrated.
• The backlog becomes evidence-based. Instead of debating which feature to build based on the loudest voice, you can point to recurring patterns across real conversations.
• Empathy compounds. Teams that talk to customers weekly develop a visceral understanding of customer pain that cannot be replicated by reading a report.

Building the Habit Cycle

The continuous research cycle has five phases that repeat indefinitely ^{prr cdh}:

1. Focus — Decide what you need to learn this week. This is not starting from scratch each time — it is revisiting your opportunity solution tree (OST), checking which assumptions carry the most risk, and targeting your interview or test accordingly.
2. Collect — Conduct the interview, run the usability test, review the analytics. One activity per week is enough.
3. Analyze — Extract insights, update your maps and frameworks. This should take minutes, not days, because you are processing small batches continuously rather than large batches sporadically.
4. Share — Communicate what you learned to the team and stakeholders. A 2-minute debrief at standup, a Slack message with a key quote, a sticky note on the OST.
5. Repeat — Do it again next week.

The cycle is intentionally lightweight. If it takes more than 2-3 hours per week (including the interview itself), you are overengineering it. The point is sustainability, not comprehensiveness.

Start Small and Iterate

Torres emphasizes that you do not need permission, budget, or a formal research program to begin ^cdh. You need one customer conversation. Start there.

• Week 1: Interview one customer. Take notes.
• Week 2: Interview another. Compare notes. Notice a pattern.
• Week 3: Share the pattern with your team. Interview a third customer to test it.
• Week 4: You now have a continuous practice.

Do not wait for the perfect process. Do not wait for a research ops hire. Do not wait for executive buy-in. Start, and the rest follows.

Working Backward from Outputs to Outcomes

Many teams receive assignments framed as outputs: "Build a reporting dashboard." "Add a Slack integration." "Redesign the settings page." The continuous practitioner's first move is to work backward ^cdh:

• What outcome does this output serve? ("Increase activation rate from 40% to 60%")
• What opportunities would achieve that outcome? ("New users don't understand the core value proposition during onboarding")
• What assumptions must be true for this output to achieve the outcome? ("Users actually want a reporting dashboard, and it would improve their activation experience")

This reframing transforms a feature request into a research question. Sometimes the assigned output is exactly right. Sometimes it is a solution to the wrong problem. You will not know until you ask.

The Compare-and-Contrast Mindset

Torres identifies a critical cognitive principle: never evaluate a single option in isolation ^cdh. When you compare options side by side, you make better decisions — the contrast reveals strengths and weaknesses that are invisible when you look at one thing alone.

Applied to continuous discovery:

• Never test one solution. Test at least two. A/B tests exist for a reason, and the principle extends to concept tests, prototype tests, and even interview questions.
• Never pursue one opportunity. Map multiple opportunities on the OST and compare them before committing.
• Never rely on one data source. Triangulate: interview data + analytics + survey data gives you three perspectives on the same question.

The compare-and-contrast mindset is a hedge against confirmation bias. When you only look at one option, you are biased toward finding reasons it will work. When you look at two, you are biased toward finding the better one — which is a much more useful bias.

Two-Way Door Decisions

Not every decision deserves a week of research. Torres borrows the Amazon framework of two-way doors ^cdh:

• One-way door decisions are irreversible or very expensive to reverse. They deserve deep research, careful analysis, and broad stakeholder input. Examples: choosing your core technology stack, picking your beachhead market, signing an exclusive distribution deal.
• Two-way door decisions are easily reversible. They deserve speed. Examples: button copy, onboarding flow sequence, email subject lines.

The continuous practitioner develops judgment about which door they are walking through. Most product decisions are two-way doors — and treating them as one-way doors is a primary cause of organizational slowness.

When in doubt, ask: "If this turns out to be wrong, how hard is it to undo?" If the answer is "not very," move fast. Ship it. Learn from the result. That is research.

Showing Your Work

Walking Stakeholders Through the OST

Torres advises against presenting research conclusions as fait accompli ^cdh. Instead, show your work. Walk stakeholders through the Opportunity Solution Tree: here is the outcome we are targeting, here are the opportunities we discovered, here is the evidence for each one, here is why we prioritized this one, and here are the assumptions we are testing next. See Opportunity Solution Tree.

This approach accomplishes two things:

1. It builds trust. Stakeholders can see the reasoning, not just the recommendation. They can push back on specific assumptions rather than rejecting the entire conclusion.
2. It invites collaboration. When people see the tree, they add branches. The VP of Sales mentions an opportunity you missed. The engineer flags a technical constraint that reshapes the priority. The artifact becomes a shared thinking tool, not a presentation slide.

The HiPPO Problem

HiPPO — the Highest Paid Person's Opinion — is the tendency for teams to defer to the most senior person in the room, regardless of evidence ^cdh. It is the single biggest cultural barrier to research-informed decisions.

Countering the HiPPO:

• Lead with evidence, not recommendations. "Here's what we heard from 12 customers this month" is harder to override than "I think we should..."
• Make the customer's voice present. Play a 30-second interview clip. Read a direct quote. Concrete evidence from a real person outweighs abstract opinions from executives.
• Use structured decision frameworks. When decisions are made through a defined process (opportunity scoring, assumption testing, experiment results), authority shifts from hierarchy to evidence.
• Show, do not tell. The HiPPO problem is not solved by arguing about it. It is solved by demonstrating, repeatedly, that evidence-based decisions produce better outcomes. Start small, track results, and build the case over time.

Enabling Others to Do Research

A continuous practice cannot depend on a single researcher or a single PM ^prr. It must be distributed.

From Lone Practitioner to Team Capability

The scaling path:

1. Solo — One person does the interviews, synthesis, and communication. This is where everyone starts.
2. Pair — Bring one other person (designer, engineer) into interviews. They observe, take notes, and start building their own interviewing muscle.
3. Trio — The product trio (PM + designer + engineer) shares responsibility for discovery. They rotate who leads the interview, who takes notes, and who synthesizes. See Chapter 10 for the product trio model.
4. Team — The entire team has basic research literacy. Engineers can run usability tests. Designers can analyze behavioral data. Customer support funnels insights systematically.
5. Organization — Research is an organizational capability, not a team-level one. There is a shared repository of insights, common frameworks, and a culture that expects evidence behind decisions.

Each step requires letting go of control. The solo researcher who insists on perfecting every study will never scale. The goal is not perfect research by everyone — it is adequate research by many, supplemented by expert research where it matters most.

Four Anti-Patterns

Continuous practice has its own failure modes. Recognizing them early is half the battle ^{cdh just-enough}.

1. Overcommitting to One Opportunity

The team discovers a promising customer need and goes all-in: full sprint commitment, engineering resources, design effort. Six weeks later, they realize the opportunity was narrower than they thought, or the solution does not work, and they have nothing else in the pipeline.

The fix: Always have multiple opportunities in play. The OST should have several branches, not one. Commit resources proportional to confidence: low confidence = small experiments; high confidence = full build.

2. Avoiding Hard Problems

The team gravitates toward easy-to-research, easy-to-build opportunities and avoids the gnarly, ambiguous, high-impact problems that would actually move the needle.

The fix: Periodically audit your opportunity backlog. Are you working on the most impactful opportunities, or the most comfortable ones? The hard problems are usually where the real value lives.

3. Analysis Paralysis

The team researches endlessly, waiting for certainty before making a decision. Every study raises new questions. Every finding needs "one more data point" to confirm.

The fix: Set decision criteria before you start researching. "We will decide after talking to 8 customers" or "We will choose between these two options after running a one-week experiment." Time-box the research, make the call, and move forward. You can always learn more after shipping (see: two-way doors).

4. Research Theater

The team conducts research but the findings never influence decisions. Studies are commissioned to justify pre-existing conclusions. Reports are produced but not read. Interviews happen but insights stay in the researcher's notebook.

The fix: This is a cultural problem, not a methodological one. If research does not change decisions, ask why. Is the research answering the wrong questions? Are the findings communicated poorly? Are stakeholders not involved in the process? Often, the root cause is that research is happening to the team rather than with the team. Involve decision-makers from the start — in framing the question, in attending interviews, in co-analyzing the data ^just-enough.

Discovery Feeds Delivery, Delivery Feeds Discovery

Torres describes the relationship between discovery and delivery as a continuous feedback loop, not a handoff ^cdh.

• Discovery feeds delivery: Research identifies what to build, for whom, and why. The backlog is populated with evidence-based opportunities.
• Delivery feeds discovery: Shipping a feature generates new data — usage patterns, support tickets, retention changes. That data raises new research questions.

Teams that separate discovery and delivery into sequential phases lose this feedback loop. The product trio should be doing both, simultaneously: building this sprint's features while researching next sprint's decisions.

Measuring Impact

Continuous research is an investment, and investments should be measured ^cdh.

Connecting Product Outcomes to Business Outcomes

The measurement chain:

1. Research activities — Number of interviews, experiments run, insights generated. (Leading indicators — useful for building the habit, but insufficient alone.)
2. Product outcomes — Activation rate, retention, NPS, task success rate. (The direct impact of research-informed decisions.)
3. Business outcomes — Revenue, LTV, CoCA, market share. (The ultimate measure.)

Track whether research-informed decisions outperform opinion-based decisions. Over time, the pattern will be clear — and that pattern is your best argument for continued investment in research.

The Discovery Retrospective

At regular intervals (monthly or quarterly), hold a discovery retrospective ^cdh:

• What surprised us? Which findings contradicted our assumptions?
• How could we have learned it sooner? Were there signals we missed, faster methods we could have used, or assumptions we should have tested earlier?
• What decisions did research inform? Trace specific product decisions back to specific research activities.
• What decisions did we make without evidence? Not every decision needs research, but knowing which ones were evidence-free is important context.

The retrospective is not about blame. It is about calibrating the team's research instincts and improving the practice over time.

Managing the Cycles

Continuous does not mean constant. The practice has natural rhythms ^cdh:

• When to loop back: When you ship a feature and the data does not match your expectations. When a new competitor enters the market. When you notice customer behavior changing. When the team realizes they have been building on stale assumptions.
• When to move forward: When you have enough evidence to act (not perfect evidence, enough evidence). When additional research would not change the decision. When the cost of delay exceeds the cost of being slightly wrong.

Judgment about when to loop and when to move is the highest-order research skill. It cannot be codified into a rule — it is developed through practice. Which is yet another argument for making the practice continuous.

Building Research Culture

The "Satisfying Click"

Erika Hall describes the moment when research snaps a decision into focus — when ambiguity resolves and the team knows what to do — as a "satisfying click" ^just-enough. That click is addictive. Teams that experience it once want it again.

Your job as a research advocate is to create as many of those clicks as possible, for as many people as possible. Every time research resolves a debate, prevents a mistake, or reveals a surprise, make it visible. Not as self-promotion, but as evidence that the practice works.

From Habit to Culture

Culture is what people do when nobody is watching. Research culture means that:

• Engineers ask "what did customers say about this?" before building.
• Designers test prototypes with real users, not just stakeholders.
• PMs cite evidence in roadmap discussions, not just intuition.
• Executives ask "what's our confidence level?" before greenlighting a project.

This does not happen overnight. It happens through the accumulated weight of hundreds of small moments where research made a visible difference.

The Long Game: Antifragility in Research Practice

Aulet's framework for disciplined entrepreneurship suggests a principle that extends beyond startups: the best systems get stronger under stress, not weaker ^de. A continuous research practice, well-built, has this antifragile quality.

When the market shifts, the team that interviews customers weekly detects the shift first. When a competitor launches a disruptive product, the team with deep customer understanding knows which customers are at risk and why. When a recession tightens budgets, the team with validated unit economics knows exactly where to cut and where to invest.

The teams that skip research feel safe in calm waters and panic in storms. The teams that practice research continuously navigate storms with calm, because they have been building their map of reality week by week, conversation by conversation.

Starting Tomorrow

If you take one thing from this chapter, take this: start tomorrow. Not next quarter, when you have budget. Not next sprint, when things calm down. Tomorrow.

Find one customer. Ask them about their work. Listen. Take notes. Share what you learned with your team.

That is the entire practice in miniature. Everything else — the OST, the habit cycle, the retrospectives, the culture change — grows from that single conversation. The hardest part is the first one. After that, it is just repetition.

And repetition, done with intention, becomes mastery.