aannames-bedenken

Identificeer de riskante aannames onder je idee of feature. Twee routes (nieuw/bestaand product), multi-perspectief, met risico-prioritering.

Aannames Bedenken

Metadata

Doel: Maak expliciet welke aannames je product- of feature-idee steunt. Niet om ze allemaal gelijk te valideren, maar om te weten welke het meest gevaarlijk zijn als ze fout zijn.

Aanpak: Twee routes afhankelijk van context (nieuw product vs. feature in bestaand product). Multi-perspectief (PM, Designer, Engineer). Integratie van Product Faculty's Leverage Discovery hypothesen. Risico-prioritering: welke aanname raakt je meest als die fout is?

Output: Prioriteised list van 10-15 aannames, top 3 met risico-klassificatie, confidence ratings per aanname (1-5), aanbevolen experiment-type per top-3.

Instructies

Fase 0: Context ophalen

Stap 1 — Check wat er al is Scan uploads, gedeelde mappen en workspace op relevante bestanden (eerdere assumptions-analyses, validatie-experiments, research-notes). Lees ze door.

Stap 2 — Slimme vragen stellen

  • Wel context gevonden → Bevestig kort wat je ziet ("Ik zie [X], klopt dat?"). Stel alleen vragen over wat je nog mist.
  • Geen context → Stel onderstaande vragen.
  1. Het idee: Wat is precies het product-idee of de feature? (Beschrijf in 1-2 zinnen)
  2. De context: Is dit een volledig nieuw product of een feature in een bestaand product?
  3. De bron: Waarom denk je dat dit het juiste antwoord is? (Klantfeedback? Markttrend? Je eigen frustratie?)
  4. Doelgroep: Voor wie is dit? (Vul zo concreet mogelijk in)
  5. Urgentie: Welke aannames zijn cruciaal om volgende week al te valideren, en welke kunnen nog even wachten?

Framework: Twee Routes

Route A: Nieuw Product (6 categorieën)

Als je een volledig nieuw product bouwt, zijn dit de kritieke aannames:

1. VALUE: Hebben mensen dit probleem echt?

  • "Onze doelgroep ervaart dit als een pijnpunt met hoge prioriteit"
  • "Dit probleem kost hun significant tijd/geld/moeilijkheid per maand"
  • "Ze hebben al geprobeerd dit op te lossen (met workarounds of tools)"
  • "Ze zouden actief geld/inspanning willen investeren om dit op te lossen"

Rode vlag: "Ze zeiden dat het interessant leek" is geen aanname dat er waarde is.

2. USABILITY: Kunnen mensen ons product werkelijk gebruiken?

  • "De gebruikersinterface is intuïtief voor onze doelgroep"
  • "De learning curve past bij hun beschikbare tijd/geduld"
  • "Ze hebben de juiste apparaten/vaardigheden/context om dit te gebruiken"
  • "Onboarding duurt niet langer dan X minuten"

Rode vlag: "We bouwen voor tech-savvy users" is in veel markten een dodesteek.

3. FEASIBILITY: Kunnen wij het technisch bouwen?

  • "Met huidiger team en skill-set is dit haalbaar in X maanden"
  • "We hebben geen blockers op 3rd-party integraties/APIs"
  • "De kosten voor hosting/infra passen binnen budget"
  • "Deze tech-stack schaal mee als we groeien"

Rode vlag: "We gaan een AI-model trainen" is geen aanname, dat is engineering-werk. Wel: "We kunnen dit model in goede kwaliteit runnen op gebruiker's apparaat" kan een aanname zijn.

4. VIABILITY: Is dit financieel gezond?

  • "We kunnen dit tegen X prijs verkopen"
  • "Onze target Unit Economics (ratio bv. CAC:LTV) zijn positief op 24 maanden"
  • "Concurrenten prijzen dit ook tegen X, dus dat gat bestaan"
  • "De opslag die we nemen is verdedigbaar vs. waarde"

