# Assumption Mapping

Assumption mapping hjelper teamet med å identifisere, prioritere og designe eksperimenter for de kritiske antakelsene bak en idé eller løsning — slik at vi reduserer risiko *før* vi bygger.

**Initiativ / mulighet:**
**Teamet:**
**Dato:**
**OST-node:** [Hvilken node i Opportunity Solution Tree dette gjelder]
**OST-sti:** [Full sti: Utfall → Mulighet → Løsning]

---

## Steg 1 — Identifiser hypoteser

Gjør gjerne dette som en workshop med teamet — post-its, Figma eller whiteboard.

Hver hypotese bør være sporbar til en spesifikk node i OST. Se [`../discovery/ost-guide.md`](../discovery/ost-guide.md) for hvordan antakelser kobles til trenivåer.

Skriv ned hypoteser for hver risikokategori:

**Desirability (Verdi / Bruk):**
*Antagelser om at brukerne vil ha dette og vil bruke det.*
- H1: [Vi antar at brukere...]
- H2:
- H3:

**Feasibility (Teknologi):**
*Antagelser om at vi teknisk kan bygge og drifte dette.*
- H4:
- H5:

**Viability (Forretning):**
*Antagelser om at dette er bærekraftig fra et forretningsperspektiv.*
- H6:
- H7:

**Tips:**
- Ulike farger per kategori gjør det lettere å se mønstre
- Hypotesene bør være spesifikke — ikke "folk vil like dette" men "behandlere over 45 år vil bruke funksjonen uten opplæring"
- Én hypotese per post-it, kort og presis

---

## Steg 2 — Prioriter hypoteser

Plasser hypotesene i et 2×2-kart:

```
KRITISK (mislykkes hvis feil)
│
│    [Kritisk + lite bevis]    [Kritisk + mye bevis]
│    ← TEST DISSE FØRST         ← Bekreft disse
│
│    [Ikke-kritisk + lite]     [Ikke-kritisk + mye]
│    ← Lav prioritet            ← Aksepter og gå videre
│
└─────────────────────────────────────────────────
         LITE BEVIS         MYE BEVIS
```

**X-aksen (bevis):**
- Venstre: liten eller ingen evidens som støtter hypotesen
- Høyre: sterk, relevant, nylig evidens

**Y-aksen (viktighet):**
- Øverst: kritisk — hvis denne hypotesen er feil, vil initativet mislykkes
- Nederst: ikke-kritisk — feil her er håndterbart

---

## Steg 3 — Design eksperimenter

For de mest kritiske og lite bevisste hypotesene — design eksperimenter:

| Hypotese | OST-node | Kritisk? | Bevis? | Eksperiment | Metode | Suksesskriterium | Eier | Tidslinje |
|---|---|---|---|---|---|---|---|---|
| H1: [...] | [Node] | Ja | Lite | [Beskriv] | Brukertest / Intervju / A/B / Concierge | [Hva er "bevist"?] | | |
| H2: | | | | | | | | |
| H3: | | | | | | | | |

**Eksperimenttyper (billigst til dyreste):**
1. **Ekspertintervju** — Spør noen som vet om dette er et reelt problem
2. **Brukerintervju** — Utforsk atferd og behov i dybden
3. **Konsepttest** — Vis en idé (ikke kode) og mål reaksjon
4. **Prototype-test** — La brukere navigere en klikkbar prototype
5. **Concierge** — Lever tjenesten manuelt for å bekrefte etterspørsel
6. **Smoke test / landing page** — Mål interesse før noe er bygget
7. **A/B-test** — Test to versjoner i produksjon

---

## Eksperimentlogg

*Oppdateres løpende etter hvert som eksperimenter kjøres.*

| Eksperiment | Hypotese | Resultat | Lærdom | Neste steg |
|---|---|---|---|---|
| | | Bekreftet / Avkreftet / Mer kompleks | | |

---

## Compare-and-contrast

Torres' prinsipp: test alltid minst 2 løsninger per mulighet. Bruk tabellen under for å dokumentere sammenligningseksperimenter.

| Mulighet (OST) | Løsning A | Løsning B | Felles suksesskriterium | Resultat A | Resultat B | Valg + begrunnelse |
|---|---|---|---|---|---|---|
| [Mulighet fra OST] | | | [Samme metrikk] | | | |

---

## Status per hypotese

| Hypotese | OST-node | Status | Sist oppdatert |
|---|---|---|---|
| H1: | | ⬜ Utestet / 🟡 Under testing / ✅ Bekreftet / ❌ Avkreftet | |
| H2: | | | |
