Product Discovery

What is product discovery?

Product discovery is how a product team decides what is worth building. Before work goes into the delivery backlog, discovery checks whether a problem is real, whether users will adopt a proposed solution, whether the business can support it and whether it can be built with the available technology.

It typically runs in two loops. In the first, the team learns about users through interviews, support tickets, usage data and sales conversations. In the second, it tests possible solutions quickly, often with a prototype or a small experiment, and keeps the ones that hold up.

Discovery happens before a new product exists, overlapping with idea validation, and continues after launch whenever a team decides what to add, change or remove. It shows up in startups, in SaaS companies planning a roadmap, and in internal product teams building tools for colleagues. In each setting the aim is the same: lower the risk of spending months on something users will not adopt.

How is product discovery different from product delivery?

Discovery decides what to build; delivery builds it well. Discovery work is quick, cheap and full of throwaway artifacts: interview notes, sketches, prototypes and small tests. Delivery work is slower and more careful, because it produces code that real users depend on and that the team has to maintain.

Many teams run both at once. While engineers deliver the current cycle's features, a product manager, a designer and a senior engineer explore the next set of problems. This keeps the backlog filled with ideas that already have some evidence behind them.

Problems start when the two are confused. Building in order to discover is expensive, and discovering without ever committing to delivery leaves the team with research and no product.

What activities are part of product discovery?

Discovery is a set of habits rather than a single phase, and most teams mix several of these activities every week.

• User interviews: regular conversations about how people work today and where it breaks.
• Data review: usage analytics, support tickets and churn reasons to spot patterns.
• Opportunity mapping: grouping problems and ranking them by how often they occur and how much they matter.
• Solution prototyping: quick designs or technical spikes to test the most promising ideas.
• Small experiments: feature flags, fake-door tests or limited pilots that measure real behavior.

The mix changes with the question. Early on, interviews dominate because the team is still learning the problem. Later, usage data and experiments carry more weight because there is real behavior to observe.

Who should be involved in product discovery?

Discovery works best as a small, cross-functional effort. A common core is a product manager who owns the problem, a designer who owns usability, and an engineer who can judge feasibility early. Bringing an engineer in from the start avoids designing solutions that cannot be built or would cost far too much.

Others join when needed. Sales and customer success bring buyer objections and support patterns. Marketing brings positioning and channel insights. For AI features, someone who understands the data and model behavior should test whether the idea works on real inputs before it reaches design.

Users are the most important participants. Discovery that relies only on internal opinions tends to confirm what the team already believed.

How do you know product discovery is working?

The clearest sign is that fewer shipped features go unused. When discovery is working, the team can explain why each item on the roadmap is there, what evidence supports it and what result it should produce.

Other signs include faster decisions to drop weak ideas, a steady flow of user conversations rather than occasional bursts, and roadmap discussions that cite evidence rather than the loudest stakeholder. Over time, products built this way move closer to product-market fit, because each release is aimed at a problem users have confirmed.

If discovery produces long reports that never change the backlog, it has turned into research for its own sake. The fix is to tie every research activity to a decision the team needs to make soon.

How does Vizio AI run product discovery?

Product discovery sits at the center of the product strategy and UX work in our Venture Studio. For new products, it runs alongside idea validation: we interview target users, map the problems worth solving and test solutions with clickable prototypes. For existing products, we review usage and feedback to decide which features, AI integrations or modernization work should come next.

Discovery then feeds our software development, so what we build has evidence behind it, and it continues after launch as part of the growth and iteration systems we set up. The starting point is a short discovery sprint around one product question the team is unsure about.