Study Guide: Continuous Discovery Habits by Teresa Torres

By SuperSummary

12 min read

Why does it matter? Because working hard on the wrong thing isn't a personal failure — it's a structural one.

Most product teams aren't lazy. They're not underfunded, understaffed, or indifferent. They work hard, ship constantly, and still end up building things nobody uses — then wonder what went wrong. The instinct is to blame execution. Bad estimates, wrong hires, a stakeholder who blew up the roadmap. But Teresa Torres spent seven years watching teams from the inside, and she landed somewhere more uncomfortable: the problem isn't effort. It's that most teams have never replaced gut instinct with a structured way of learning. They interview customers occasionally, test assumptions rarely, and make the same feature-shaped bets on repeat. Continuous Discovery Habits doesn't ask you to work harder. It asks you to swap one deeply ingrained reflex — try something, wait, then guess about what it meant — for a set of small, repeatable practices that keep reality in the room. The shift is learnable. But it has to be deliberate.

The Exhaustion Isn't About Hours — It's About Being the Only One Who Talked to a Customer

San Francisco, 2013. Teresa Torres is sitting in yet another conference room, making the case for a product strategy to executives who haven't spoken to a single customer. She's leading product and design at a venture-backed startup with a genuine mission — helping college students land their first job — and a head of engineering she considers a dream collaborator. By most measures, the job should be rewarding. She's not grinding through eighty-hour weeks. The company has matured past the burn-everything-down startup phase. And yet one day she walks in and quits.

The exhaustion that drove her out wasn't about workload. It was about a specific, grinding form of loneliness: she was the only person in the room who had actually talked to customers. Every strategic argument she made, she had to win from scratch. Every sales rep pushing for a prospect's pet feature, every executive anchored to a competitor's roadmap — Torres was the sole person with first-hand knowledge of what customers actually needed, and that knowledge had to be re-litigated constantly. That's not a sustainability problem. It's a structural one.

So Torres — who went on to spend seven years coaching product teams and tracking where they broke down — built something designed to fix the structure. Her solution is weekly customer contact, conducted by the team actually building the product: a product manager, a designer, and an engineer, together, every week, running small research activities aimed at a concrete outcome. Not a solo PM evangelizing findings after the fact. The structural fix for Torres's 2013 exhaustion isn't hiring a better evangelist. It's making customer contact a shared team habit so no one is ever again the only one in the room who knows.

Chasing Metrics Without a Customer Frame Is Just a License to Cheat

Ambitious metrics don't align teams — they select for whoever is most willing to cheat. That's the quiet lesson buried in the 2016 Wells Fargo scandal, and it applies to product teams far more than most want to admit.

For years, Wells Fargo's cross-selling strategy looked like smart business: get a customer through the door with a checking account, then grow their relationship with savings accounts, credit cards, mortgages. The logic was sound. The problem arrived when leadership turned that strategy into hard quotas with lucrative bonuses attached. The metric was clear — grow the average number of accounts per customer — but it contained no instruction about how. No customer lens. No constraint requiring that accounts be ones customers actually wanted. So employees found the path of least resistance: they opened accounts on customers' behalf without asking. Millions of them. The bank paid $185 million in fines and absorbed billions in lawsuit costs, but the deeper damage was to the logic of metrics-as-alignment itself.

Torres's diagnosis is precise: Wells Fargo's leadership had implicitly framed the problem as "grow accounts at any cost." That framing made cheating a rational response. Had the frame been "create customers who want to open more accounts," the same quota pressure would have pushed employees toward understanding what customers valued — toward discovery, not fraud. The metric was identical in structure. That single constraint changed everything about which behaviors it rewarded.

This is why Torres introduces the Opportunity Solution Tree as something more than an organizational chart for ideas. Its structure enforces a specific sequence: you start with a business outcome, but before you can reach solutions, you have to pass through the customer opportunity space — the needs, frustrations, and desires that, if addressed, would actually move that outcome. The tree doesn't let you skip from "grow retention" to "build a loyalty program" without first asking why customers leave and what would make them stay. That intermediate layer is the guardrail. Remove it, and you're back to Wells Fargo: a number dangling in the air with no constraint on how you hit it.

A metric without a customer frame isn't a north star. It's a blank check for whoever figures out the fastest shortcut.

