Lean startup: begin met het ‘minimum viable product’

Geen reacties
Tags: , , , , , , , , , ,
Posted 31 jan 2014 in nieuws

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 tot je een idee hebt van wat er allemaal in moet komen en hoe je het gaat bouwen. Maar stel dat je vol goede moed aan de slag gaat en 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, veel ontwerpkeuzes, die vaak moeilijk omkeerbaar zijn, zijn al gemaakt en het product beschikt over een rijke keur aan niet altijd optimaal werkende functies. 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 lean – en dus efficiënt en snel – ondernemen, dan moet het product zich in de praktijk bewijzen. Tot die tijd weet je niets, nada, noppes. 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. Bijvoorbeeld: ‘ik denk dat er behoefte is aan …’. En die hypothese vervolgens te toetsen in 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. 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 single-page website. In drie zinnen wordt het product beschreven en geïnteresseerden kunnen zich aanmelden voor de closed beta. 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 community creëren van loyale testers en supporters. 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 je weer moet bedenken dat elke aanname omtrent functionaliteit 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 met een compleet product succes oogsten, en schaamt hij zich dus een beetje voor een uitgeklede eerste versie. Niet voor niets is de meest gehoorde uitspraak van product developers: ‘de volgende versie kan ook dit of dat…’.
Maar Reid Hoffman, founder 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 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, tag-woorden voorzien van een ‘#’. Hashtags zijn niet bedacht door Twitter, maar door inventieve gebruikers. Nu hadden de twitter-developers ervoor kunnen kiezen om hier een tagwoorden systeem voor te bouwen, of misschien het aantal karakters per tweet te vergroten. 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, die vervolgens voor slechte pers zorgen als je je product gaat versoberen. 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’ mee. 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 business-to-business 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: build, measure, learn. Doe een aanname over 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’.



Lees het volledige bericht op Emerce »


Add Your Comment