Rode vlag: "We verkopen tegen $9/maand maar CAC is $500" is een aanname die direct waarschijnlijk fout is.

5. GO-TO-MARKET: Kunnen we klanten bereiken?

  • "Er is een bestaand channel/platform waar onze doelgroep verzameld zit"
  • "Onze boodschap resonates met messaging op die plek"
  • "We hebben toegang tot of budget voor die channel"
  • "Concurrenten gebruiken dezelfde channel, dus het werkt"

Rode vlag: "We zullen viral gaan" is geen Go-to-Market aanname, dat is hoop. "We kunnen betaalde acquisition tot X CAC runnen op Product Hunt" is concreet.

6. STRATEGY: Fit dit in wat we willen zijn?

  • "Dit product strengthens ons brand/positioning"
  • "Dit sluit aan op langetermijn roadmap/vision"
  • "Dit brengt ons niet in directe conflict met bestaande inkomstenbronnen"
  • "Dit helpt ons defensible competitive advantage bouwen"

Rode vlag: "Dit volgt de markt" is het tegenovergestelde van strategie.

Route B: Bestaand Product (4 categorieën)

Als je een feature in een bestaand product toevoegt:

1. VALUE: Zal deze feature het kernprobleem van doelgroep oplossen?

  • "De doelgroep erleeft het huiidigen workflow als pijnlijk in onderdeel X"
  • "Ze hebben aangegeven dat ze bereid zijn dit als eerste te verbeteren"
  • "Deze feature lost het probleem op (niet: voegt mogelijkheid toe)"
  • "Ze zouden dit maanden eerder willen hebben dan feature Y"

Rode vlag: "Product team vindt dit cool" is irrelevant. "3 van onze 5 best customers vroegen hier expliciet om" is relevant.

2. USABILITY: Past dit bij het bestaand product en user behavior?

  • "Onze gebruikers zullen dit feature vinden (discovery)"
  • "De UI/UX past in het bestaand design system"
  • "De workflow onderbreekt niet het bestaand happypath"
  • "Adoption rate zal boven X% liggen (t.o.v. baseline features)"

Rode vlag: "Het past technisch in de codebase" betekent niet dat het usable is.

3. FEASIBILITY: Is dit haalbaarheid in ons development cycle?

  • "Dit past in X sprints zonder huiidig roadmap te blokkeren"
  • "We hebben geen upstream-dependency issues"
  • "Geen onverwachte technical debt risk"

Rode vlag: "We zullen het refactoren" bij feature-adds = scope creep.

4. VIABILITY: Helpt dit onze economie?

  • "Dit verhoogt retention/engagement met Y% (baseline: Z%)"
  • "Dit reduceert support tickets (impact: aantal per maand)"
  • "Dit opens nieuw segment (IAC growth) of verhoogt ARPU"
  • "Dit voorkomt customer churn naar competitor (defensief value)"

Rode vlag: "Dit is nice-to-have" is geen viability-aanname.

Discovery Hypothesen: Een Extra Lens

Buiten deze categorieën, raadpleeg altijd Product Faculty's 4 Core Hypothesen uit Leverage Discovery:

H1: DOELGROEP — Wie dienen we werkelijk?

  • "Ons huiidigen ICP (Ideal Customer Profile) is X"
  • "Dit feature attracts/retains vooral [segment], niet [ander segment]"
  • "We begrijpen de jobs/pains van deze groep goed genoeg om dit te bouwen"

Onderzoeksvraag: Zit dit feature in de top 3 pijnpunten voor dit segment?

H2: ALTERNATIEVEN — Wat gebruiken ze vandaag?

  • "Ze gebruiken huiidigen alternatieven: [A], [B], [C]"
  • "Onze feature is duidelijk beter dan [B] in onderdeel X"
  • "We weten waarom ze niet zelf deze feature in [C] hebben gebouwd"

Onderzoeksvraag: Hoe ziet het huiidigen workflow eruit en waarom is onze feature beter?