Your Customers Can't Tell You What They Want — But Their Stories Will

A woman in one of Torres's workshops gets asked what factors she considers when buying jeans. She answers without hesitation: fit is everything, her number-one criterion. Torres then asks her to describe the last time she actually bought a pair. She bought them on Amazon, from a brand she recognized, because they were on sale. On Amazon, where you cannot try anything on. Fit — her stated priority — was structurally impossible to verify. She wasn't lying. She just had no idea how she actually made decisions.

That gap between stated preference and real behavior isn't a character flaw. It's a feature of how the brain works. Gazzaniga showed that when patients couldn't consciously access the reason for a choice, the verbal brain simply invented one — confidently, fluently, and wrong. He called this the "left brain interpreter," and it runs in all of us, constantly. When your brain doesn't know why it did something, it generates a plausible story and delivers it with the full weight of conviction.

Ask a customer a direct question and you trigger the interpreter, not memory. "What do you value most in a product?" gets you a coherent answer. She gave you a coherent answer. She also gave you a wrong one. The jeans woman's brain produced "fit" because fit sounds like the right thing to care about. Her actual purchasing behavior — brand recognition, a sale price — never got consulted.

The fix Torres prescribes is narrow but demanding: stop asking what customers want, and start asking them to narrate specific past events. "Tell me about the last time you bought a pair of jeans" produces a story anchored in an actual moment — Amazon, a familiar brand, a discount — instead of an aspirational self-portrait. Stories recruit memory rather than identity. They're not immune to bias, but they're grounded in something that happened, which is a fundamentally different input than a customer's theory of themselves.

The habit to break is seductive precisely because it feels rigorous. You asked. They answered. You took notes. But if the question was direct, you may have collected a detailed record of who your customer wishes they were.

Brainstorming Meetings Feel Productive Because They Keep You from Feeling Stuck — Not Because They Work

The brainstorming meeting feels like your most creative hour because it keeps you from feeling stuck — and that sensation of flow is exactly what makes it a trap.

Bernard Nijstad wanted to know why teams swear by group brainstorming even though individuals working alone consistently generate more ideas, more diverse ideas, and more original ones. His answer: the illusion of group productivity. When you brainstorm in a group, someone else's idea fills the silence the moment your own thinking stalls. You spend less time cognitively frozen. The session feels fluid, energized, satisfying. You walk out convinced it worked. What you don't notice is that you never had to push through the hard part — the grinding discomfort of running out of obvious answers and having to keep going anyway. That discomfort is where original ideas live.

Nijstad's finding lands harder once you understand what's happening underneath it. Social loafing: individuals unconsciously let others carry the creative load, and no one notices because everyone's talking. Production blocking: in a group, ideas vanish the moment someone talks over you — your thought, half-formed, disappears before you can develop it. And conformity works on the room like gravity; once the first idea gets praised, everything that follows bends toward it, narrowing the range before most people have said a word. None of these feel like failure from the inside. They feel like collaboration.

The fix isn't to stop sharing ideas with your team — it's to reorder when that happens. Generate ideas alone first. Then share with the group, not to brainstorm together, but to expose yourself to other angles. Then return to solo ideation. Hearing other people's ideas genuinely does spark new ones — but only if you go back and generate alone afterward, letting the inputs sit overnight. The meeting becomes fuel, not the furnace.

The Map You Draw Before You Talk to Anyone Is Wrong — and That's the Point

Think of a first draft as a hypothesis wearing the costume of a fact. The moment you write something down — a customer journey, a process map, a list of pain points — it starts to feel true. The ink dries and the thinking stops. That's exactly the failure mode Torres is trying to prevent.

The corrective she proposes is deliberately awkward: before the product trio sits down together, each person draws the customer experience alone. The product manager sketches from memory — the complaints in support tickets, the patterns in call-center notes. The designer, being new to the company, draws from genuine outsider confusion, capturing the anxiety a customer might feel mid-process. The engineer maps the technical logic, showing how a mistake in one early step cascades downstream and derails everything that follows. None of them draw the same thing. That's the point. If they'd gathered in a room and built one map together, the loudest voice would have anchored the group early, and the others would have quietly adjusted toward it. Instead, they end up with three distinct pictures of the same experience — and the gaps between those pictures are where the real discovery lives.

