# Discovery Assumptions & Risks Workshop

> **Formats:** Markdown (canonical) | DOCX | PDF | Miro/FigJam
> **Updated:** 2026-03-22
> **License:** CC BY 4.0 -- Kate Makrigiannis / k8mak.com

A 4-step team activity for surfacing your riskiest assumptions, ranking them by impact, and choosing discovery activities to test them before you build the wrong thing.

## When to use this

You're starting a new initiative, entering a discovery phase, or your team is about to invest significant effort in something nobody has validated yet. This workshop helps a cross-functional team generate assumptions, identify which ones carry the most risk, and pick concrete activities to reduce uncertainty. Run it in 60-90 minutes with 4-8 people.

---

## Process

### Step 1: Generate assumptions through three lenses

Split your assumptions into three categories. Each lens surfaces a different type of risk.

**Set up three columns on your board:**

| Viability | Desirability | Feasibility |
|---|---|---|
| Will this work as a business? | Do people actually want this? | Can we build this? |

**Viability assumptions** -- business model, revenue, cost, regulatory, market timing:
- "Clinics will pay $15/month per provider seat"
- "Our licensing model works in the EU market"
- "We can launch before the regulatory deadline in Q3"

**Desirability assumptions** -- user need, willingness to adopt, behavior change:
- "Patients will log their vitals daily without reminders"
- "Pharmacists will use a digital checklist instead of their paper workflow"
- "Parents will trust an AI-generated care recommendation"

**Feasibility assumptions** -- technical capability, team capacity, integration, timeline:
- "Our API can handle 10x current load without re-architecture"
- "We can integrate with the EHR system in 4 weeks"
- "The ML model will reach 90% accuracy with our current training data"

**How to run it:**
- Silent brainstorm: 8-10 minutes, one assumption per sticky note
- Each person writes assumptions they believe the team is making -- stated or unstated
- Encourage "uncomfortable" assumptions. The ones nobody wants to say out loud are usually the riskiest.
- Aim for 15-25 total assumptions across the three columns

**Facilitator prompt:** "What are we assuming is true that, if wrong, would sink this initiative?"

---

### Step 2: Stack-rank by impact

Now prioritize. Not all assumptions carry equal risk.

**For each assumption, ask:** "If this assumption is wrong, how bad is it?"

- **High impact:** The initiative fails or requires a major pivot
- **Medium impact:** Significant rework or delay, but recoverable
- **Low impact:** Minor adjustment needed

**How to run it:**
- Read each assumption aloud (group similar ones first)
- Quick team vote: high, medium, or low impact (dot-vote or thumbs up/down/sideways)
- Move high-impact assumptions to the top of each column
- Don't debate for more than 1 minute per assumption. If the team can't agree quickly, mark it as "high" and move on -- disagreement about impact is itself a signal.

---

### Step 3: Plot on the impact-vs-confidence matrix

Take your high-impact assumptions and place them on a 2x2 matrix.

```
                    High Impact
                         |
    ┌────────────────────┼────────────────────┐
    │                    │                    │
    │   RISKIEST         │   VALIDATED        │
    │   High impact,     │   High impact,     │
    │   low confidence   │   high confidence  │
    │                    │                    │
    │   → TEST THESE     │   → MONITOR        │
    │     FIRST          │     (already have   │
    │                    │      evidence)      │
    ├────────────────────┼────────────────────┤
    │                    │                    │
    │   WORTH CHECKING   │   SAFE TO ASSUME   │
    │   Low impact,      │   Low impact,      │
    │   low confidence   │   high confidence  │
    │                    │                    │
    │   → TEST IF TIME   │   → PARK           │
    │     ALLOWS         │                    │
    └────────────────────┼────────────────────┘
                    Low Impact
        Low Confidence       High Confidence
```

**How to assess confidence:**
- **High confidence:** You have data, research, or direct user feedback supporting this assumption
- **Low confidence:** This is a guess, an opinion, or based on what happened at a previous company

**Focus on the top-left quadrant: high impact, low confidence.** These are your riskiest assumptions -- the ones that could sink the initiative and that you have no evidence for. Pick the top 2-3 for discovery activities.

---

### Step 4: Select discovery activities for your riskiest assumptions

For each of your top 2-3 riskiest assumptions, choose a discovery activity that will give you evidence.

**Common discovery activities by assumption type:**

| Assumption Type | Discovery Activities |
|---|---|
| **Desirability** (do people want this?) | User interviews, surveys, prototype testing, landing page test, concierge MVP, Wizard of Oz test |
| **Viability** (does the business model work?) | Pricing experiments, competitor analysis, financial modeling, pilot program, letter of intent from customers |
| **Feasibility** (can we build it?) | Technical spike, proof of concept, architecture review, vendor evaluation, load testing |

**For each selected activity, capture:**

```
Assumption: (The specific assumption to test)
Activity: (What you'll do to test it)
Evidence needed: (What result would confirm or invalidate the assumption?)
Owner: (Who runs this activity?)
Timeline: (When will we have results?)
```

