Product Discovery

Purpose: Align the team on a problem worth solving before committing to a solution

How to run this meeting

Start by anchoring the conversation in the problem, not the solution. A common failure mode is arriving at a discovery meeting with a solution already in mind and working backward to justify it. Use Jobs-to-be-Done framing — "When [situation], I want to [motivation], so I can [outcome]" — to stay grounded in what customers are actually trying to accomplish. The problem statement should be agreed upon before any solutions are discussed.

Maintain a strict separation between the problem space and the solution space. Spend at least the first half of the meeting on evidence, hypotheses, and problem clarity. When the group is ready to explore solutions, use "How Might We" (HMW) framing to keep ideas generative rather than prescriptive — "HMW make it easier for admins to audit user permissions" opens more options than "We should add an audit log."

Keep the meeting small: the PM, a designer, and one or two engineers is usually the right core group. Bring in customer-facing roles (support, sales, CS) when you have them. Timebox each section ruthlessly — discovery meetings that drift into open-ended brainstorming rarely produce useful outputs. End with a clear list of experiments or next steps, not a solution commitment.

Before the meeting

• Pull 3–5 pieces of customer evidence (support tickets, interview quotes, session recordings, survey data)
• Draft a working problem statement and circulate it 24 hours in advance
• Identify the customer segment this problem affects most
• Review any prior research or related discovery work
• Decide who owns the HMW facilitation

Meeting Details

• Date:
• Facilitator:
• Attendees:
• Duration: 60–90 minutes

---

Problem Statement

State the problem in one or two sentences from the customer's perspective. Avoid implying a solution. The group should agree on this statement before moving on.

When Meridian's compliance team runs a quarterly access audit, they have no way to see a history of who granted or revoked permissions — only the current state. This forces them to reconstruct changes manually from Slack and email threads, which takes days and introduces errors.

---

Customer Evidence

List the data points that validate this problem exists and matters. Quotes, ticket counts, NPS verbatims, and interview findings all count. Cite sources so evidence can be traced back.

• Support ticket volume: 14 tickets tagged "permissions-audit" in Q4, up from 3 in Q3
• Customer interview (Meridian, 2024-11-12): "We literally have someone go through Slack DMs to reconstruct who changed what. It's embarrassing."
• Churn survey (Acme Corp, 2024-10-28): Listed "lack of audit trail" as a top-3 reason for not renewing
• NPS verbatim (score: 4): "Great product but no audit log means we can't use it for SOC 2 compliance"
• 3 enterprise prospects flagged this in sales calls last quarter (source: Salesforce notes)

---

Hypotheses

Write hypotheses in falsifiable form: "We believe [claim] because [evidence]. We'll know we're right if [measurable signal]."

• We believe compliance-focused customers will pay a premium for audit log access because they cite it as a blocker to renewing. We'll know we're right if 80% of affected accounts upgrade to a plan that includes it within 90 days of launch.
• We believe the core job is "prove to an auditor that access was controlled correctly," not "monitor for unauthorized changes in real time." We'll know we're wrong if customers prioritize real-time alerting over historical export during usability testing.

---

Possible Solutions

Capture solution ideas without evaluating them yet. Use HMW framing to keep this generative. Evaluation comes later.

• HMW: Make the current permission state easy to export for auditors?
• HMW: Give admins a timeline view of all permission changes?
• HMW: Integrate with existing compliance tools (Vanta, Drata) so this isn't manual?
• HMW: Let admins annotate changes with a reason at the time they make them?
• HMW: Generate a pre-formatted audit report for common frameworks (SOC 2, ISO 27001)?

---

Experiments

What's the fastest way to test the riskiest hypothesis? Define the experiment, what you'll measure, and how long it runs.

---

Next Steps

Concrete owners and deadlines. No action item should be "TBD."

• @priya to schedule 3 customer calls with affected accounts by 2024-12-06
• @design-team to prototype CSV export flow for usability testing by 2024-12-13
• @marcus to pull full support ticket list and tag by customer segment by 2024-12-04

---

Action Items

Follow-up

Share these notes with the full product team within 24 hours. If experiments are approved, create tracking issues and link them here. Schedule a follow-up discovery sync once the first round of customer calls is complete. The PM should update the problem statement if new evidence changes the framing.