This is why Torres insists on drawing rather than talking. Language papers over disagreement without revealing it. Two people can nod through an entire conversation and leave with completely different mental models, each confident they're aligned. A drawing forces specificity. You can't sketch vague. The moment your pen has to commit to what happens next, you discover whether you actually know or were just assuming.

The resulting shared map isn't a research deliverable — it's a structured list of questions. The trio knows which parts reflect hard evidence, which are educated guesses, and which are pure speculation waiting to be tested. It will change after the first round of customer interviews. It should. A map that survives contact with real customers unchanged wasn't honest about its own uncertainty to begin with. The goal is to make what you currently believe visible enough to argue with — so your customers, eventually, can prove you wrong.

The Portland Condos Were Built for the Wrong Family Size — Because Nobody Tested That Assumption

The city of Portland spent tens of millions of dollars on a housing project designed to help displaced Black families return to their historic neighborhood. The city negotiated tax breaks, priced the condos below market, and restricted sales to the very families it wanted to help. Years after the building opened, most units sat empty. Nobody bought them. Eventually the developer gave up and listed them publicly.

The reason was embarrassingly simple: the developer built one- and two-bedroom units. Most of the displaced families had four or more members. The condos were structurally incompatible with the people they were meant to serve. Nobody had tested the assumption that small units would work for large families — not because it was a hard assumption to test, but because nobody had thought to surface it as an assumption at all. Everyone in the room already knew what displaced families needed. They just knew wrong.

Two biases conspire against you here: confirmation bias, which makes you notice evidence that your idea will work and quietly ignore evidence that it won't, and escalation of commitment, which makes you more convinced an idea is right the more time and money you've spent on it. The possibility that you've misunderstood something fundamental stops feeling like a possibility. It stops feeling like anything at all.

Torres's prescription is to stop testing ideas and start testing the specific assumptions your ideas depend on. A prototype of three competing features takes months to build and gives you ambiguous data about which feature people prefer and why. But beneath any feature is a stack of smaller claims — that users will want this, understand that, trust the system enough to try it — and each of those claims can be tested in a day or two with a sketch, a one-question survey, or a quick simulation of a specific moment. From a five-step story map of a single idea, Torres demonstrates generating twenty distinct assumptions. Most will be safe. A few won't be. The goal is to find those few before the building is built.

To prioritize, she borrows a tool from David Bland: plot your assumptions on a grid of importance versus evidence. Assumptions that land in the upper-right corner — high stakes, thin evidence — are what Bland calls leap-of-faith assumptions. Those are the ones you test first, before a single line of code is written. Portland's leap-of-faith assumption would have landed squarely there: family size determines unit size, the stakes were the entire project, and the evidence tested was zero. It was sitting right there in the architectural plans. Nobody drew the grid.

83% of Students Started Searching When You Asked the Right Question

When should you start measuring your product? Most teams answer: once it's built. Torres's answer is earlier — much earlier — and the AfterCollege search interface is the clearest demonstration of why.

Here's the problem the team was staring at: two-thirds of college students visiting their job board never started a search. The standard interface asked two questions — what kind of job do you want, and where? For most 22-year-olds, those questions might as well be written in a foreign language. They don't know what jobs they qualify for. They don't know where they want to live. The questions assumed knowledge the students didn't have.

The team had a hypothesis: ask students what they studied instead, and you remove the knowledge barrier entirely. Everyone can answer that. But before they built a machine-learning algorithm to match majors to job categories — a months-long investment — they wanted to know if the idea was worth anything at all. So they built a proxy in days. An English major's input triggered a manual search query the team had constructed themselves, surfacing marketing, journalism, and public relations listings. No algorithm. Just a shortcut dressed up as one.

They routed a fraction of their traffic through the new interface and watched. Search starts jumped from 36% to 83%. The rough approximation, assembled in days, outperformed the product they'd spent months building. That number didn't just validate an assumption — it settled the question of whether to keep investing.

What that 83% didn't tell them was whether students actually got hired — an event that happened entirely off-platform, after the interview, after the offer. You can't measure that by watching clicks. So the team built a follow-up email that went out 21 days after a student applied, offering something genuinely useful — interview preparation, salary negotiation guidance — in exchange for a single update on what happened. Response rates started at 5% and, through iteration, reached 37%. Not perfect visibility, but enough to track whether the product was creating real value or just generating activity.

