Een beslissing zonder informatie duurt langer
Zolang niemand kan zien wat het wordt, gaat het gesprek over aannames. Elke ronde levert nieuwe vragen op en het besluit schuift door, terwijl het probleem blijft liggen.
Geen budget voor een volledig traject, wel voor een proof of concept
Je gelooft in het idee, maar een heel bouwtraject goedgekeurd krijgen lukt niet zolang niemand kan zien waar het over gaat. Beginnen met iets kleins doorbreekt die impasse: eerst laten zien dat het werkt, daarna pas de investering vragen die erbij hoort.
01
/
04
Waarom klein beginnen sneller tot een besluit leidt
Niet omdat het goedkoper is, maar omdat het de discussie verandert.
Kleine stappen vragen minder mandaat
Voor een beperkte stap is vaak minder goedkeuring nodig dan voor een heel traject. Dat maakt het verschil tussen deze maand beginnen en wachten op de volgende begrotingsronde.
Je koopt informatie, geen software
De opbrengst van een eerste stap is niet het prototype zelf maar wat je erdoor te weten komt: of de gebruiker het snapt, of collega's het steunen en of het probleem klopt.
02
/
04
Wat je er wel en niet mee bewijst
Eerlijk over de grens, want een prototype beantwoordt niet elke vraag.
Wat je hiermee toetst
- Of de gebruiker de flow begrijpt en logisch vindt.
- Of collega's en stakeholders het idee steunen.
- Welke vragen er opkomen zodra mensen het zien.
- Of het probleem dat je oplost herkenbaar is.
- Hoe de oplossing eruit zou kunnen zien in de praktijk.
Wat je hiermee niet toetst
- Of het technisch schaalt naar veel gebruikers.
- Of de koppeling met jullie systemen gaat werken.
- Wat het volledige traject uiteindelijk gaat kosten.
- Of het voldoet aan beveiligings- en beheereisen.
- Of mensen er op termijn voor willen betalen.
03
/
04
Hoe zo'n eerste stap verloopt
Een werkdag met een vast ritme, gericht op de vraag die je wilt beantwoorden.
-
09:00
De vraag scherpstellen
Wat moet er na deze dag beslist kunnen worden, en wie beslist dat? Dat bepaalt wat we bouwen.
-
10:00
De flow kiezen
Welk pad laat het beste zien waar het over gaat? We kiezen er een en houden de rest erbuiten.
-
11:30
Scope vastleggen
Wat moet klikbaar zijn om de vraag te beantwoorden, en wat mag statisch blijven?
-
13:30
Bouwen
De flow wordt omgezet in werkende schermen, met voorbeelddata die bij jullie situatie past.
-
15:30
Toetsen op het besluit
We lopen het door met de beslisser in gedachten: welke vraag zou die stellen, en beantwoordt de demo die?
-
17:00
Overdracht
Je krijgt de werkende URL, de aannames en een lijst met wat een vervolg zou vragen.
04
/
04
Van prototype naar een onderbouwd besluit
Wat je erna doet, hangt af van wat de reacties opleveren.
De meest voorkomende uitkomst is dat het gesprek verschuift. In plaats van of we hier iets mee moeten gaat het over welk onderdeel als eerste moet en wat het mag kosten. Dat is een makkelijker gesprek, omdat er iets ligt waar mensen naar kunnen wijzen.
Soms levert het een duidelijke nee op. Ook dat is bruikbaar: je hebt dan een onderbouwing waarom je niet verder gaat, zonder dat er een bouwbudget in is gegaan.
En soms roept het een nieuwe vraag op die je met een andere flow wilt toetsen. Dan is een tweede ronde logischer dan meteen doorbouwen. Wat er bij een echt bouwtraject komt kijken staat in van prototype naar productie. Zit het knelpunt bij jou eerder in de bezetting dan in het budget, kijk dan bij geen development-capaciteit in huis.
05
/
05
Veelgestelde vragen
Wat is het verschil tussen een prototype en een proof of concept?
In de praktijk worden de termen door elkaar gebruikt. Een prototype laat zien hoe iets werkt voor de gebruiker, een proof of concept toont aan dat iets technisch kan. Wat wij in een dag maken zit meestal in de eerste categorie: klikbaar, bedoeld om te tonen en te toetsen.
Waarom zouden we niet meteen het hele traject doen?
Dat kan prima, als de richting al vaststaat en er draagvlak is. Klein beginnen is nuttig wanneer er nog twijfel is over de vraag, de gebruiker of het draagvlak. Dan levert een kleine stap informatie op die de grote beslissing beter maakt.
Helpt dit bij het onderbouwen van een budgetaanvraag?
Meestal wel. Een aanvraag voor iets dat mensen kunnen zien en doorklikken roept andere reacties op dan een beschrijving op papier. Het maakt de discussie concreter, al blijft de uitkomst afhankelijk van je eigen organisatie.
Wat als uit het prototype blijkt dat het idee niet werkt?
Dan heb je dat geleerd zonder dat er een heel traject aan hing. Dat is een van de redenen om klein te beginnen: een idee laten vallen op basis van reacties is goedkoper dan het bouwen en daarna ontdekken.
Kunnen we later op dit prototype doorbouwen?
Het prototype is gemaakt om een vraag te beantwoorden, niet om live te gaan. Bij een vervolg kijken we wat er herbruikbaar is en wat opnieuw moet, omdat productie andere eisen stelt aan code, beveiliging en beheer.
Hoeveel tijd kost het ons intern?
Een intake vooraf en beschikbaarheid op de dag zelf voor vragen en keuzes. Daarna heb je iets in handen dat je zelf kunt laten zien, zonder dat wij erbij hoeven te zijn.
