Productontwikkeling / 03
Een MVP heeft een eerste klant nodig, geen korter wensenlijstje.
Er staan veertig functies in de spreadsheet. Terug naar twintig voelt als vooruitgang. Maar waarom zou iemand het product morgen openen? Begin bij de taak van de eerste klant en het resultaat waarvoor die terugkomt.
Beschrijf één transactie
Een denkbeeldig boekingsproduct: de klant vindt een tijd, reserveert, betaalt en ontvangt bevestiging; de aanbieder ziet een betrouwbare afspraak. Die zin vertelt meer dan dashboard, AI, betalingen en meldingen.
Welk signaal toetst het idee? Een eerste afgeronde boeking, een tweede betaald bezoek of een aanbieder die wil blijven? Kies iets dicht bij het probleem. Alleen registraties tellen kan daar weinig over zeggen.
Hypothese
Wie betaalt en welke taak moet worden afgerond?
Traject
Eén route van verzoek naar behaald resultaat.
Pilot
Echte gebruikers; fouten en handmatige hulp blijven zichtbaar.
Besluit
Doorgaan, aanpassen of stoppen op basis van gegevens.
Dit is een voorbeeld voor een boekingsdienst. Verander bij een ander product eerst de hypothese en daarna de functielijst.
Bepaal welke onzekerheid de eerste versie moet wegnemen
Een prototype, een pilot en een MVP beantwoorden verschillende vragen. Een klikbaar prototype kan laten zien of mensen de navigatie begrijpen. Een begeleide pilot kan duidelijk maken of een dienst praktisch uitvoerbaar is. Een MVP moet iemand een afgebakende waarde laten ervaren en het team informatie geven voor de volgende beslissing. Die vormen kunnen op elkaar volgen, maar hoeven niet allemaal dezelfde functies of dezelfde technische basis te hebben.
Schrijf daarom vóór het ontwerpen op wat nog onzeker is. Is het probleem belangrijk genoeg? Begrijpt iemand het aanbod? Wil een organisatie toegang geven tot de benodigde gegevens? Kan het team de beloofde uitkomst leveren? Een mooi dashboard beantwoordt die vragen niet vanzelf. Kies een eerste versie die het meest risicovolle deel zichtbaar maakt. Zo voorkom je dat de ontwikkeling vooral de onderdelen verfijnt die al begrepen waren, terwijl de belangrijkste aanname buiten beeld blijft.
Teken de volledige route van één gebruiker
Een lijst met functies maakt het moeilijk om te zien of een product werkelijk bruikbaar is. Beschrijf liever één concrete route: iemand ontvangt een uitnodiging, voert gegevens in, krijgt een resultaat en weet wat de volgende stap is. Noteer bij iedere stap wat de gebruiker verwacht en welk systeem die verwachting waarmaakt. Neem ook een mislukte of afgebroken poging mee, want daar ontstaat vaak het meeste herstelwerk.
Bij producten voor meerdere partijen moet de route aan beide kanten kloppen. Een klant kan bijvoorbeeld een aanvraag plaatsen, maar zonder een werkende ontvangst- en afhandelroute voor de leverancier ontstaat er nog geen dienst. Bouw daarom niet automatisch eerst alle schermen voor één rol. Zoek de kleinste keten waarin beide partijen hun noodzakelijke stap kunnen uitvoeren. Die keten kan er bescheiden uitzien en toch veel meer leren dan een uitgebreide interface zonder afgeronde uitkomst.
Maak handmatig werk zichtbaar en meetbaar
Een eerste versie mag stappen bevatten die het team achter de schermen uitvoert. Handmatig een rapport controleren of een aanvraag koppelen kan helpen om vroeg te leren welke variaties voorkomen. Het wordt problematisch wanneer niemand weet hoeveel tijd dit kost of wanneer gebruikers een onmiddellijke uitkomst verwachten terwijl een medewerker nog moet beginnen. De inrichting moet aansluiten op wat het team daadwerkelijk kan waarmaken.
Leg daarom vast welke handelingen handmatig blijven, wie ze uitvoert en hoe de voortgang wordt bijgehouden. Gebruik die informatie om te bepalen welke automatisering later zinvol is. Als iedere aanvraag een ander soort beoordeling vraagt, ligt het probleem misschien in de afbakening van het aanbod. Meer code lost dat niet vanzelf op. Een goede pilot maakt zulke verschillen zichtbaar voordat de werkwijze in een duur systeem wordt vastgelegd.
Scroll opzij om alle kolommen te zien.
| Functie | Keuze voor de pilot | Acceptatiecriterium |
|---|---|---|
| Tijd kiezen en boeken | Bouw het volledige traject | Twee gebruikers kunnen niet hetzelfde tijdslot boeken |
| Ongebruikelijke wijzigingen | Laat een beheerder deze handmatig verwerken | Het verzoek heeft een eigenaar en zichtbare status |
| Betaling, als die nodig is om de vraag te testen | Bevestig de betaling op de server | Een herhaald bericht maakt geen tweede aankoop aan |
| Beloningen en doorverwijzingen | Wacht tot de kernvraag is getoetst | Gegevens verbinden de functie met herhaalaankopen |
Kies web of mobiel op basis van de gebruikssituatie
Een mobiele app is niet automatisch de logische eerste stap omdat klanten hun telefoon gebruiken. Een webapp kan voor veel vroege experimenten voldoende zijn, zeker wanneer de route vooral bestaat uit informatie invoeren, resultaten bekijken en een afspraak maken. Onderzoek welke handeling echt afhankelijk is van mogelijkheden zoals achtergrondtaken, intensief cameragebruik of diepere aansluiting op het toestel. Maak die behoefte concreet voordat er twee platformen worden gebouwd.
Test een risicovolle technische functie afzonderlijk als zij essentieel is. Een klein werkend experiment met de camera of een apparaatkoppeling kan meer duidelijkheid geven dan een volledige visuele demo. Houd daarnaast rekening met distributie, updates, ondersteuning en de omstandigheden waarin gebruikers werken. Een verkoopmedewerker onderweg heeft andere beperkingen dan een beheerder achter een groot scherm. De platformkeuze moet die praktijk ondersteunen, niet alleen passen bij het beeld dat het team van een modern product heeft.
Onderzoek integraties voordat je de planning vastlegt
Een MVP kan klein ogen en toch sterk afhankelijk zijn van een extern systeem. Denk aan een agenda, een boekhoudpakket of gegevens die bij een zakelijke klant staan. Controleer vroeg of een testomgeving beschikbaar is, welke rechten nodig zijn en welke velden werkelijk kunnen worden gelezen of gewijzigd. Een document met API-mogelijkheden is een begin; een geslaagde proef met representatieve gegevens geeft veel meer zekerheid over de uitvoerbaarheid.
Bepaal ook welk systeem de bron is voor belangrijke toestanden. Een scherm kan bijvoorbeeld betaald tonen, maar die status moet terug te voeren zijn op een betrouwbare bevestiging van de betaalprovider. Bewaar stabiele identificaties tussen systemen en beschrijf wat er gebeurt bij vertraging. Zonder deze afspraken ontstaan er snel twee versies van dezelfde werkelijkheid. Dat levert niet alleen technische fouten op, maar ook verwarring voor de mensen die klanten moeten helpen.
Test toegang met twee gewone accounts
Een beheerdersaccount is handig tijdens de bouw, maar verbergt gemakkelijk fouten in toegangsrechten. Maak minimaal twee gewone testaccounts met gescheiden gegevens. Controleer of gebruiker A de gegevens van gebruiker B kan vinden door een adres, recordnummer of verzoek aan te passen. De interface verbergen is onvoldoende wanneer de server het opgevraagde record alsnog teruggeeft. Toegang moet worden gecontroleerd op het moment dat gegevens worden gelezen of gewijzigd.
Denk ook aan uitnodigingen, herstel van toegang en het vertrek van een teamlid. Een eerste versie hoeft niet ieder complex rollenmodel te ondersteunen, maar de gekozen grenzen moeten consequent zijn. Beschrijf welke rollen bestaan en welke handelingen daarbij horen. Gebruik die beschrijving als acceptatiecriterium bij oplevering. Daarmee wordt beveiliging een toetsbaar onderdeel van het product, in plaats van een algemeen punt dat pas vlak voor de lancering ter sprake komt.
Ontwerp betalingen rond gebeurtenissen op de server
Een gebruiker die terugkeert naar een bedankpagina is niet het enige betrouwbare signaal dat een betaling is afgerond. De browser kan worden gesloten, een verbinding kan wegvallen en een bevestiging kan later aankomen. Gebruik daarom de daarvoor bedoelde servermeldingen van de betaalprovider en controleer hun authenticiteit. Koppel de betaling aan de juiste bestelling of het juiste account voordat toegang wordt verleend of een vervolgactie start.
Zorg dat dezelfde melding meer dan één keer kan worden ontvangen zonder dubbele gevolgen. Test ook een vertraagde bevestiging, een afgebroken betaling en een situatie waarin de betaling wel lukt maar het product tijdelijk niet bereikbaar is. Beschrijf wat de klant dan ziet en hoe het team de situatie herstelt. Een eenvoudige betaalroute is pas eenvoudig voor de gebruiker wanneer deze onregelmatige gebeurtenissen achter de schermen goed worden afgehandeld.
Voeg AI alleen toe als de kernuitkomst er beter van wordt
Een AI-functie kan waardevol zijn wanneer zij een lastig onderdeel van de taak ondersteunt: documenten ordenen, informatie samenvatten of een eerste voorstel maken. Benoem dan precies welke verbetering wordt verwacht en hoe die wordt beoordeeld. Een tekst die professioneel klinkt is geen bruikbaar kwaliteitscriterium wanneer de gebruiker vooral correcte gegevens nodig heeft. Verzamel voorbeelden met een gewenste uitkomst en met situaties waarin het systeem moet aangeven dat het onvoldoende weet.
Maak daarnaast een route voor fouten en twijfel. Kan een gebruiker het resultaat aanpassen, de bron controleren of hulp vragen? Mag het model alleen informatie voorstellen of ook wijzigingen uitvoeren? Houd die bevoegdheden gescheiden en beperk de gegevens die nodig zijn voor de taak. Een MVP met AI heeft dezelfde operationele vragen als ieder ander product, plus de noodzaak om variërende antwoorden te beoordelen. Dat hoort in de eerste scope wanneer AI de kern van het aanbod vormt.
Vergelijk offertes met dezelfde acceptatiesituatie
Twee offertes zijn moeilijk te vergelijken als de ene partij alleen schermen begroot en de andere ook foutafhandeling, beheer en overdracht meeneemt. Geef beide partijen dezelfde concrete gebruikersroute en vraag wat er inbegrepen is. Bijvoorbeeld: een nieuwe klant meldt zich aan, betaalt, krijgt toegang en kan na een mislukte poging verdergaan. Vraag ook wie de omgeving beheert en hoe een probleem na oplevering wordt onderzocht.
Laat aannames en uitsluitingen expliciet opschrijven. Een lagere prijs kan passen bij een smallere eerste versie, zolang duidelijk is wat daarmee nog niet wordt getest. Vraag om demonstraties aan de hand van acceptatiecriteria in plaats van alleen voortgang in aantallen schermen. Neem bovendien eigendom van accounts, broncode, domeinen en gegevens mee in de overdracht. Het product moet door de organisatie kunnen worden voortgezet wanneer de samenwerking of de samenstelling van het team verandert.
Meet pogingen, uitkomsten en redenen om te stoppen
Een registratie is een begin van gebruik, geen bewijs dat iemand waarde heeft gekregen. Meet daarom de stappen die nodig zijn voor de gekozen kernuitkomst. Hoeveel mensen begonnen, hoeveel bereikten het resultaat en waar liepen anderen vast? Combineer die aantallen met gesprekken en concrete voorbeelden. Een lage voltooiing kan voortkomen uit een technisch probleem, een onduidelijk aanbod of een taak die minder belangrijk is dan werd aangenomen.
Spreek vooraf af welke bevinding tot welke beslissing leidt. Een kleine pilot kan voldoende zijn om een fout te ontdekken of een route te verbeteren, maar onderbouwt niet automatisch een brede marktvraag. Kijk naar de manier waarop deelnemers zijn gekozen en hoeveel begeleiding zij kregen. Bewaar de oorspronkelijke hypothese naast de resultaten. Zo kan het team na de eerste versie bewust kiezen voor verbeteren, verder onderzoeken of stoppen, in plaats van iedere uitkomst te gebruiken als reden om meer functies te bouwen.
Beperk de breedte, behoud betrouwbaarheid
Eén klanttype, één dienst, één route. Een beheerder kan uitzonderingen handmatig behandelen als het proces duidelijk is. Een doorverwijsprogramma, vijf abonnementen en automatische rapportages kunnen wachten.
Validatie, rechten, betaalstatus en herstel blijven nodig. Probeer via een tweede account een boeking van iemand anders te openen. Ververs tijdens betaling. Verstuur twee keer. Een demo die perfecte klikken vereist, is geen stevige proef met echte klanten.
Een mobiele app heeft een reden nodig
Een responsive webapp kan genoeg zijn wanneer de hoofdtaak via een link begint. iOS en Android verdienen een plek als apparaatfuncties of herhaald gebruik de ervaring veranderen. Schrijf die behoeften eerst op.
Hetzelfde geldt voor AI. Bij een eenvoudige boeking kan de assistent later komen. Is documentbegrip de kern van het product, dan hoort het beoordelen van antwoorden bij de eerste versie.
Neem de overdracht op in de opdracht
Spreek af wie domein, repository, hosting en betaalaccount beheert. Zorg voor export, back-ups en een route om fouten te melden. Op maandag na de lancering moet iemand het product kunnen beheren.
Beschrijf de eerste versie als een korte acceptatietest met zichtbare resultaten. Zet latere ideeën apart. Klanten laten vervolgens zien wat het uitbreiden waard is.
Voor je begint
- Benoem de eerste klant en diens volledige taak.
- Test rechten, onderbroken betalingen en dubbele verzending.
- Spreek toegang tot code, accounts en beheerdocumentatie af.
Redactionele toelichting. Voorbeelden verduidelijken een keuze of test; het zijn geen klantresultaten.