
Continuous Discovery Habits
Teresa Torres
What's inside?
Explore the essential habits for successful product development, learn how to consistently discover what your customers value, and create products that drive business growth.
You'll learn
Key points
01Why Most Product Teams Build the Wrong Things
Stepping into the world of product development often feels like entering a chaotic kitchen where everyone is shouting orders, but no one is quite sure what the customer actually wants to eat. For decades, the business world operated on a deeply flawed assumption: that brilliant visionaries sitting in isolated conference rooms could perfectly predict market demands. We used to rely heavily on the waterfall method, a rigid, linear process where massive amounts of time were spent writing exhaustive requirements documents before a single line of code was ever written. Teams would spend months, sometimes years, building a product in secret, convinced they were creating the next big thing. When launch day finally arrived, the result was all too often a deafening silence. The product failed, the investment was lost, and teams were left pointing fingers at one another. To solve this, the software industry widely adopted Agile methodologies. Agile promised a revolution by breaking work down into smaller, manageable chunks and delivering software faster. However, as Teresa Torres astutely points out, Agile only solved half of the equation. It taught us how to build software right, but it completely failed to teach us how to build the right software. Teams became incredibly efficient at shipping features, essentially transforming into high-speed feature factories. Yet, if you are rapidly shipping features that do not solve real customer problems, you are just running faster in the wrong direction. We somehow confused the speed of delivery with the actual creation of value. This brings us to the vital distinction between product delivery and product discovery. Delivery is all about the execution—writing the code, testing for bugs, and pushing the software live. Discovery, on the other hand, is the messy, complex, and deeply human process of deciding what to build in the first place. Historically, discovery was treated as a one-time project. A company might hire an expensive market research firm to conduct a massive study, hand over a beautifully formatted slide deck, and consider the discovery phase officially complete. The team would then spend the next twelve months building based on that single, frozen snapshot of customer data. But the world does not stand still. Markets shift, competitors launch new offerings, and customer expectations evolve constantly. A single research project conducted in January is practically obsolete by June. The core philosophy of Continuous Discovery Habits is that discovery can no longer be treated as an isolated event; it must become a continuous, ongoing practice deeply integrated into your team's weekly routine. Torres defines continuous discovery as minimum weekly touchpoints with customers by the team building the product, where they conduct small research activities in pursuit of a desired product outcome. This definition is incredibly precise and intentionally shifts the burden of research away from a separate, siloed research department directly onto the shoulders of the people actually designing and coding the product. Think about how you steer a car on a highway. You do not simply point the steering wheel in one direction, lock it in place, and close your eyes for the next fifty miles. You keep your hands on the wheel, making dozens of tiny, almost imperceptible micro-adjustments every single minute based on the curve of the road, the speed of the wind, and the behavior of other drivers. Continuous discovery applies that exact same logic to product management. By engaging with your customers every single week, your team can constantly adjust its course. You catch misunderstandings before they turn into costly mistakes. You discover emerging needs the moment they arise. Transitioning from a project mindset to a continuous mindset requires a fundamental rewiring of how a company defines success. In an output-driven culture, success is measured by the number of features shipped, the lines of code written, and the deadlines met. It is a culture that rewards busyness over impact. Continuous discovery demands a shift toward an outcome-driven culture. An outcome is a measurable change in customer behavior that creates value for the business. Instead of celebrating because you launched a new search filter on your e-commerce site, you only celebrate when you can prove that the new search filter actually helped more customers find and purchase the products they were looking for. This shift is profoundly liberating, but it is also deeply uncomfortable for many organizations. It forces leaders to admit that they do not have all the answers. It requires executives to let go of rigid product roadmaps filled with promised features and instead trust their teams to pursue strategic goals through experimentation and customer feedback. It requires a level of humility that traditional corporate structures simply do not encourage. Yet, the companies that embrace this uncertainty are the ones that consistently dominate their markets. They do not win because they have better ideas out of the gate; they win because they have built a system that allows them to learn faster than anyone else. By committing to continuous discovery, you are essentially building a safety net for your product decisions. You no longer have to place massive, millions-of-dollars bets on unproven ideas. Instead, you make small, informed wagers every single week. You replace exhausting debates over opinions with objective data gathered directly from the people who will actually use your product. As we dive deeper into this methodology, we will explore exactly how to structure your team, organize your thoughts, and talk to your customers in a way that guarantees a steady stream of actionable insights.
02The Power of the Almighty Product Trio
Walk into almost any traditional corporate office, and you will quickly notice invisible walls dividing the various departments. The product managers sit in one corner, analyzing spreadsheets and dreaming up strategies. The designers are clustered in another area, obsessing over color palettes, typography, and user flows. The engineers are tucked away in a quiet zone, wearing noise-canceling headphones, trying to turn abstract ideas into functional logic. For decades, this siloed structure was considered the most efficient way to build software. Work would flow like an assembly line: the product manager would decide what to build, document it in a massive file, and toss it over the metaphorical wall to the designer. The designer would create the visual interfaces and then toss the files over another wall to the engineers, who would be expected to build exactly what was pictured. Teresa Torres argues that this assembly-line mentality is the single biggest destroyer of innovation and product quality. When work is handed off in this manner, an enormous amount of context is lost at every single transition point. By the time the requirements reach the engineers, the original purpose—the deep, underlying customer problem that needed solving—has been completely stripped away. The engineers are simply told to build a button that does a specific thing, rather than being invited to solve the actual problem. This inevitably leads to resentment, miscommunication, and a final product that feels disjointed and utterly disconnected from real user needs. To break down these silos and foster true continuous discovery, Torres introduces the concept of the Product Trio. The Product Trio is a core team typically consisting of a product manager, a designer, and a software engineer usually a tech lead. These three individuals represent the three vital perspectives required to build a successful product: viability, desirability, and feasibility. The product manager ensures that the solution is viable for the business, meaning it aligns with company goals and can actually generate revenue or save costs. The designer ensures the solution is desirable, meaning customers will actually want to use it and can figure out how to navigate it easily. The engineer ensures the solution is feasible, meaning it can actually be built with the current technology, time, and resources available. The magic of the Product Trio lies in shared context. Instead of working in isolation and handing off documents, the trio experiences the discovery process together from the very beginning. When it is time to interview a customer, the product manager does not just conduct the interview alone and send a summary email to the rest of the team. The designer and the engineer are right there on the call, listening to the customer’s tone of voice, noticing their facial expressions, and hearing their raw frustrations. Consider how this shared experience changes the dynamic of a team. Suppose a customer complains that a specific reporting feature in your software is too slow and confusing. If a product manager hears this alone, they might write a ticket that says, "Redesign the reporting dashboard." The designer might then create a beautiful, highly complex new dashboard that takes the engineering team six months to build. But if the engineer is sitting in on that interview, they might realize that the customer doesn't actually need a massive new dashboard at all. The engineer might recognize that the customer simply needs one specific data point that could easily be added to an existing page with just two hours of coding. Because the engineer had direct access to the customer's problem, they were able to propose a vastly superior, faster, and cheaper solution that the product manager and designer would never have thought of on their own. Building a strong Product Trio requires a significant shift in ego and power dynamics. In traditional environments, the product manager often acts as the "CEO of the product," dictating orders to the rest of the team. In a high-functioning trio, however, leadership is shared. It is a partnership built on mutual respect and a deep understanding that no single discipline holds all the answers. The product manager must be willing to let go of their absolute authority and invite the designer and engineer into the strategic decision-making process. The engineer must be willing to step away from their code editor and engage in messy, ambiguous conversations about customer psychology. The designer must be willing to compromise on aesthetic perfection in favor of rapid, functional experimentation. Of course, getting three intelligent, highly opinionated professionals to agree on anything is not an easy task. Disagreements within the Product Trio are not just common; they are absolutely essential. If the trio always agrees immediately, it usually means that someone is not speaking up, or the team is suffering from groupthink. The key is how the team handles those disagreements. Rather than arguing based on internal opinions or trying to pull rank, a healthy trio uses their disagreements as a signal that they need more information. When the product manager says, "I think customers want feature A," and the engineer says, "I think they want feature B," the trio does not sit in a room and debate it for hours. Instead, they say, "We have a disagreement. Let's design a quick test or talk to a customer tomorrow to find out which assumption is correct." Furthermore, the concept of the Product Trio does not mean that other roles are entirely excluded from the process. Depending on the nature of your product, you might occasionally need to bring in data scientists, marketing experts, or legal advisors. Torres refers to this as expanding to a "Product Quad" or beyond when necessary. However, the core triad of PM, design, and engineering remains the beating heart of the discovery process. They are the ones meeting every single week, synthesizing customer interviews, mapping out opportunities, and deciding which experiments to run next. When a Product Trio truly clicks, the transformation in the workplace is palpable. The endless, soul-crushing meetings arguing over requirement documents disappear. The friction and finger-pointing between departments melt away. Instead, you have a tight-knit, cross-functional unit that moves with incredible speed and agility. They possess a deep, shared empathy for their users, and they hold a collective ownership over the outcomes they are trying to achieve. By uniting business strategy, human-centered design, and technical reality into one cohesive team, the Product Trio becomes an unstoppable force for creating products that truly matter.

Continue reading with LeapAhead app
Full summary is waiting for you in the app
03Mapping the Mess with Opportunity Solution Trees
04How to Talk to Customers Without Being Awkward
05Spotting Hidden Opportunities in Customer Stories
06Brainstorming Solutions That Actually Solve Problems
07Testing Assumptions Instead of Building Full Features
08Conclusion
About Teresa Torres
Teresa Torres is a product discovery coach with a deep understanding of product management. She has a background in human-computer interaction and artificial intelligence. Torres is known for her expertise in helping teams adopt user-centered, hypothesis-driven product development practices. She writes a popular blog, Product Talk.