Continuous Discovery: Building Products Users Actually Want

The Problem with Building What You Think Users Want

Most software projects start with someone's idea of what users need. Maybe it's the founder's vision, maybe it's a feature request from a loud customer, maybe it's a competitive analysis that identified a gap. The team builds the thing, ships it, and then discovers that users don't use it the way anyone expected — or don't use it at all.

This isn't a failure of execution. The code works. The design is polished. The feature does exactly what the specification described. It's a failure of discovery — the process of understanding what problems actually exist, how users currently cope with them, and what solution would genuinely improve their lives.

Continuous discovery is the discipline of maintaining an ongoing, structured connection between the product team and the people they're building for. Not a one-time research phase before development starts, but an embedded habit that runs alongside every sprint, informing every prioritization decision.

Weekly Touchpoints With Real Users

The foundation of continuous discovery is talking to users every week. Not through surveys — which tell you what people say they want — but through conversations that reveal what they actually do, what frustrates them, and what they've given up trying to improve.

The conversations don't need to be long. Fifteen to twenty minutes, focused on understanding a specific part of the user's workflow, is more valuable than a sixty-minute unfocused interview. The key is consistency. One interview per week for six months gives you a deeper understanding of your users than a two-week research sprint conducted once a year.

Structure the conversations around behavior, not opinions. "How did you handle X the last time it came up?" reveals more than "Would you use a feature that does Y?" People are unreliable predictors of their own future behavior, but they're excellent reporters of their past behavior — if you ask specific enough questions.

Build a research panel of users who've agreed to periodic conversations. Five to eight regular contacts, supplemented by new recruits to avoid echo chamber effects, gives you a reliable stream of insights. Compensate their time appropriately. A $50 gift card for twenty minutes is a trivial expense compared to the cost of building the wrong feature.

From Insights to Validated Solutions

Raw user insights are not product specifications. The gap between "users struggle with X" and "we should build Y" is where most teams make their biggest mistakes. They jump from a problem observation to a specific solution without validating that the solution actually addresses the problem.

Opportunity mapping helps bridge this gap. When you identify a user need, map it to specific opportunities — ways your product could address that need — and then generate multiple possible solutions for each opportunity. This prevents the common trap of falling in love with the first solution idea and building it without considering alternatives.

Prototype and test before building. This doesn't mean building throwaway code. It means creating the simplest possible artifact that lets you test whether your solution concept resonates with users. Sometimes that's a Figma prototype. Sometimes it's a spreadsheet. Sometimes it's a five-minute conversation describing the concept and asking for reactions. The goal is to fail cheaply and quickly on bad ideas so you invest development time only on validated solutions.

This iterative validation process connects directly to how I approach MVP development. An MVP isn't just a smaller version of your product — it's a hypothesis about what users need, built to the minimum scope that lets you test that hypothesis with real behavior.

Making Discovery a Team Sport

Continuous discovery fails when it's one person's responsibility. If only the product manager talks to users and then translates those conversations into tickets, the development team builds based on secondhand interpretations. Context gets lost. Nuance disappears. The developer implementing a feature has no connection to the human whose problem they're solving.

Include developers in user interviews. Not every developer, not every week, but rotate participation so that everyone on the team regularly hears directly from users. A developer who watched a user struggle with a workflow brings that empathy into every design decision they make, in ways that a ticket description cannot convey.

Share insights broadly and immediately. After every user conversation, post a brief summary in your team channel. Highlight surprising observations, recurring patterns, and direct quotes that capture the user's experience. Over time, these summaries build a shared understanding of your users that informs decisions at every level.

Connect discovery insights to your feature prioritization process. Every candidate feature should trace back to a validated user need, not just an internal idea. This doesn't mean you never build something speculative — but it means speculative features are explicitly labeled as bets, with clear criteria for evaluating whether they paid off.

The teams that build products users love aren't smarter or more creative than the teams that don't. They're more connected. They maintain a continuous, structured relationship with the people they serve, and they let that relationship guide what they build, how they prioritize, and what they choose not to build. Discovery isn't a phase — it's a habit, and it's the most valuable habit a product team can develop.