**Rules for good discovery activities:**
- The activity should produce evidence, not opinions. "Ask 5 users" beats "discuss in the team meeting."
- Set a decision threshold before you start. "If fewer than 3 out of 8 users complete the task, we pivot." Deciding the bar after you see results is confirmation bias.
- Timebound everything. Discovery that runs indefinitely is procrastination.
- Cheap and fast beats thorough and slow. You're reducing uncertainty, not writing a research paper.

---

## Worked example

**Context:** A health-tech startup is building a medication adherence app for elderly patients.

**Assumptions generated (18 total, showing the 6 highest-impact):**

| Assumption | Lens | Impact | Confidence |
|---|---|---|---|
| Elderly patients will use a smartphone app daily | Desirability | High | Low |
| Caregivers will set up the app on behalf of patients | Desirability | High | Low |
| We can integrate with 3 major pharmacy chains' APIs | Feasibility | High | Low |
| Insurance will reimburse for digital adherence tools | Viability | High | Medium |
| Push notifications improve adherence by 20%+ | Desirability | Medium | Medium |
| Our team can ship an MVP in 8 weeks | Feasibility | Medium | High |

**Top 3 riskiest (high impact, low confidence):**

1. **Elderly patients will use a smartphone app daily**
   - Activity: 5 in-home observation sessions with patients 65+ managing 3+ medications
   - Evidence needed: 4/5 participants can complete the core "mark medication taken" flow without assistance
   - Owner: UX researcher (Maria)
   - Timeline: 2 weeks

2. **Caregivers will set up the app on behalf of patients**
   - Activity: Prototype test with 6 caregiver-patient pairs using a clickable Figma prototype
   - Evidence needed: Caregivers complete setup in under 10 minutes; patients can use the app after caregiver leaves
   - Owner: Product designer (James)
   - Timeline: 2 weeks (run concurrently with activity 1)

3. **We can integrate with 3 major pharmacy chains' APIs**
   - Activity: Technical spike -- review API documentation, contact developer relations at CVS, Walgreens, Rite Aid
   - Evidence needed: At least 2 of 3 have public or partner APIs that support medication list access
   - Owner: Tech lead (Priya)
   - Timeline: 1 week

---

## Facilitator tips

- **Separate assumption generation from evaluation.** Don't let the team debate whether an assumption is risky while they're still brainstorming. Generate first, evaluate second. Mixing the two kills creativity and surfaces fewer assumptions.
- **Unstated assumptions are the dangerous ones.** Push the team to name what everyone "just knows." "Our users have reliable internet access" might be an assumption nobody questions -- until it breaks your product.
- **The three lenses prevent tunnel vision.** Engineering teams over-index on feasibility. Product teams over-index on desirability. Business teams over-index on viability. The three-lens structure forces all three perspectives into the room.
- **2-3 discovery activities is the right number.** More than that means you're not prioritizing -- you're doing all the research. Pick the assumptions that, if wrong, would change what you build.
- **Revisit the matrix as you learn.** After each discovery activity, update the assumption's confidence level. Some will move from "riskiest" to "validated." Others will reveal new assumptions you didn't see before.
- **"We already know" is the most dangerous phrase in this workshop.** If someone says it, ask: "What evidence do we have?" If the answer is anecdote or intuition, it stays in the low-confidence zone.

---

## Appendix: Common assumptions by phase

**Early discovery (problem space):**
- The problem we're solving exists and is painful enough for people to seek a solution
- The target users are reachable through our planned channels
- The market is large enough to sustain the business

**Solution design:**
- Users will understand how to use this without training
- This solution is meaningfully better than what users do today
- Users will switch from their current solution

**Pre-launch:**
- Our pricing is within the target customer's budget and perceived value
- We can acquire users at a cost that sustains the business model
- Our infrastructure can handle the expected load at launch

---

## How did it go?

After the workshop, check:

- [ ] The team generated assumptions across all three lenses (viability, desirability, feasibility) -- not just one
- [ ] At least 15 assumptions were surfaced (fewer usually means the team self-censored)
- [ ] High-impact assumptions were identified through team voting, not one person's opinion
- [ ] The top 2-3 riskiest assumptions have specific discovery activities with owners and timelines
- [ ] Each discovery activity has a clear "what evidence would change our mind" threshold
- [ ] The team left with a concrete plan, not just a decorated whiteboard

---

## Miro/FigJam board setup

To run this workshop digitally, set up your board with these zones:

1. **Brainstorm zone:** Three columns (Viability / Desirability / Feasibility) with space for 25+ sticky notes
2. **Ranking zone:** A single column where high-impact assumptions are stacked top-to-bottom
3. **Matrix zone:** 2x2 grid labeled Impact (vertical) and Confidence (horizontal) with quadrant labels
4. **Action plan zone:** Table with columns for Assumption, Activity, Evidence Needed, Owner, Timeline
5. **Parking lot:** Space for assumptions that need more discussion outside the workshop

Pre-populate each zone with the column headers and labels before the session starts.

---

*Part of the [k8 Agent Toolkit](https://k8mak.com/agent-toolkit). Download other formats at k8mak.com/resources.*