Lean startup: begin met het minimaal werkbare product

Als aspirant ondernemer met een geweldig idee voor een softwareproduct weet je wat je moet doen: bouw een eerste versie van het product. Om tot die eerste versie te komen ga je dan met wat vrienden, zakenrelaties of adviseurs zitten brainstormen. Maar stel dat je er vervolgens achter komt dat dit toch niet helemaal het product was waar je doelgroep op zat te wachten?

Dit soort situaties kom ik in de praktijk vaak tegen. Er is al een product, en veel ontwerpkeuzes, die vaak moeilijk omkeerbaar zijn, zijn al gemaakt. Tegelijkertijd valt het aantal gebruikers vaak nog tegen. Allemaal verloren moeite en tijd, gestoken in ongewenste functionaliteit. Waste! Maar hoe voorkom je deze situatie?

Het minimale product
Vanuit de Lean Startup-school is op deze vraag een interessant, drieletterig antwoord geformuleerd: het MVP. MVP staat voor Minimum Viable Product. Ofwel: het minimaal werkbare product. Het allerkleinste, meest minimale, snelst te creëren product dat – en daar gaat het om – je meest urgente vraag beantwoordt: Waar heeft je klant behoefte aan?

Wil je efficiënt en snel ondernemen, dan moet het product zich in de praktijk bewijzen. Hoe komt het product eruit te zien? Geen idee. Is er een markt voor? Joost mag het weten. Het enige wat je kunt doen is het formuleren van een hypothese en die toetsen aan de praktijk.

Afhankelijk van je product zijn er veel MVP-strategieën mogelijk. Groupon begon dagelijkse deals aan te bieden via een WordPress-site die in één middag in elkaar was gezet. Voor de rest bevatte de site geen enkel stukje techniek. Om te bestellen moest de klant een mailtje sturen. De coupons werden in FileMaker met de hand gemaakt. De virtuele opslagplaats Dropbox begon niet eens aan een product  (de technologie was te complex voor een simpele MVP), maar stuurde een YouTube video de wereld in.

Fake it, don’t make it
Een veelgebruikte aanpak is het maken van een simpele website. In drie zinnen wordt het product beschreven en geïnteresseerden kunnen zich aanmelden voor een gesloten proef. Intussen wordt er getwitterd en geblogd over het (nog niet bestaande) product en worden er af en toe schermontwerpen getoond. Door de tekst op de minisite te variëren kun je al wat leren over de behoefte van de gebruiker. En met het e-mailbestand dat je zo opbouwt kun je een gemeenschap creëren van loyale testers. Er wordt wel eens gezegd: Fake it, don’t make it’. Of op z’n Oudhollands: ‘Bezint eer ge begint’.

De volgende stap is dan de bouw van een eerste functionele versie, waarbij elke voorgenomen functionaliteit als het ware een hypothese is die getoetst moet worden. Hoe kleiner en simpeler deze versie is, hoe beter.

Dit is vaak een moeilijk punt voor de ondernemer. Het liefst zou hij de wereld willen laten zien wat voor moois hij heeft bedacht, en schaamt hij zich dus een beetje voor een uitgeklede eerste versie. Maar Reid Hoffman, oprichter van LinkedIn, zei ooit: “If you are not embarrassed by the first version of your product, you’ve launched too late.”

Keep it simple
Door simpele producten te lanceren, krijg je beter inzicht in wat de gebruiker er mee wil. En soms zul je verbaasd staan van hoe inventief gebruikers omgaan met een sobere interface. Een bekend voorbeeld is Twitter: deze simpele sms-naar-iedereen site werd snel opgepakt door velen die hun gemoedstoestand met de wereld wilden delen. Al snel ontstond het gebruik van hashtags. Hashtags zijn niet bedacht door Twitter, maar door inventieve gebruikers. Nu hadden de ontwikkelaars ervoor kunnen kiezen om hiervoor zelf oplossingen te bouwen. Maar door het platform juist heel sober te houden won het aan populariteit. De rest is geschiedenis.

Eric Ries beschrijft in ‘The Lean Startup’ hoe hij in tijdsnood en met pijn in zijn buik, als cheap hack de avatars in zijn virtuele wereld IMVU liet springen van A naar B, in plaats van lopen. De gebruikers vonden het geweldig, want springen was sneller.

Bij het online taleninstituut Myngle kwamen we er achter dat de marktplaatsbenadering, waarbij leerlingen op zoek moesten naar de juiste leraar, niet werkte. De klant wilde aan de hand genomen worden en een docent toegewezen krijgen. En de docenten hadden geen affiniteit met adverteren. Hadden we dit eerder onderzocht middels een simpele MVP, dan had dat veel hoofdbrekens, ontwikkeltijd, marketinggeld en doorlooptijd gescheeld.

Behoedzaam ontwikkelen
Als je eenmaal een verkeerde weg hebt ingeslagen met productontwikkeling, is de weg terug vaak zeer moeizaam. Een eenmaal gekozen databasestructuur laat zich vaak niet zonder kleerscheuren wijzigen. En zelfs de weinig gebruikte functies hebben vaak nog wel enthousiaste gebruikers. Reden te meer om behoedzaam te werk te gaan.

Eén klant die schreeuwt om een bepaalde functionaliteit betekent nog niet dat je hem moet geven wat hij vraagt. Wellicht is hij de enige en gebruikt hij het product voor een a-typisch doel. Kijk en luister goed en ga niet te snel door de knieën. Soms kun je door een API (Application Programming Interface) te ontwikkelen veel druk van je ontwikkelplanning wegnemen. Laat de buitenissige klanten het zelf maar oplossen. En wie weet leer je dan alsnog een geheel nieuwe toepassing van je product, waar wel markt voor bestaat.

Naast het voordeel van het vermijden van onnodige ontwikkeltijd speelt ook de time to market een rol. Met een MVP kun je veel sneller beginnen met het werven van gebruikers en het verdienen van geld. Waarom niet binnen een kwartaal al omzet behalen in plaats van na een jaar van ontwikkelen?

Een ander voordeel van een minimaal product is dat het leidt tot een veel hechtere relatie met je gebruikers. Dit geldt voor zowel consumentenproducten als voor zakelijke applicaties. De klanten die vanaf het begin met je meegroeien, die je persoonlijk te woord staat en die mee mogen denken over de ontwikkeling hechten meer waarde aan persoonlijk contact dan aan een ‘perfect’ product. Zo krijg je de trouwste gebruikers en de meest toegewijde ambassadeurs.

Build, Measure, Learn
Ook het vervolg van je productontwikkeling blijft hetzelfde patroon volgen. In lean startup-termen: bouw, meet en leer. Ga na welke stap je wilt zetten, ontwikkel de nieuwe versie, meet wat er gebeurt (zie ook mijn artikel over meten) en verwerk de resultaten tot weer een nieuwe ‘aanname’. Schroom niet af en toe een stapje terug te zetten.  Om weer Oudhollands af te sluiten: ‘Beter ten halve gekeerd, dan ten hele gedwaald’.