Introductie
Versie één bestaat om te leren. Niet om te imponeren. Niet om te schalen. Niet om iedere stakeholder tevreden te stellen.
De meeste startups bouwen versie drie voor ze versie één lanceren. Dat vertraagt leren en vergroot risico. Een kleinere versie produceert meestal betere feedback, niet omdat het team lui is, maar omdat de feedback het hele punt is.
Dit kader helpt je beslissen wat in v1 blijft, wat v2 wordt en wat helemaal van de roadmap verdwijnt.
Wat het oplost
Wat een scherpe v1 levert
-
Een helder leersignaal
Een smalle v1 produceert een helder signaal: klanten vinden de waarde of ze vinden hem niet. Een brede v1 produceert een troebel signaal waar meerdere features iedere observatie verdunnen.
-
Een ship-bare datum
Kleinere scope ship sneller. Sneller shippen betekent eerdere feedback, snellere iteratie en lagere kost van fout zitten. De meeste v1-tijdlijnen krimpen dramatisch zodra de scope eerlijk is.
-
Lagere veranderkost
Twee features verwijderen na de launch is normaal. Vijftien is een rewrite. De kleinere v1 houdt de kost van richting veranderen binnen het budget dat je hebt.
-
Sneller team-leren
Teams leren product, klanten en operaties door een live product te draaien. Hoe langer v1 erover doet om te shippen, hoe langer het team wacht om te leren, en pre-launch kennis is vrijwel altijd op specifieke manieren fout die het team nog niet kan benoemen.
-
Een verdedigbaar verhaal
Een v1 die één ding goed doet is makkelijker te positioneren, te demonstreren en aan te bevelen dan een v1 die tien dingen slecht doet. Het verhaal dat je over v1 kunt vertellen zet de verwachtingen voor v2.
Wat het niet oplost
Wat een kleine v1 niet oplost
-
Een onheldere hypothese
Een kleine v1 vereist nog steeds dat je weet wat je toetst. Zonder hypothese produceert kleinere scope kleinere ruis, geen sterker signaal.
-
Ontbrekende distributie
Wat in v1 ship moet nog steeds klanten bereiken. Een perfecte minimale v1 zonder publiek is een gesloten-circuit experiment.
-
Founder-besluiteloosheid
V1-scope groeit op wanneer de founder niet kan beslissen wat core is. Kleinere scope zonder de onderliggende beslissing stelt de beslissing alleen uit naar de launchweek.
-
Operationele onvolwassenheid
Een kleine v1 heeft nog steeds monitoring, support en een manier om incidenten op te lossen nodig. Klein betekent niet slordig, het betekent bewust.
-
Stakeholder-politiek
Iedere stakeholder heeft een feature die hij essentieel acht. Een kleine v1 dwingt die gesprekken eerder af, niet later. Zonder politieke helderheid eindigt de v1-onderhandeling nooit.
Beslisboom
Zes vragen om v1 te schalen
Run iedere kandidaat-feature door deze vragen. De nee's houden v1 ship-baar en het leersignaal sterk.
- Vraag 01
Wat is het core klantprobleem?
Nee → Benoem het voor je scope. Een v1 zonder benoemd probleem is een v1 die nooit eindigt.Ja → Bevestig met een klant die het probleem in eigen woorden beschreef. Als je er geen kunt vinden, is het probleem nog niet specifiek genoeg. - Vraag 02
Wat is de minimum workflow?
Nee → Map de workflow end-to-end. Iedere stap die niet strikt vereist is, is een kandidaat voor verwijdering.Ja → Bevestig dat de workflow een schoon begin, een schoon einde en één uitkomst heeft. Meerdere uitkomsten betekenen meerdere workflows, en meerdere workflows betekenen meerdere v1s. - Vraag 03
Wat kan eruit?
Nee → Probeer harder. Iedere v1 bevat meer dan hij nodig heeft; eruit halen is het werk.Ja → Verplaats het naar een 'niet in v1'-lijst, met een datum om opnieuw te bekijken. Lijsten met datums verslaan lijsten zonder. - Vraag 04
Wat kan handmatig?
Nee → Automatiseer het kleinste wat je moet. Al het andere kan een mens in de loop zijn voor de eerste weken.Ja → Houd het handmatig. Handmatige operaties leren je wat te automatiseren; automatisering verbergt wat je moet leren. - Vraag 05
Wat kan wachten tot versie twee?
Nee → Definieer v2 expliciet. Een v2-lijst krimpt v1 omdat alles aspirationals daarheen kan.Ja → Bevestig door v1-scope terug te lezen en iedere feature tegen de v2-lijst te toetsen. Wat in v2 past, hoort daar. - Vraag 06
Wat moet bestaan om waarde te bewijzen?
Nee → Definieer bewijs concreet. 'Klanten vinden het leuk' is geen bewijs; een klant die tekent, betaalt, terugkomt of aanbeveelt wel.Ja → Bevestig dat het bewijs in de eerste 30 dagen na launch waarneembaar is. Bewijs dat een kwartaal kost is te traag om v1 te informeren.
Veelgemaakte fouten
Vijf veelgemaakte fouten
- 01
Toekomstige features bouwen
Founders voegen features toe voor de klant die ze hopen over achttien maanden te hebben. Die features tellen zelden voor de klant tegenover hen, en ze vertragen de launch die zou leren of de toekomstige klant echt is. Bouw voor vandaag; de toekomstige klant stemt nog niet.
- 02
Te vroeg schaalbaarheid bouwen
Een v1 ontworpen voor 100.000 gebruikers op dag één is een v1 die niet ship voor de eerste 100. Schaalbaarheid is het juiste probleem in de verkeerde fase; bouw voor de klanten die je hebt, schaal wanneer het moet.
- 03
Te vroeg admin-tools bouwen
Admin-panels, rolsystemen, audit logs en uitgebreide dashboards zijn echt werk. Op v1 kan het meeste van dat werk in een database-client of een spreadsheet, en het operationele leren is waardevoller dan de polish.
- 04
Te veel automatiseren
Automatisering voor je de workflow begrijpt, codeert de verkeerde regels. Handmatige processen zijn traag, informatief en makkelijk te veranderen. Automatiseer nadat de regels helder zijn, niet ervoor.
- 05
Investeerders proberen te imponeren
Een indrukwekkende v1 is zelden een leerbare v1. Investeerders die ertoe doen verkiezen bewijs van klant-leren boven bewijs van engineering-inzet. Bouw voor klantsignaal; het investeerdersverhaal volgt.
Alternatieven
Praktische patronen voor v1
Vier patronen die een v1 shippen die snel leert zonder kwaliteit op te offeren.
-
Single-workflow v1
Kies één klantworkflow, bouw hem goed, negeer de rest. Zelfs heel kleine v1s produceren sterk signaal wanneer de workflow scherp is. De juiste default voor vrijwel ieder vroeg product.
-
Concierge v1
Lever de waarde als dienst voor je hem automatiseert. Traag, klein, maar het leert je de operationele realiteit van het product, en wat klanten werkelijk geautomatiseerd nodig hebben.
-
Spreadsheet v1
Run het vroege product in een gedeelde spreadsheet voor de eerste tien klanten. Veel bedrijven hebben hun kernwaarde zo gevalideerd zonder een regel productiecode te schrijven.
-
Wizard-of-Oz v1
Serieus ogende interface, mensen runnen de back-end. Klanten ervaren het product; het team ervaart de operationele kost, en leert wat eerst geautomatiseerd moet worden.
Vuistregel van Ronald
Versie één moet waarde bewijzen, geen ambitie.
Ambitie hoort in v3, v5 en het deck. V1 heeft een ander werk: het kleinst mogelijke product produceren waarmee klanten waarde voelen en het team kan zien of die waarde echt is. Verwar de twee en v1 wordt een v3 die drie keer zo lang duurt en een derde zo veel leert.
, Ronald · YourStartup.Expert
Samenvatting
Samenvatting
V1 is een leerartefact. De zes vragen hierboven veranderen 'wat moeten we eerst bouwen?' in een beslissing die het team kan verdedigen: het kernprobleem, de minimum-workflow, de schrappingen, de handmatige delen, de v2-lijst en het bewijspunt. Alles wat niet aan dat leersignaal bijdraagt, hoort elders, meestal op een lijst, soms in de prullenbak.
De meeste v1-tijdlijnen klappen ineen zodra de scope eerlijk is. Het team dat een scherpe v1 in acht weken ship, leert in het volgende kwartaal meer dan het team dat een uitgestrekte v1 in twintig weken ship. Kleiner is geen compromis; het is de ontwerpkeuze die alles na v1 goedkoper maakt.
Veelgestelde vragen
Versie één, beantwoord.
De vragen die founders stellen voor ze de v1-scope bevriezen.
- Wat hoort in versie één?
- Wat nodig is om de core klantwaarde te leveren via één workflow, plus het absolute minimum aan infrastructuur om die workflow live te draaien, basale monitoring, een manier om issues op te lossen, een manier om feedback te verzamelen. Al het andere hoort op een v2-lijst, in een parkeerplaats voor toekomstige herzieningen, of in de prullenbak. De toets: als een feature weggehaald kan worden zonder de core waarde te vernietigen, hoort hij niet in v1.
- Hoe klein moet versie één zijn?
- Klein genoeg om in acht tot twaalf weken te shippen, klein genoeg om end-to-end te veranderen in één sprint na launch, en klein genoeg dat het team hem in één zin kan beschrijven zonder het woord 'en' te gebruiken. Als je v1 langer dan drie maanden duurt of meer dan één core workflow heeft, is het een v3 verkleed als v1, en het team betaalt de prijs in vertraagd leren en verhoogd rework.
- Moet versie één schalen?
- Nee. V1 moet betrouwbaar zijn, niet schaalbaar. Betrouwbaar betekent dat de workflow werkt voor de eerste 50 klanten; schaalbaar betekent dat hij werkt voor de eerste 50.000. Het 50.000-klanten probleem kan opgelost worden met rewrites, refactors en infrastructuur-wijzigingen zodra het product het recht verdient; het 50-klanten probleem kan met niets anders opgelost worden dan met een werkende v1.
- Kan versie één handmatig werk bevatten?
- Absoluut. Handmatige operaties zijn een van de snelste manieren om te leren wat een product werkelijk nodig heeft. Het concierge-patroon, Wizard-of-Oz-interfaces en spreadsheet-gedreven workflows laten allemaal een v1 shippen voor de automatisering arriveert, en de handmatige ervaring leert het team wat eerst geautomatiseerd moet worden. Handmatig is geen shortcut; het is een leer-instrument.
- Wanneer begint versie twee?
- Wanneer v1 helder klantsignaal heeft geproduceerd, retentie, herhaald gebruik, bereidheid om te betalen, of specifieke feature-verzoeken geworteld in echte workflows. V2 moet ontworpen worden tegen dat signaal, niet tegen de v1-backlog van geschrapte features. Veel features op de originele 'v2-lijst' blijken niet te tellen zodra echte klanten het product gebruiken. Laat bewijs v2 vormen; beslis hem niet vooruit.