H3: VOORDEEL — Wat kunnen wij dat concurrenten niet?

  • "Concurrents features vergelijkbaar, maar wij hebben [defensible voordeel]"
  • "Dit voordeel is moeilijk te kopieren (network, data, positioning)"
  • "Dit voordeel rechtvaardigt onze prijs/positioning"

Onderzoeksvraag: Wat kunnen wij hier uniek doen dat competitors niet makkelijk kunnen copyen?

H4: TREND — Wat maakt dit nu mogelijk?

  • "Marktshift [technologie / regelgeving / behavior] maakt dit relevant nu"
  • "Dit moment voorbij, dit feature wordt irrelevant over 18 maanden"
  • "Onze timing is strategic, niet lukraak"

Onderzoeksvraag: Waarom lukt dit NU en niet vorig jaar? Wat verandert?

Stap 1: Lijst de Kandidaat-Aannames

Werk beide routes parallel (of kies Route A/B afhankelijk van context). Brainstorm per categorie:

Template voor brainstormen:

ROUTE A / ROUTE B: [Categorienaam]

Onze aannames zijn:
1. [Aanname 1 — begin altijd met "We geloven dat..."]
2. [Aanname 2]
3. [Aanname 3]
...

Tip: Elke aanname moet:

  • Falsifieerbaar zijn (niet: "klanten zullen het willen", wel: "minstens 40% van doelgroep zal dit maanden eerder willen hebben dan alternatieven")
  • Observable zijn (niet: "dit is innovatief", wel: "de feature biedt 3x sneller workflow dan huiidigen alternatief X")
  • Gemeten kunnen worden (getal, % of ja/nee observatie)

Stap 2: Multi-Perspectief — PM, Designer, Engineer

Dit is cruciaal. Elke rol heeft ander blinde plekken.

PM-Perspectief

  • Focusseert op VALUE en VIABILITY
  • Risk: overdrijft wat klanten willen; onderschat execution risk
  • Vragen: "Hebben we direct met klanten gesproken? Hebben ze actief om dit gevraagd?"

Designer-Perspectief

  • Focusseert op USABILITY en VALUE (hoe voelt het?)
  • Risk: optimaliseert elegantie boven simplicity; onderschat doelgroep werkelijkheid
  • Vragen: "Wie moet dit echt gebruiken? Wat is hun huiidigen context? Hoe snel moeten ze dit leren?"

Engineer-Perspectief

  • Focusseert op FEASIBILITY en scalability
  • Risk: ziet alleen technical blockers; onderschat user-behavior impact
  • Vragen: "Wat kan fout gaan? Welke dependencies missen we? Wat breekt als 10x meer users dit gebruiken?"

Praktijk: Leid elk perspectief apart 15 minuten, dan merge:

  1. "PM, wat zijn jouw top-3 riskante aannames?"
  2. "Designer, hoe ziet een user dit werkelijk gebruiken? Wat kan misgaan?"
  3. "Engineer, waar zie jij technical risk?"
  4. Merge tot gedeelde top-3 lijst.

Stap 3: Confidence Rating per Aanname

Score elke aanname 1-5:

  • 5: "We hebben dit gevalideerd in 10+ klantgesprekken, alle zeiden ja, en zelfs betaald al"
  • 4: "Klanten hebben dit directe gevraagd, en concurrenten bieden het, dus markt bestaat"
  • 3: "Dit klinkt logisch, maar we hebben het niet direct getest; wel past het in bekende patronen"
  • 2: "Dit is een intelligent gok, maar we hebben weinig data; veel kan hier fout gaan"
  • 1: "Dit is puur speculatie; we hebben geen data of expert consensus"

Belangrijk: Lage confidence = hoge prioriteit voor validatie. Niet het tegenovergestelde!

Stap 4: Risico-Klassificatie

Niet alle aannames zijn even belangrijk. Klassificeer per aanname:

TIG — Tight Integration with Growth

Deze aanname bepaalt of het product überhaupt schaalbaar is. Fout = volledig mislukt.

