Continuous Discovery

Continuous Product Discovery

Turn customer feedback from a periodic chore into a high-frequency engine for product decisions.

Help the user with continuous product discovery using insights from 23 guests and posts across Lenny's Podcast and Newsletter.

How to Help

• Audit current proximity - Evaluate the frequency and quality of direct team-to-user interactions and identify existing gatekeepers.
• Define discovery rituals - Help set up recurring cadences for interviews, demo days, and support shifts that involve the entire product trio.
• Structure the opportunity space - Guide the translation of raw feedback into a visual map of unmet needs, pain points, and desires.
• Accelerate evidence gathering - Recommend lightweight methods for testing assumptions through prototypes and behavior mapping before committing to full builds.

Core Principles

Distinguish needs from solutions

Teresa Torres: "I can tell you that opportunity is an unmet need pain point or desire, and that's great. But I can tell you that 98% of people that write opportunities write them as solutions. So we tend to just really struggle with this distinction between the problem space and the solution space."

True discovery requires defining every opportunity strictly as an unmet customer need rather than a pre-conceived feature idea.

Remove layers between builders and users

Brian Tolkin: "Talking to customers every single day like one-on-one onboarding drivers responding to support tickets, there's no centralized support team, there was no closer to the customer, right? And so I think that foundation actually for really understanding what moves the business and being super close to the customer actually is a pretty good foundation for them going on to say, okay, what do we actually want to build in a more scalable technology way?"

Deep empathy is built by eliminating centralized filters and having product teams engage directly in onboarding and support.

Integrate discovery into execution

Itamar Gilad: "Google, was what I call an evidence guided company. So essentially it put a high premium on focusing on customers, coming up with a lot of ideas on looking at the data, looking at how these ideas actually worked out. They weren't shy about launching betas and things that were very rough and incomplete and learning from that and then they expected people to take action based on the results."

Launch rough, incomplete versions to gather real-world data that dictates whether to pivot or proceed with the engineering task.

Prioritize high-signal informal contact

Jeff Weinstein: "The moment the customer felt compelled enough to go out of their way to talk about some problem, that's a unbelievable gift. I will leave a meeting to just get one message back to them. If you're text message friendly with five or 10 of those, you are going to have so much direct signal that is infectious."

Direct, informal communication with motivated users, such as text messaging, often provides higher quality signals than structured research.

Maintain research as a continuous partner

Judd Antin: "Well, the solution is simple but not easy to me. It's that we need to restructure the way we make products in a way which integrates research much more fully. It looks like consistent relationships in which researchers, and the work, and the insights they provide are a part of the process from beginning to end."

Research should be an integrated partner throughout the entire development process rather than a reactive service used at the start.

Identify friction through direct observation

From "The unconventional Palantir principles that catalyzed a generation of startups": "You have to be the user to unlock this concept. I don’t mean that spiritually as in “think like the user”; I mean literally do their same job with your product as an extended member of their team and see what you learn."

Perform the customer's actual work alongside them to reveal the operational friction that interviews alone cannot uncover.

Embed technical staff in customer workspaces

Nabeel S. Qureshi: "There was a different type of engineer which you sent into the field. You would spend maybe Monday to Thursday and you would actually go into the building where the customer worked and you would work alongside them. You would literally get a desk there and so, that engineer became known as a forward deployed engineer."

High-value enterprise discovery is best achieved by having engineers work on-site at customer offices to identify tactical bottlenecks.

Templates & Frameworks

• Continuous Discovery vs. Project-Based Research (Teresa Torres) - A reframing of how discovery fits into product work: not as a phase before delivery, but as a parallel continuous habit that runs alongside delivery
• Opportunity Solution Tree Framework (The Best of Lenny’s Newsletter 2023) - Teresa Torres's framework for continuous product discovery, connecting outcomes to opportunities to solutions to experiments.
• Product Scrapbook (Notion Database) (Product manager is an unfair role. So work unfairly.) - A lightweight Notion database for collecting customer insights, feedback, and evidence organized by strategic swim lanes for faster discovery and planning.
• Forward Deployed Engineering (FDE) Model (The unconventional Palantir principles that catalyzed a generation of startups) - A customer discovery and product development approach where engineers physically embed inside customer environments for extended periods (months, not hours), do
• Exposure Hours (Guillermo Rauch) - An internal operating principle at Vercel for developing product taste and empathy.
• Product Trio Model (Teresa Torres) - A collaborative working model where the product manager, designer, and software engineer make discovery and product decisions together as equals, rather than th
• Customer Support as Everyone's Job — Implementation Rhythm (What working at Figma taught me about customer obsession) - The three-step rhythm Figma used when handling any customer interaction, from support tickets to sales calls to random encounters
• Go to the Source Checklist (First-principles thinking) - Five methods for getting to primary information rather than relying on secondhand assumptions

See references/artifacts.md for the full list with details.

Questions to Help Users

• "How many hours did your team spend observing customers doing their work last week?"
• "What is the most recent customer insight that caused you to kill or pivot a feature?"
• "Which members of your engineering team have spoken directly to a user in the last 14 days?"
• "Are you tracking unmet customer needs separately from your list of feature requests?"
• "What internal gatekeepers or centralized teams currently sit between your builders and your users?"
• "How do you currently store and organize customer evidence so it is accessible during planning?"

Common Mistakes to Flag

• Treating discovery as a phase - Discovery should be a parallel continuous habit rather than a one-time project that happens before delivery starts.
• Listening to stated positions over incentives - Users often provide playbooks or demands that mask the underlying incentives driving their actual behavior.
• Focusing on solutions during interviews - Early discovery should focus on deeply understanding the underlying user needs rather than pitching specific feature ideas.
• Building for vocal minorities - Over-indexing on feedback from the loudest users can lead to a product that fails to meet the needs of the broader market.

Deep Dive

For all 27 sourced insights from 23 guests, see references/guest-insights.md

Related Skills

• Customer Interviews
• Idea Validation
• Product Experiments
• Defining Icp