Wat hoort in een eerste versie, en wat kan wachten?

Een lijst met functies groeit vanzelf. Telkens je over je idee praat, komt er iets bij: een klantenkaart, een chat, een overzicht met cijfers. Een eerste versie bevat veel minder dan die lijst, namelijk wat iemand nodig heeft om de belangrijkste taak van begin tot einde uit te voeren.

Begin bij de belangrijkste taak

Stel dat je een app wil voor een kapsalon, waarmee klanten zelf een afspraak maken. De belangrijkste taak past dan in één zin: een klant boekt een afspraak, en het salon weet ervan. Lukt het niet om zo’n zin te schrijven, dan is het idee nog te breed voor een eerste versie, en daar kom je beter nu achter dan tijdens het bouwen.

Overloop daarna de stappen zoals een gebruiker ze zet:

1. De klant opent de app en kiest een behandeling.
2. De app toont welke momenten vrij zijn, en de klant kiest er een.
3. De klant vult een naam en een telefoonnummer in en bevestigt.
4. Het salon ziet de afspraak verschijnen in zijn agenda.
5. De klant kan niet komen en annuleert.

Dat is de eerste versie. Een klantenkaart, reviews, shampoo verkopen en een overzicht van de drukste dagen zitten er niet tussen, hoe goed die ideeën ook zijn.

Wat er ongevraagd bij hoort

Een stappenlijst beschrijft wat er gebeurt als alles goed loopt. Stel er daarna de vraag bij wat er gebeurt als dat niet zo is. Wat ziet een klant als iemand anders dat moment net geboekt heeft? Wat als het salon sluit voor vakantie? Wat als iemand zich vergist in het telefoonnummer?

Op een wensenlijst vergeet je die antwoorden makkelijk, en toch horen ze bij een eerste versie, want klanten lopen er meteen tegenaan. Hetzelfde geldt voor de praktische kant: moeten mensen inloggen, dan moeten ze hun wachtwoord kunnen herstellen, en bewaar je gegevens van klanten, dan hoort daar een privacyverklaring bij.

Hoe je beslist wat wacht

Twee vragen brengen je een heel eind. Kan de belangrijkste taak zonder deze functie? Kan iemand het voorlopig manueel doen?

Herinneringen zijn een goed voorbeeld. Ze zijn nuttig, maar de kapper kan de dag ervoor ook zelf een berichtje sturen. Een overzicht van de drukste dagen kan je een tijdje uit de agenda halen of in Excel bijhouden. Dat manuele werk vertelt je ook iets. Je ziet hoe vaak het echt nodig is en wat er precies in moet, en als het te veel tijd begint te vragen, heb je meteen een goede reden om het te laten bouwen.

Elke functie die wacht, is ook werk dat je nu niet betaalt.

Sommige dingen bespreek je wel vooraf, ook als ze nu nog niet gebouwd worden. Komt er later een tweede vestiging of een tweede taal, dan kan degene die bouwt daar in de opbouw van de gegevens al rekening mee houden. Hetzelfde geldt voor werken zonder bereik, want dat bepaalt hoe een app haar gegevens bewaart en doorstuurt. Zulke dingen achteraf toevoegen, vraagt meer werk dan ze vooraf inplannen.

Een functie die niet bij het product past

Een functie kan nuttig klinken en toch niet in je product horen. Voor mij moet ze altijd bij het product passen.

Felix, mijn eigen product, helpt boetieks om goede klanten terug te laten komen met persoonlijke berichten. In een gesprek vroeg iemand om een nieuwsbrieffunctie, en ik zei nee: Felix moet geen nieuwsbrief worden. Bulkberichten zitten er wel in. Daarmee stuur je een specifiek bericht naar een gekozen groep, terwijl een nieuwsbrief een algemeen bericht aan iedereen is.

Dat voorbeeld kan je gebruiken bij je eigen lijst. Schrijf in één zin wat je product doet en voor wie. Past een functie niet in die zin, ga dan na welke behoefte achter de vraag zit. Soms kan wat er al is die behoefte opvangen, of volstaat een kleine aanpassing. Shampoo verkopen kan een prima plan zijn voor het kapsalon, en het hoort niet bij een app om afspraken te maken.

Wat je doet met alles wat wacht

Hou het bij. De volgorde waarin dingen gebouwd worden, heet een roadmap: wat eerst komt, wat daarna en wat later kan. Zolang een idee daarop staat, is het makkelijker om het vandaag te laten liggen.

Die volgorde hoeft niet vast te staan. Bij Felix kwamen bulkberichten en spraaknotities uit verkoopgesprekken, nog voor de eerste pilot. Zodra echte mensen jouw eerste versie gebruiken, heb je nog meer om op af te gaan. Wat ze meermaals vragen, schuift op naar boven, en wat niemand mist, kan van de lijst.

Twijfel je of de belangrijkste taak wel de juiste is, dan kan je dat testen voor er iets gebouwd wordt. Dat lees je in Test je idee voor je het bouwt.