Gantt Chart for Product Discovery

Product discovery is the work that happens before engineering starts — the research, testing, and decision-making that determines whether you are building the right thing. Done well, discovery prevents teams from spending three months building a feature no user needs. Done poorly, it becomes an endless loop of interviews and workshops that never produces a decision.

A Gantt chart gives discovery a shape: defined phases, parallel research tracks, explicit dependencies, and hard dates for the go/no-go decision that sends the work to engineering. This guide walks through a full product discovery timeline from problem framing to handoff.

Phase 1: Problem Framing (Weeks 1–2)

Discovery starts with a problem, not a solution. The problem frame determines every research question, prototype test, and prioritization decision that follows. Investing two weeks in a precise problem statement prevents three months of work on the wrong opportunity.

Opportunity assessment tasks:

Strategic alignment check: Does this problem sit in an area the company is committed to winning? Does solving it advance the product strategy? Problems that are real but strategically peripheral should stay in the backlog.
Market sizing: How many users or customers experience this problem? How frequently? What is the potential revenue or retention impact of solving it? Size the addressable opportunity with numbers, not adjectives.
Competitive landscape scan: Are competitors solving this problem? If so, how? What is the gap between their approach and what users actually need?

Deliverable: A one-page opportunity assessment document. It frames the problem, sizes the opportunity, maps the competitive context, and states why this is worth solving now versus later. This document requires sign-off from the product leader and at least one engineering lead before research planning begins.

Phase 2: User Research Planning (Weeks 2–3)

Research without a plan produces data without insight. Before recruiting a single participant, document:

Research questions: What specific questions does this discovery effort need to answer? List them explicitly. "Understand the user" is not a research question.
Methodology selection: Match the method to the question:
Problem interviews: Best for understanding the current-state experience, pain intensity, and workarounds.
Surveys: Best for quantifying frequency and distribution of a problem across a larger population.
Usability testing: Best for evaluating an existing flow or prototype.
Ethnographic observation: Best for understanding behavior in natural context (office, field, home).
Tree testing or card sorting: Best for navigation and information architecture questions.
Participant criteria: Define who the right research participants are. Use the same specificity as a sales ICP — not "users of our product" but "B2B operations managers at companies with 50–500 employees who currently use spreadsheets for X."
Sample size: For qualitative interviews, 5–8 participants per distinct user segment saturates most major themes. For surveys, 100+ responses. For usability tests, 5 participants catch 80% of usability issues.

Phase 3: Participant Recruitment and Scheduling (Weeks 3–4)

Recruitment is always slower than planned. Build in buffer.

Recruitment channels:

Existing customers: CSM introductions for customer interviews. Fastest and most relevant.
User research panels: Respondent.io, User Interviews, or UserTesting.com for external participants. Allows precise demographic filtering.
Sales-introduced prospects: For problems that target future customers not yet using the product.
Internal recruiting: For low-stakes early-stage concepts, use colleagues outside the team.

Scheduling tasks:

Send calendar invites with a brief description of what the session involves and how long it takes.
Confirm all participants 24 hours before.
Prepare and test recording setup (consent to record, Zoom or in-person recording).
Brief any observers on note-taking protocol — observers do not speak during sessions.

Phase 4: Research Execution (Weeks 4–6)

The quality of research execution determines the quality of insights. Common failure modes:

Leading questions: "Would you want a feature that helps you do X?" always gets yes. Ask "Tell me about the last time you experienced X" instead.
Solution-first framing: Showing prototypes too early anchors participants to your solution rather than their actual behavior.
Confirmation bias: Ignoring data points that contradict the hypothesis. Document disconfirming evidence with the same rigor as confirming evidence.

Interview facilitation protocol:

5-minute warm-up: role, company, context.
10-minute current-state walkthrough: "Walk me through the last time you had to do X."
20-minute deep dive: follow surprising or emotionally charged moments.
5-minute future-state probe: "What would ideal look like for you?"

Debrief after each session: 15-minute team debrief immediately after each interview to capture hot observations before memory fades.

Phase 5: Insight Synthesis and Affinity Mapping (Weeks 6–7)

Raw interview notes are not insights. Synthesis transforms data points into patterns and patterns into product-relevant findings.

Affinity mapping process:

Transfer each observation onto a sticky note (digital: FigJam, Miro; physical: wall or whiteboard).
Group observations into clusters based on similarity.
Name each cluster as an observation ("Users often do X") not a solution ("We should build Y").
Identify the 3–5 most significant patterns — these become your key findings.

Insight validation: Cross-reference qualitative findings with quantitative data (analytics, survey results). An insight that appears in interviews and is confirmed by usage data is much stronger than one that appears in interviews alone.