Voorbeelden:

  • "Er is marktevraag voor dit probleem" (TIGE)
  • "We kunnen economisch klanten bereiken" (TIGE)
  • "Unit economics worden positief op 24 maanden" (TIGE)

TOY — Techno Opportunity Yield

Deze aanname bepaalt of we het technisch kunnen bouwen op schaal.

Voorbeelden:

  • "We kunnen dit op gebruikers-apparaat runnen onder 2s latency" (TOY)
  • "De API's die we nodig hebben zijn beschikbaar" (TOY)

MUST — Must-haves voor product-market fit

Deze aannames bepalen of het product bruikbaar en begeerd is.

Voorbeelden:

  • "Doelgroep vindt deze UI intuïtief" (MUST)
  • "Setup duurt <5 minuten" (MUST)

Rangschikking voor validatie:

  1. TIGE — validate eerst (stop-loss)
  2. MUST — validate tweede (product betreft)
  3. TOY — validate derde (execution betreft)

Stap 5: Top-3 Aannames met Experiment-Type

Selecteer je top-3 meest risicante/laag-confidence aannames. Voor elk:

  1. Aanname (statement)
  2. Huiidigen confidence (1-5)
  3. Waarom dit risicant (als dit fout is, wat gaat er mis?)
  4. Aanbevolen experiment-type (zie overzicht hieronder)

Experiment-Type Overzicht

Route A (Nieuw Product)

  • VALUE-aannames valideer met: Customer interviews (klachten 10+ targets), pretotype (landing page, explainer video), fake door (pre-order/waitlist)
  • USABILITY-aannames valideer met: Prototype usability test (5-8 users), concierge MVP (jij doet het handmatig voor hen)
  • FEASIBILITY-aannames valideer met: Technical spike, proof-of-concept
  • VIABILITY-aannames valideer met: Pricing experiment (fake pricing page), cohort analysis (simulation)
  • GTM-aannames valideer met: Channel test (pilot paid ads), fake door via channel (zie je opscaling)

Route B (Bestaand Product)

  • VALUE-aannames valideer met: A/B test feature (percentage users zien het), cohort analysis (engage rate verschil)
  • USABILITY-aannames valideer met: Prototype in staging (intern + 5-10 power users), heatmap/session recording
  • FEASIBILITY-aannames valideer met: Technical spike, load test
  • VIABILITY-aannames valideer met: Cohort analysis (retention/engagement verschil), revenue impact simulation

Output Checklist

Lever het volgende op:

  1. Volledige aannames-lijst — minimaal 10-15 items, per route/categorie
  2. Confidence-ratings — 1-5 per aanname
  3. Risk-klassificatie — TIGE / MUST / TOY per aanname
  4. Top-3 prioriteit — gerangschikt op risico + lage confidence
  5. Experiment-aanbevelingen — per top-3 aanname, type + korte beschrijving
  6. Merge-rapport — hoe PM, Designer, Engineer het eens zijn (en waar ze het nog niet eens zijn)

Veel Voorkomende Fouten

  • Te veel aannames tegelijk willen valideren — focus op top-3, niet alle 15
  • Confidence overschatten omdat je "voelde dat het klopt" — gevoel is niet data
  • Geen onderscheid tussen TIGE/MUST/TOY — niet alle aannames zijn even kritiek
  • VALUE-aanname confunderen met feature-feedback — "feature klinkt cool" ≠ "probleem is groot"
  • De Designer/Engineer niet echt vragen — monoloog van PM is bias
  • Aanname is te breed ("doelgroep zal het willen") — specifiek maken ("minstens 40% van X zal dit kiezen boven Y")
  • Geen back-up experiment gedefinieerd — "wat doen we als experiment faalt?"

Bronnen

  • Product Faculty — Leverage Discovery (hypothesen H1-H4, prioritering TIGE/MUST/TOY)
  • Teresa Torres — Continuous Discovery Habits (aanname-driven discovery)
  • Marty Cagan — Inspired (risky assumptions)
  • Lean Startup — aanname-testing discipline