Product discovery skills
employers want

Product discovery is how teams decide what to build. It runs alongside delivery and focuses on learning fast and cheaply. Marty Cagan's SVPG describes the goal as tackling four big risks before building: value (will customers buy or use it?), usability (can they figure it out?), feasibility (can we build it with our time, skills and technology?) and business viability (does it work for sales, legal, finance and the business model?).¹ SVPG frames discovery as a team effort, ideally led by a product manager, designer and tech lead together.²

Teresa Torres's opportunity solution tree gives the work a structure: start with a desired outcome, map the opportunities (customer needs, pain points and desires) that could drive it, generate several solutions for the most important opportunity, then design small tests for each solution's assumptions.³ The payoff is avoiding waste. Pendo's usage analysis found that 80% of features are rarely or never used.⁴ Discovery skills are central to product management roles, which AmbitionBox lists in India at a typical ₹22.1–24.5 lakh.⁵

Big product risks to test (SVPG)

4

Features rarely or never used (Pendo)

80%

Customer touchpoints in continuous discovery

Weekly

Typical product manager pay in India (AmbitionBox)

₹22.1–24.5 lakh

Table: How product discovery skills are assessed (editorial summary)

Table: Testing assumptions behind a new feature (illustrative)

Table: How product discovery developed (editorial summary)

• A set of interview notes with patterns
• An opportunity solution tree
• An assumption map with risk ranking
• Two tests you ran and their results
• A decision you made from the evidence
• A verified product discovery certificate

Show waste avoided and value created: "Ran two-week discovery on a proposed report builder; found and validated a simpler digest; shipped in three weeks instead of three months."

"How do you avoid leading questions in interviews?"

Ask about specific past experiences — "Tell me about the last time you…" — not hypotheticals or opinions about your idea.

"Which assumption would you test first?"

The one most critical to success with the least evidence.

"What's a fake-door test and when is it appropriate?"

A demand test using an entry point to a future feature; use it carefully and be honest with users who click.

"How do you know when discovery is done?"

When the key risks have enough evidence for a confident decision — discovery then continues on the next question.

"How does AI change discovery?"

Faster synthesis and prototyping, but the need to talk to real customers and validate remains.

• "How often do PMs talk to customers?" — discovery culture.
• "Do designers and engineers join discovery?" — trio practice.
• "Can ideas be killed after testing?" — evidence over opinion.
• "What's an example of a pivot from research?" — real practice.

Table: Discovery-heavy roles and typical pay in India (AmbitionBox, October 2026; indicative)

Table: Common product discovery tools (editorial guidance)

• APM or researcher — supports discovery.
• Product manager — leads discovery for a team.
• Senior PM — discovery for complex bets.
• Group PM — discovery practice across teams.
• Head of product — evidence-led culture.

1. Week 1: Interviews — Five story-based interviews; find patterns.
2. Week 2: Map — Opportunity solution tree and assumption map.
3. Week 3: Test and prove — Run two tests; take the Product Discovery Certification.

Related: Product Manager, UX Research and Product Prioritization. Guides: product management, UX research and user interview questions.

• Interviews — weekly customer conversations.
• Synthesis — patterns and opportunities.
• Assumption reviews — with the trio.
• Tests — prototypes and experiments.
• Decisions — pursue, pivot or park.
• Sharing — insights with stakeholders.

"What's the difference between discovery and delivery?"

Discovery decides what to build; delivery builds it well. Both run continuously.

"How do you handle a stakeholder who wants to skip discovery?"

Propose a short, time-boxed test of the riskiest assumption to reduce risk quickly.

Table: A first-90-days plan (editorial guidance)

Begin by setting up a steady interview rhythm — recruiting is often the hardest part. Build an opportunity map with your designer and engineer around the team's outcome, then test the most promising ideas with small experiments. Share what you learn openly, including ideas you killed.

The best discovery interviews collect stories about real past behaviour rather than opinions. Start with context: the person's role and goals. Then ask about a specific recent instance: "Tell me about the last time you prepared the Monday report." Follow the story step by step, asking what happened next, what was hard, what they tried and how they felt.

Avoid pitching your idea or asking "Would you use…?" People are poor predictors of their own future behaviour and tend to be polite. Instead, look for workarounds, spreadsheets, repeated frustrations and money or time already spent — strong signs of real problems.

Take notes in the participant's words, and synthesise with your trio soon after. Over several interviews, patterns become opportunities on your tree.

AI tools now transcribe and summarise interviews, cluster feedback and generate clickable prototypes from a description. That can shrink a discovery cycle from weeks to days. The risk is that teams skip talking to customers because synthetic summaries feel like evidence. AI-generated "user personas" or simulated interviews can't replace real conversations about real behaviour.

The best teams use AI to remove busywork — scheduling, note-taking, first-pass synthesis and rapid prototypes — while keeping humans in the loop for interviewing, interpreting and deciding. They check AI summaries against the original transcripts, protect participant data and test prototypes with real users. In interviews, explain how you use AI to run more discovery, not less, and how you guard against its blind spots.

• Asking customers what to build.
• Testing only favourite ideas.
• Skipping feasibility and viability.
• Polished prototypes too early.
• No decision criteria.

The four risks and discovery practice come from SVPG; opportunity solution trees from Teresa Torres at Product Talk; feature usage from Pendo; and India pay from AmbitionBox (read October 2026). The worked example, interview guidance and history are editorial. Science of Apps publishes the free test linked here. Last reviewed October 2026.

• Product discovery — learning what to build before building it.
• Opportunity — a customer need, pain point or desire.
• Assumption — something that must be true for an idea to succeed.
• Fake-door test — measuring interest in a feature that doesn't exist yet.
• Product trio — PM, designer and engineer working together.