The sequence matters: crude prototype first, specific assumptions measured precisely, then a slow build toward the harder outcome. You don't wait until the product is finished to find out if you're building the right thing.

Stakeholder Battles Are Won Before the Meeting — by Showing the Journey, Not the Conclusion

Why do smart product managers keep losing arguments to executives who know less about the customer? The standard explanation is politics — seniority wins, the HiPPO always wins, that's just how it works. But Torres thinks teams are misreading the problem, and the Airship story shows why.

Lisa Orr's team spent weeks doing genuine discovery. Tasked with cloning a competitor's customer-journey builder — a tool that lets marketers sequence messages across channels over time — they interviewed customers who actually used the competitor's version. What they found was damning: the tool was so complicated that most marketers couldn't figure out where to start, and the ones who did built tangled, redundant journeys they couldn't maintain. The real opportunity wasn't to copy the competitor. It was to rethink the whole approach. So that's what they built. Then the sales team revolted. They wanted the clone — something they already knew how to sell. All that discovery, all that differentiated thinking, nearly died in a conference room.

Torres's diagnosis is blunt: the sales team wasn't being obstinate. They were responding rationally to what they'd been shown. Lisa's team presented a conclusion — here's the product we built — without walking anyone through the reasoning that made it feel inevitable. When you skip the journey and hand someone a destination, they fill the gap with their own experience. The sales team's experience was customers asking for a journey builder that looked like the competitor's. Of course they pushed back. They'd never been given the evidence that made "build a better one" the logical answer.

The fix is structural. The Opportunity Solution Tree works as a communication tool precisely because it forces the sequence: start with the agreed outcome, walk through the customer pain points that threaten it, then show the solutions as responses to those pains. By the time you reach the recommendation, your stakeholder has followed the same chain of reasoning you did.

Lisa's team did eventually win the argument — but only after a beta that wouldn't have been necessary if they'd walked the sales team through the evidence they already had.

You Don't Need Permission to Start — You Need One Partner and One Interview

Torres is 22 years old, sitting on a client call, and a woman from the American Association for the Advancement of Science has just described her first-ever design as horrible. Not rough. Not a miss. Horrible. Torres had spent three days on it. Her manager liked it. She'd walked in expecting praise and received a sucker punch instead.

What happened next is the whole argument. Torres didn't wait for her company's culture to shift toward human-centered design. She didn't petition her manager to restructure the client relationship. On that same call, she invited the unhappy client to partner with her on the next iteration. One ask. One person. That week.

From there, she started showing up to client meetings she hadn't been invited to, attending conferences, reading feedback forums, finding anyone who resembled the person she was designing for. None of it required organizational approval. She had a single guiding principle — good design means staying close to the customer — and she applied it through whatever was in reach. By 32, she was running someone else's company. Not because the organizations she worked for eventually got enlightened, but because she never waited for them to.

The version of continuous discovery that requires a transformed culture, executive sponsorship, and a mandate from above is a fantasy that lets you off the hook. The actual version starts with finding one partner — a designer, an engineer, anyone willing to weigh in on a single decision — and having one conversation with someone who resembles your customer. Then doing it again next week. Torres describes weekly customer interviews as a keystone habit, borrowing the concept from habit researcher Charles Duhigg: the behavior that makes every other behavior easier. It turns out the whole system runs on that one repeated conversation.

You don't need permission to start. You need a partner and a calendar invite.

The Habit That Changes What 'Doing Your Job' Means

There's a version of this work where you wait — for the right company, the right culture, the right executive who finally gets it. Torres spent years watching people wait. The isolation of 2013, the sucker-punch at 22 — both were invitations to wait, and she refused both times. What she built instead wasn't a methodology. It wasn't closer to a professional identity: someone who talks to customers because that's who they are, not because the org chart permits it.

You already know what Tuesday looks like. One person willing to think alongside you. One customer conversation, scheduled before you talk yourself out of it. The map you draw will be wrong — that's not a problem, that's the work. Discovery doesn't begin when conditions are favorable. It begins when you decide that building things that actually matter is your practice, regardless of what the organization around you has figured out yet.