Continuous Discovery

Welcome back to The Explainer. Today, we are diving into a concept that is quite literally revolutionizing how we build digital products. We're going to unpack product expert Teresa Torres' master framework for continuous discovery. If you or your team have ever felt totally bogged down by siloed workflows, roadmaps that change every five minutes, or products that somehow just completely miss the mark with your users, this explainer is the ultimate remedy. So let's jump right in and see exactly how modern, adaptable product teams should really be operating. Here is our roadmap for today. We'll start with the curse of knowledge, move on to defining continuous discovery, introduce the product trio, talk about outcomes over outputs, tackle discovering opportunities and solutions, and finally wrap up with rapidly testing hidden assumptions. Okay, let's dive into this fundamental dichotomy. in the product world we basically have two modes we have discovery which is all the messy work we do to figure out exactly what we should even be building and then we have delivery which is the actual building shipping and maintaining of that production quality product now historically teams treated these like totally separate phases or worse gave them to completely different teams but here's the thing digital products are never truly done right you never see a company like netflix just announce okay our app is finished let's all go home and retire Because of that reality, the lines between these two activities absolutely have to blur. Discovery and delivery must become completely intertwined. Section 1. The curse of knowledge and why our expertise actually fails us. Think about the dozens of micro decisions product teams make every single day. Sure, some are huge strategic pivots, but a lot of them are just, hey, what do we label this button? Or how exactly should this workflow operate? The catch? As product builders we suffer from this massive cognitive bias known as the curse of knowledge. We are absolute experts on our own products. We know exactly where everything lives. But our customers, they are not experts on our products. When we make those daily decisions from our own highly informed point of view, we inadvertently alienate our regular users. I mean, if you scroll through your phone right now, you undoubtedly have apps you used to love that just stopped making sense to you over time because their workflow drifted away from your mental model. That right there is the curse of knowledge in action. And this brings us right to Teresa Torres' master definition of continuous discovery. It goes like this. At a minimum, weekly touch points with customers by the team building the product where they are conducting small research activities in pursuit of a desired product outcome. Now, I know that's a mouthful. It's a dense, incredibly powerful definition. So we're going to deconstruct it and rebuild it, literally line by line, for the rest of this explainer. Let's isolate that very first phrase, weekly touch points with customers. The absolute best antidote to that curse of knowledge we just talked about is simply talking to your customers more often. Hitting a weekly cadence is huge. It allows your team to get feedback when ideas are literally just pencil sketches or half-baked concepts. You don't have to wait until an entire feature is coded and shipped to find out if you're even solving the right problem. This early, continuous feedback unlocks this amazing co-creation mindset, seamlessly blending your team's technology knowledge with a customer's deep understanding of their own needs. Section 3. Enter the product trio and breaking down silos. So when that definition mentions by the team building the product, it's pointing directly to what we call the product trio. This is a product manager, a designer, and a software engineer working together from day one to lead discovery. Obviously, you might tag in a product marketing manager or a data analyst for specific issues, but this trio is the absolute baseline requirement. By teaming up like this, you're explicitly trading the raw speed of one person just making a solo decision for the incredibly high quality of collective cross-functional decision making. But, you know, we really have to ask a critical question here to challenge the old way of doing things. Why not just let the product manager write up the requirements and hand them off down the assembly line? Well, handoffs are actually kind of devastating for three main reasons. First, you get this massive loss of context. A PM can literally never document every single thing they learn from a customer in a requirements doc. So the designer misses some nuance, and by the time it reaches the engineer, even more fidelity is lost with every hop away from the customer. Second, you trigger constant rework. The designer hits a weird pattern constraint, so you have to rewrite the requirements. Then the engineer says it'll take four times as long to build, so you have to de-scope and redesign. And finally, you end up building the wrong solutions altogether. Why? Because the engineers, the folks who know the absolute most about what is actually possible with the technology, were left completely out of the room when the critical decisions were being made. Section four, outcomes over outputs and navigating fluid roadmaps. And this brilliantly illustrates the overarching goal of discovery, a total shift in how teams are actually managed. Historically, teams have been managed by outputs. That means being handed a fixed roadmap in January and being told to deliver a specific list of features by specific dates. But guys, that requires predicting the future. Think back to March 2020. If you had a fixed yearly roadmap, a global pandemic immediately threw it out the window. Instead, we have to chase outcomes, creating measurable impact or behavior change. Think about Netflix. They care deeply about subscriber retention. They might not know exactly what specific feature they need to build in August, but they know whatever they do build has to increase subscriber viewing minutes. That's a measurable outcome that drives retention. Focusing on outcomes lets your team instantly adapt to disruptions while still delivering real business value. Now, what's really interesting about this next concept is how it exposes a massive trap in how we do product research. Think about this simple question. Is Usain Bolt fast? In the world of decision-making research, this is what's known as a whether or not decision. When a product team falls in love with their very first idea, they run to their customers and ask, hey, is this idea good or not? And doing that heavily exacerbates confirmation bias. You're only going to notice the evidence that proves your idea is brilliant, and you'll completely ignore the fatal flaws. Because the real answer to that question is, fast relative to what? Relative to a cheetah? Probably not. A Tesla? Definitely not. but relative to other humans, absolutely. You see, you only get a true answer through comparison. Therefore, your team must never evaluate just one single solution. You have to compare and contrast multiple strong solutions against each other. Instead of asking, is my idea good? You have to ask, which of these ideas looks most promising? It's a simple framing trick, but it forces your brain to objectively weigh the pros and cons of every option. Section six, rapidly testing hidden assumptions, breaking down solutions. Okay, I hear you. Testing multiple full-blown solutions sounds incredibly time consuming. To actually test competing ideas without getting bogged down in endless project cycles, you have to break your solutions down into their underlying assumptions. These usually fall into five buckets. One, desirability. Do customers even want this thing? Two, viability. Is this actually good for our business outcome? Three, feasibility. Is it technically possible for our engineers to build? Four, usability. can users actually find it and figure out how to use it and finally five ethical assumptions by breaking a massive complex solution down into these tiny assumptions you can run rapid scrappy tests and get real data back in just a day or two so the crucial point here is that that last category ethical assumptions it's basically just asking is there any potential harm in building this solution think about pulse oximeters during the pandemic They were absolutely essential, but it turned out they actually worked a lot better on patients with fairer skin than those with darker skin. Now, the original product team definitely didn't intend for that to happen, but it led to real people getting misdiagnosed. It's just a stark, practical reminder that surfacing these assumptions early on helps us avoid those unintended real-world consequences when our products go live. Well, we've covered a lot of ground today. We've unpacked the curse of knowledge, met the product trio, and seen how continuous discovery shifts us from outputs to outcomes. I want to leave you with one final, provocative thought to chew on. If your digital product is never truly done, why on earth is your team's learning process still trapped in fixed project cycles? It is time to take this framework, embrace the wonderfully messy reality of your own organization, and just start talking to your customers every single week. Thanks so much for joining me on this explainer and keep learning.

Product discovery coach Teresa Torres introduces the framework for continuous discovery, defined as a collaborative process for making frequent, evidence-based decisions about what to build. She advocates for product trios—consisting of product managers, designers, and engineers—to engage in weekly customer touchpoints to overcome the "curse of knowledge" and ensure product viability. To visualize this workflow, Torres details the opportunity solution tree, a tool that aligns business outcomes with specific customer needs and pain points rather than static feature lists. The presentation emphasizes shifting from an output-focused project mindset to an outcome-driven continuous mindset by rapidly testing small assumptions rather than entire ideas. Finally, the session covers practical strategies for story-based interviewing and overcoming organizational resistance to direct customer research.

#ProductManagement #UXResearch #ContinuousDiscovery