别把方案写成机会：Teresa Torres 谈机会解决方案树和每周客户访谈

Torres describes the opportunity solution tree as a simple decision-tree visual: an outcome at the root, branching into the opportunity space, then into solutions and assumption tests. She built it because many teams are shifting from output focus to outcome focus without knowing how to manage the unstructured question of what to build to hit an outcome. Teams that learned their craft by being told to build features, she says, now need scaffolding for a very different kind of job.

The framework looks easy but is hard in practice, Torres says, because people struggle to define an opportunity. An opportunity is an unmet need, pain point or desire, yet she estimates that 98% of people write theirs as solutions. Good product work, in her view, means getting comfortable in the problem space and framing a problem well before jumping to answers, which runs against how our brains are wired.

She admits she cringes when she sees blog posts where the opportunity space is all solutions, but does not want to call people out. Her workaround is to publish good examples instead.

Using streaming entertainment as her example, Torres recommends structuring the opportunity space with an experience map of the whole journey. For streaming it runs from the trigger to watch something, to deciding what and where to watch, to evaluating it, to the viewing experience and the post-viewing experience. Under each step you capture needs, pain points and desires, such as not being able to find a title you have in mind, getting back to a show, or being unable to tell if a show is good.

She points out that none of those items contain solutions, which is why Netflix's and Hulu's opportunity spaces would look much alike even though they would choose different opportunities and solve them differently. The companies that build great products, she says, either intuitively or explicitly understand that journey and its needs.

For the top level she suggests roughly three to seven opportunities, tied to steps in the experience map, so the tree stays cognitively manageable. As you go down, opportunities get smaller: "I can't decide what to watch" becomes "I don't know if this show is good," and then something as specific as knowing who is in the cast. That shrinking is what makes a continuous cadence possible, because the lower opportunities can actually be addressed while still contributing to the big problem.

Opportunities come from customer stories, Torres says, but most interviewers ask direct questions out of context, such as what someone likes to watch. People can answer fast, but the answer often does not reflect their behavior and loses nuance. Asking about the last time they watched a movie yields the scene, who they were with and how they chose, and she says customers may reveal needs they are not even aware of.

She lists a stack of skills: interviewing well, hearing opportunities, framing them specifically, and finding the common experience structure across seemingly unique stories. A good opportunity is something like how painful it is to type a password with the old Apple TV remote, which can be solved. A vague one like "I wish this were easier to use" can occupy a team forever. She warns that this is hard critical thinking, but teams who put in the work get a deeper understanding of customers and build better products.

For people in feature-factory companies, Torres advises individual contributors not to try to force organizational change. Change how you work yourself, she says, and find customers to talk to, even by asking friends and family; one healthcare-badge team solved its recruiting problem with a product manager's two doctor uncles. Understanding the outcomes that matter to the business also improves the small decisions you make every day, even if the roadmap is prescribed.

Torres defines discovery as the work of deciding what to build, and continuous discovery as building continuous feedback loops with customers. She ties it to two trends: companies increasingly want customers in the decision process, and digital products are never done, so a project mindset gives way to a continuous one. When leaders say there is no time for discovery, she says they really mean project-based research, and she agrees there is no time for that.

Her answer is that everything in the backlog is a bet whether or not you do discovery, and discovery makes bets better. She advises against halting bets until discovery is done, since that kills appetite for discovery. Keep making bets, start discovering in parallel, and over time the bets improve; she treats assumption testing and delivery as the same work.

To get a weekly interview, she borrows from Nudge and wants an interview to appear on the calendar on Monday morning with no effort. The common approach is an in-product prompt, like an NPS survey, that asks whether the customer has 20 minutes to talk and then offers scheduling software. For buyers and decision-makers, salespeople, account managers and support staff can recruit on calls, and she suggests teams define a weekly trigger describing the need or pain they are looking to hear about.

On tooling, she says many options now exist: Calendly pioneered scheduling and has fast followers, and intercept tools such as Qualaroo, Ethnio, Intercom, Usabilla, Chameleon and Hotjar can all serve the in-product ask.

Not every solution needs heavy discovery, Torres says. Core experiences and differentiators deserve robust work, while something like a forgot-password flow that is working fine may not. She advises instrumenting the product and measuring the impact of releases so you can hone your judgment about where the risk really is, and says people new to discovery should err toward doing a bit too much.

To avoid locking onto the obvious solution, she recommends working with multiple solutions for the same opportunity and comparing them, the way you would look at several apartments or interview with several companies. When a team feels it is overcommitting to one idea on something that must be good, that is the moment to widen the options.

Asked how much say a PM should have, Torres says the idea of the PM as the decider or CEO of the product comes from toxic business culture and territorial silos. She cites the marshmallow challenge, where kindergartners outperform MBA students because they just try things rather than negotiating status. She has seen product trios of PM, designer and engineer decide together, because shared understanding from doing discovery jointly reduces disagreement, and when they still disagree it means a better option has not been found yet.

The first common mistake, Torres says, is asking long lists of why and how questions, which produces an unnatural cadence. She says an interview should feel like having a beer with a buddy, and that you can run a whole interview by asking for the story of the last time someone did the thing. Even though you may need many prompts to teach the person that you want their whole story, the goal is a conversational flow.

She role-plays with Lenny about the last time he watched streaming, which was Obi-Wan Kenobi on Disney+. She asks him to set the scene and walks through the moment he decided to watch and what he did next. Her point is that you only need to be curious and help the person tell the timeline, with prompts like "what happened next?" instead of "why?".

Bad interviewers worry about the next question and stop listening, she says, missing friction such as Lenny finding nothing on Netflix or Prime. Staying shallow throws away the value. She adds that customers tend to enjoy this kind of interview, and the best sign of a good one is a customer asking when you can do it again. She also warns against asking what people would do or think, calling it garbage in, garbage out, since product people need to understand actual behavior.

Torres says the process should not fundamentally change as a company grows. A trio with an outcome, empowered to interview weekly and test assumptions, can work this way in a three-person or a hundred-thousand-person company. What changes is the need to manage dependencies, rely on shared design patterns and share discovery work with adjacent teams to keep the product coherent.

On skepticism about talking to so few customers, she asks critics how many customers they spoke to and what data they used for last week's decisions. Everyone in business makes decisions with zero data, she says, so one interview beats none, and she thinks people nitpick because they dislike the conclusion. Product teams can work with small data because they are changing behavior rather than seeking new knowledge and have good feedback loops, and larger-scale data arrives as they ship.

She treats experiments as user research and sees two core discovery activities: qualitative interviewing to learn the opportunity space, and assumption testing to evaluate solutions. Teams should break an idea into its underlying assumptions, prioritize them, and run tests small enough to test only that assumption. A team doing this might run half a dozen to a dozen assumption tests in a week across three ideas and compare them at week's end, which is what makes continuous discovery sustainable.

Closing, Torres points to her book, her blog at producttalk.org and her courses. She asks skeptical listeners to imagine that this way of working is possible, since she did not invent it and teams really do work this way.