Deliverable: A synthesis document with: key findings (what is true about users and their problems), implications (what this means for product decisions), and open questions (what remains unknown).

Phase 6: Opportunity Prioritization (Weeks 7–8)

Multiple opportunities will emerge from research. Prioritization frameworks turn a list into a ranked order.

RICE scoring:

Reach: How many users are affected per quarter?
Impact: How significantly does solving this affect the outcome metric? (0.25 = minimal, 0.5 = low, 1 = medium, 2 = high, 3 = massive)
Confidence: How confident are you in the reach and impact estimates? (100% = high, 80% = medium, 50% = low)
Effort: How many person-months will this take? (Engineering estimate)

RICE Score = (Reach × Impact × Confidence) / Effort

Jobs-to-be-Done mapping: Map each opportunity to the functional, social, and emotional job the user is trying to accomplish. Opportunities that address the core functional job with a strong emotional component outperform those that address peripheral jobs.

Prioritization outputs to a stack-ranked list of opportunities with a clear recommendation for which one to move into solution ideation.

Phase 7: Solution Ideation (Weeks 8–9)

Ideation is structured divergence — generating many possible solutions before converging on the most promising ones to prototype.

Design sprint structure (optional but high-value for complex problems):

Day 1: Understand and define the target opportunity.
Day 2: Sketch individual solution concepts.
Day 3: Decide which concepts to prototype.
Day 4: Build a testable prototype.
Day 5: Test with users.

Even without a full design sprint, run a structured sketching session: 30 minutes of individual ideation (Crazy 8s) followed by gallery review and dot voting. Diversity of perspective matters — include engineering and CS representation, not just product and design.

Phase 8: Prototype Testing (Weeks 9–12)

Prototypes should be the minimum fidelity required to test the specific question. Over-engineering a prototype is wasted work; under-engineering it produces invalid results.

Prototype types by test:

Paper or Figma wireframes: Test overall flow and navigation.
Interactive Figma prototypes: Test interaction patterns and copy.
High-fidelity mockups: Test visual design and perceived trust/quality.
Working prototype: Test technical feasibility or complex interactions.

Test types:

Moderated usability tests: Facilitator watches participant use the prototype and asks follow-up questions. Best for understanding why users struggle.
Unmoderated testing: Participants complete tasks independently and record their experience. Faster and cheaper; less depth.
A/B concept tests: Present two different solutions to separate user groups and measure preference or behavior. Useful for validating positioning and copy.
Tree testing: Test navigation structure without visual design to isolate information architecture issues.

Aim for 5 moderated sessions minimum per prototype iteration. Two or three prototype iterations are normal — discovery is inherently iterative.

Phase 9: Finding Documentation and Stakeholder Presentation (Weeks 12–13)

Discovery ends with a presentation, not a conversation. Formal documentation forces synthesis and creates a record that engineering can refer to during build.

Deliverables:

Discovery report: Problem framing, research methodology, key findings, prioritized opportunities, recommended solution direction, and confidence level.
User research repository: Recordings, transcripts, and notes organized by participant. Tools: Dovetail, Notion, or a shared drive.
Opportunity brief: A 1-page summary of the winning opportunity for leadership sign-off.

Phase 10: Go/No-Go Decision (Week 13)

The go/no-go gate is the most important moment in discovery. It requires a decision from product, engineering, and business leadership that this opportunity is worth building.

Go criteria:

Evidence of real user pain at sufficient scale.
A solution concept that tested positively with target users.
Engineering confidence that the solution is technically feasible within acceptable effort.
Strategic alignment with company priorities.

No-go criteria:

Research revealed the problem is smaller or less painful than assumed.
No solution concept passed prototype testing.
Engineering estimates make the opportunity economically unviable.

No-go is not failure — it is discovery working as designed. Killing a bad idea in week 13 of discovery is far cheaper than killing it in month 6 of engineering.

Phase 11: Handoff to Engineering

If go, create discovery-done acceptance criteria:

User problem being solved (verbatim from research).
User success criteria (how will we know the user's problem is solved?).
Business success metrics (what product metric should move, by how much, in what timeframe?).
Prototype reference (links to all tested prototypes with test notes).
Open technical questions (known unknowns engineering needs to resolve in design).

Building Your Discovery Gantt Chart

In gantt-chart.io, build one row per phase with realistic durations. Mark the go/no-go decision as a hard milestone — no engineering work should start before it. Track participant recruitment separately from research execution. A visible discovery timeline protects the work from being compressed to fill space before a pre-announced launch date — the most common way good discovery produces bad products.