Foundations of Discovery — Key Frameworks & Mindsets

Foundations of Discovery — Key Frameworks & Mindsets

Hunger: Turn curiosity into measurable learning. This cheat sheet helps teams frame the right questions, run quick experiments that produce useful evidence, and keep what you learn discoverable and reusable.

Why this matters

Discovery without clear framing and evidence quickly becomes busywork. Use lightweight, repeatable structures so your team spends energy learning—not arguing about intent or repeating the same failed assumptions.

Quick guidance

Keep discovery hypothesis‑driven, timeboxed, and focused on the riskiest assumption. Prefer fast, cheap experiments that reveal whether an idea is worth scaling. Use shared language so the team evaluates outcomes together.

Hypothesis template (copy/paste)

Write one clear, testable sentence:

If [change or idea], then [measurable outcome], because [assumption].

Example: If we show estimated delivery at checkout, then 10% fewer customers will abandon carts within 30 days because delivery uncertainty increases abandonment.

Evidence hierarchy — what really moves confidence

1. Validated behavior in production (real users perform the target action).
2. Representative A/B tests with pre‑registered metrics and adequate traffic.
3. High‑quality pilot or field trial with real users and operational context.
4. Robust quantitative analytics (be explicit about causation limits).
5. Observational studies and lab usability sessions (good for mechanism).
6. Customer interviews and expert opinion (useful for hypotheses, not validation).

Rule of thumb: use stronger evidence before scaling. Treat interviews as idea generators, not proof.

Systems thinking prompts (avoid local fixes)

• Which stakeholders, processes, or systems will this touch?
• What downstream effects could this create in operations, support, or revenue?
• Are we optimizing a local metric that could worsen the system overall?
• Where is information delayed or hidden that might cause surprises later?

Experiment design checklist (practical & quick)

1. Clear hypothesis using the template above.
2. Primary metric and explicit success criteria (what counts as evidence).
3. Minimum detectable effect or pragmatic threshold (choose a realistic bar).
4. Timebox the test and set a run length.
5. Guardrails and rollback criteria to limit harm or customer impact.
6. Operational plan: who runs it, who monitors, where results are recorded.
7. Pre‑commit to analysis approach and which segments matter.
8. Plan the follow‑up: iterate, scale, or retire based on results.

Starter experiment example (15–30 days)

Hypothesis: If we add a single‑question friction survey on checkout asking, “What stopped you from completing?” then we will learn the top three reasons for cart abandonment within 30 days because many abandoners will answer one very short prompt.

Primary metric: Number and distribution of distinct reasons collected; target = 200 responses. Guardrail: Show once per visitor session; remove if negative support tickets spike above baseline.

Next steps: Prototype the question, run for 30 days, analyze top reasons, design rapid tests to address the top reason.

Team rituals — lightweight and accountable

• Daily check‑in (5–10 min): Each member shares one learning, one blocker, one action. Keep experiments visible.
• Weekly learning huddle (30–45 min): Review outcomes, surface surprising evidence, and decide next steps.
• Opportunity prioritization (biweekly/monthly): Revisit backlog using evidence, customer impact, and effort.
• Hypothesis library maintenance (ongoing): Capture hypotheses, assumptions, and results so the organization learns.

Common discovery pitfalls (and how to avoid them)

• Chasing shiny solutions: Start with the customer problem and the riskiest assumption, not the nicest tech.
• Equating activity with validation: Require measurable evidence before scaling.
• Fragmented discovery: Use shared templates and rituals so teams don’t test incompatible assumptions in parallel.
• Poor experiment design: Pre‑define metrics, guardrails, and analysis to avoid misleading conclusions.

Where to store learnings (minimal useful schema)

Capture experiments in a shared, searchable library to prevent repeated work and build memory. Suggested fields to store for each entry:

• Title / Short description
• Hypothesis (If/Then/Because)
• Primary metric, success criteria, guardrails
• Experiment type (A/B, pilot, survey, qualitative)
• Start / End dates, owner, collaborators
• Traffic / sample size and segments
• Outcome and evidence level (link to data or notes)
• Next recommended action (iterate / scale / retire)
• Tags (product area, customer segment, risk level)

These fields make it easier to search, prioritize, and inherit experiments across teams.

Quick actions — what to do now

1. Pick one high‑uncertainty assumption you can test cheaply this week.
2. Use the hypothesis template and experiment checklist to design a 1–4 week test.
3. Schedule a 30–45 minute learning huddle at the end of the run to decide next steps.

How to adapt this for your team or organization

This cheat sheet is a starting point. Localize it by:

• Adding team‑specific success thresholds and segments.
• Turning the Experiment Checklist into a one‑page form or template in your hypothesis library.
• Packaging this cheat sheet and a few starter experiments into an adoptable toolkit for other teams to copy and iterate on.

Reflective prompts for leaders

• Are we rewarding validated learning or just output (launches, features)?
• Do teams have permission to stop or pivot based on evidence?
• Are we balancing speed with adequate evidence before scaling?

Keep this visible where your team runs experiments. Revisit and adapt as your discovery practice matures — and capture what you learn so others can build on it.