Opportunity & Hypothesis Canvas

Opportunity & Hypothesis Canvas

A concise, practical canvas for turning vague opportunities and complaints into a testable discovery question, prioritized assumptions, measurable success criteria, and a minimum viable experiment. Use this template during a short framing session to align stakeholders, reduce risk, and accelerate learning.

How to use

Fill each section with clear, specific language. Treat the canvas as a hypothesis-building tool: the goal is not to commit to a solution, but to make assumptions explicit and design the smallest experiment that will produce informative evidence. Capture owners and dates so experiments can be run, evaluated, and iterated.

Canvas fields

1. Title / Opportunity statement

   One short sentence that names the opportunity in customer- or process-focused terms (for example: "Reduce friction when customers schedule service visits").

2. Target user, customer, or process

   Who specifically is affected? (persona, role, process step, segment). Include a brief context: when, where, and how they encounter the problem.

3. Desired behavioral or business outcome

   What change do we want to see? Phrase as an observable behavior or business result (e.g., "more bookings completed", "fewer follow-up calls").

4. Hypothesis statement

   Use an if–then–because format: "If we [intervention], then [behavior change] because [assumption about why it works]." Keep it concise and testable.

5. Success metrics (leading and lagging)

   List 1–2 primary metrics: include a lagging metric (business/behavior outcome) and a leading metric (early indicator). For each metric include baseline, target, measurement method, and measurement cadence.

6. Core assumptions (prioritized)

   List customer, value, and technical assumptions. Prioritize them (1 = riskiest / most critical). These are what your experiment should test.

   • Customer assumption: e.g., "Customers will accept a self-scheduling flow instead of calling. (Priority 1)"
   • Value assumption: e.g., "Faster scheduling increases conversions by at least X%. (Priority 2)"
   • Technical assumption: e.g., "Our calendar API can surface available slots reliably. (Priority 3)"
7. Evidence needed

   What specific evidence would confirm, refute, or refine each prioritized assumption? Be concrete (e.g., "10% of contacted customers schedule via prototype flow within 7 days").

8. Minimum test or prototype

   Describe the smallest experiment that could produce the evidence you need. Specify sample, channel, duration, and what will be measured. Include acceptance criteria and a stop condition.

   Example elements: prototype fidelity (clickable mock, concierge test), sample size or segment, timeline, data to collect.

9. Decision criteria

   Define clear outcomes and actions based on results: Scale (what success looks like), Iterate (what partial learning looks like), Stop (what failure looks like). Include any safety, compliance, or cost guardrails.

10. Dependencies, risks, and mitigation

    Note major dependencies (teams, data, tools) and known risks. Add a sketch of how you will mitigate the highest risks during the test.

11. Owner, timeline, and next steps

    Assign an experiment owner, target start and end dates, and 3 immediate next steps with owners and due dates (e.g., prototype build, recruitment, dashboard setup).

Filled example (service friction reduction)

Title: Reduce friction in scheduling service visits

Target user: Residential customers who call to book an appointment after receiving a service reminder email.

Desired outcome: Increase completed online bookings and reduce time spent by call agents.

Hypothesis: If we include a one-click self-scheduling link in the reminder email, then at least 8% of customers will self-book within 7 days because many callers avoid calling due to wait times and prefer fast digital options.

Metrics: Lagging: % of appointments booked without agent assistance (baseline 2% → target 8%). Leading: click-through rate on scheduling link (baseline N/A → target 12%).

Core assumptions: 1) Customers prefer digital booking over calling (Priority 1). 2) The booking flow is simple enough to complete on mobile (Priority 2). 3) Calendar sync works reliably (Priority 3).

Evidence needed: ≥8% self-booking rate within 7 days among recipients who click scheduling link; completion rate on mobile prototype ≥60%.

Minimum test: Send the email with a simple web-based prototype booking flow to a random subset of 1,000 customers for 2 weeks. Track clicks, bookings, drop-off steps, and agent call volumes. Stop if booking flow error rate >10% or if mobile completion <30%.

Decision criteria: Scale if self-booking ≥8% and mobile completion ≥60%; Iterate if self-booking 4–7% with clear drop-off pattern; Stop if self-booking <4% or technical issues dominate.

Owner / timeline: Product lead; experiment start in 3 weeks; duration 2 weeks. Next steps: build prototype (UX, 5d), set up analytics (Engineering, 3d), select test cohort (Data, 2d).

Facilitator prompts & 60-minute framing session

Use this timeboxed agenda for a quick alignment session. Keep discussions focused on assumptions and testability rather than solutions.

1. 5 min — Context & desired outcome

   Quickly state the opportunity and why it matters. Ask: "What outcome would make this worth doing?"

2. 10 min — Target user and behavior

   Clarify who experiences the problem and when. Ask: "Where does the friction happen and what behavior do we want instead?"

3. 10 min — Hypothesis & metrics

   Craft the if–then–because hypothesis and name one lagging and one leading metric. Ask: "How will we know we learned something useful?"

4. 15 min — Identify & prioritize assumptions

   List assumptions on sticky notes and vote to prioritize. Ask: "Which assumption, if false, would kill the idea?"

5. 10 min — Minimum test and decision criteria

   Design the smallest experiment to test the top assumption(s). Define success, iterate, and stop thresholds.

6. 10 min — Owners, risks, next steps

   Assign the experiment owner, confirm dependencies, and agree on the immediate next three tasks with owners and dates.

Common pitfalls

• Framing a solution as the hypothesis — hypotheses should test assumptions, not validate a preferred solution.
• Measuring vanity metrics rather than behavior or business outcomes.
• Running tests without clear decision criteria or stop conditions.

When to use this canvas

Best for early discovery, pre-POC alignment, and small experiments that must quickly reduce uncertainty. Not a replacement for deep domain research or long-run pilots where safety or regulations require extended evaluation.

Suggested next capabilities

• Turn this template into a fillable experiment worksheet and save results for organizational memory.
• Create a lightweight dashboard that tracks active experiments, metrics, and decision outcomes for learning reviews.
• Bundle this canvas into a Discovery & Innovation toolkit (reusable domain) with example experiments, recruitment scripts, and analytics templates.

Notes for implementers

Preserve the canvas structure and facilitator prompts. If you convert this to an interactive form, include stable field keys for metrics, assumptions with priority tags, owner fields, and decision criteria so results can be stored, compared, and surfaced across experiments.