Foundations: Curiosity & Opportunity Framing

Welcome — why framing matters

Discovery feels exciting until teams pursue different ideas, run misleading experiments, or mistake activity for validated insight. Good framing turns curiosity into a small, testable question you can learn from quickly. This guide gives straightforward mindsets, tools, and team exercises you can use immediately to frame high‑value discovery work and prioritize experiments that produce meaningful learning.

What this orientation helps you do

• Create shared thinking and language so team members focus on the same problem.
• Make assumptions explicit so experiments target the riskiest beliefs.
• Form testable hypotheses and pick low‑cost-first experiments that deliver fast evidence.
• Avoid common framing traps that waste time or produce misleading results.

Core mindsets to adopt

1. Curiosity with direction: Ask open questions, but aim to narrow them quickly into testable scopes.
2. Falsifiability: A useful hypothesis is one that could be proven wrong by evidence. If you cannot imagine what would disprove it, it’s not yet testable.
3. Value‑first thinking: Focus on outcomes and customer or system value, not on solutions. Frame around the change in behavior or metric you expect.
4. Fail fast, learn fast: Prefer cheap, fast experiments that reduce the most uncertainty early.

Simple framing tools (templates you can use right away)

1. Problem statement (one short paragraph)

Template: For [user / population], when they do/experience [situation], they currently do/feel [behavior / pain]. This matters because [impact]. Evidence: [qual or quant evidence].

Example: For first‑time buyers on our mobile checkout, when they hit the payment screen they abandon at a 25% higher rate than web. This matters because these users are our fastest‑growing segment and abandonment reduces conversion by ~8%. Evidence: analytics funnel, three user interviews.

2. Stakeholder map (quick sketch)

Make a one‑page map showing primary users, secondary users, internal stakeholders, and external partners. Note each group's main goal and what success looks like for them. This reveals competing incentives and who you should include in experiments or interviews.

3. Assumptions map

List beliefs that must be true for your idea to deliver value, and tag each with uncertainty (High / Medium / Low) and impact (High / Medium / Low). Prioritize experiments to address high‑impact, high‑uncertainty assumptions first.

4. Testable hypothesis (compact formula)

Formula: If we introduce/change [action], then measurable outcome will increase/decrease by [amount] in [timeframe], because assumption.

Example: If we simplify the mobile payment form to a single page, then conversion rate will increase by 6 percentage points within 4 weeks because users currently drop off due to perceived complexity.

Recommended first experiments (choose one or two)

Prefer experiments that give clear evidence about the riskiest assumption, are cheap to run, and can be stopped early if results are unpromising.

• Smoke test / Landing page: Create a simple page describing the offering and measure sign‑ups or interest. Good for gauging demand before building product.
• Concierge or Wizard of Oz: Manually deliver the service behind the scenes to learn real user behavior without development.
• Prototype test: Clickable or paper prototype tested with 5–8 users to observe first reactions and identify major usability gaps.
• Split test: Small A/B test on a single variable (copy, layout) when you have enough traffic for meaningful comparison.
• Expert or stakeholder interviews: Structured interviews to validate assumptions about needs, constraints, and decision criteria.

Prioritization: a compact rubric

Score ideas by Impact × Confidence / Effort. Start with items that promise medium–high impact, low confidence (unknowns), and low effort. This surfaces experiments that reduce the most risk per dollar and time spent.

Team exercises (fast, facilitation‑ready)

Exercise A — 30 minutes: Rapid problem framing

1. Split into small groups (3–5 people).
2. Each group writes a one‑paragraph problem statement using the template (10 minutes).
3. Rotate statements, and each group adds missing evidence or clarifying questions (10 minutes).
4. Discuss as a whole group: choose one statement to convert into a hypothesis and an experiment (10 minutes).

Exercise B — 45 minutes: Assumptions blitz & experiment plan

1. Map assumptions on sticky notes and place on a 2×2 grid (Impact vs Uncertainty) — 15 minutes.
2. Select the top 1–2 high‑impact, high‑uncertainty assumptions — 5 minutes.
3. Design a 1–2 week experiment for each assumption (who, what, measure, stop criteria) — 25 minutes.

Common framing mistakes and how to avoid them

• Chasing solutions not problems: Avoid starting with a feature. Start with a user behavior or metric you want to change.
• Vague hypotheses: If you can’t specify how to measure success, refine the hypothesis until you can.
• Over‑engineering early experiments: Expensive pilots hide learning. Replace costly pilots with rapid proxies where possible.
• Equating activity with validation: Interviews and demos are informative, but only measurable outcomes or observed behavior validate a hypothesis.
• Ignoring stakeholders: Not identifying internal constraints early leads to surprises when scaling or implementing.

Next steps and checklist

Before you run an experiment, confirm:

• Problem statement is clear and evidence is documented.
• Top assumptions are listed and prioritized.
• Hypothesis uses the testable formula and includes a measurable outcome.
• Experiment has a clear duration, owner, sample size/traffic expectations, and stop criteria.
• Decision rule is defined: what will you do if evidence supports or refutes the hypothesis?

How to adapt this orientation to your context

Use the mini‑exercises as meeting agendas, embed the templates in your team docs, and run at least one rapid experiment within two weeks of framing. If you operate in regulated or safety‑critical contexts, add compliance and risk checks before experimenting and involve appropriate stakeholders early.

Examples & quick reference

Problem → Hypothesis → Experiment (compact example)

Problem: New users drop off after account creation; onboarding completion is 40% in first week.

Hypothesis: If we show a progress‑based onboarding checklist after signup, onboarding completion will increase by 20% in 30 days because users lack a clear next step.

Experiment: Build a lightweight checklist overlay (no backend changes), expose to 25% of new users for 4 weeks, measure completion. Stop early if no positive trend after 2 weeks.

Closing — keep discovery lightweight and shared

Framing is not a one‑time step — it’s a shared discipline that keeps teams aligned, reduces waste, and accelerates meaningful learning. Use the templates, run short experiments, and treat results as evidence to revise the next framing cycle.