De lean startup is een nieuwe methode voor het ontwikkelen van innovatieve diensten en producten. Een experiment met deze methode leerde de Universiteitsbibliotheek Utrecht dat goede ideeën staan of vallen bij de uitwerking ervan. En dat de bibliotheek hierbij weleens in een valkuil is gestapt. Johan Tilstra doet verslag van de toepassing van deze methode en de lessons learned.
Door: Johan Tilstra
Denkt u bij het horen van de term ‘startup’ aan een universiteitsbibliotheek? Vast niet. Of in elk geval niet meteen. De term roept vooral een beeld op van ‘hipsters’ die de nieuwe Steve Jobs of Mark Zuckerberg willen worden.
Toch heeft een startup wel degelijk een plek in universiteitsbibliotheken: om relevant te blijven voor gebruikers kunnen de bibliotheken het zich niet veroorloven om níet te innoveren. Daarbij komt het groeiende besef dat succesvol innoveren niet vanzelfsprekend is, en ad hoc aan de slag gaan ook niet de beste methode. Het succes van een goed idee staat of valt juist bij de systematische uitwerking ervan. En waar anders dan in de wereld van startups vind je hier de beste methodes en technieken voor?
De term ‘lean startup’ komt uit het boek The Lean Startup (2011) van Eric Ries. Deze auteur, blogger en ondernemer in Silicon Valley analyseerde een groot aantal startups, van uiterst succesvol tot jammerlijk mislukt. In zijn boek bespreekt hij een aantal vaste kenmerken die succesvolle startups met elkaar gemeen hebben.
Ook toont hij aan dat het idee van de geniale uitvinder die met een soort bovenmenselijke intuïtie weet aan te voelen waar ‘de markt’ op zit te wachten, een mythe is. Het tegendeel is waar: veel succesvolle ondernemingen blijken een geschiedenis te hebben van heel veel uitproberen, daarvan leren en – op basis van die geleerde lessen – steeds tijdig het roer omgooien.
Vijf principes
Uit de succesfactoren destilleert Eric Ries een vijftal principes voor succesvolle startups. De nadruk op leren en zo nodig bijstellen komt terug in het eerste principe, ‘validated learning’. Daaronder schaart hij het idee dat het primaire doel van startups is zo snel mogelijk ontdekken of er bij een initieel idee een valide bedrijfsmodel te vinden is en, zo ja, te leren welk model dan precies. Dat leren, benadrukt Ries, moet zo objectief en gericht mogelijk gebeuren: leren doe je door hypotheses op te stellen en die, via toetsing aan gebruikers, al dan niet te valideren.
Dat leerproces wordt ondersteund door ‘innovation accounting’ (het tweede principe): hoe kun je zeker weten dat je vooruitgang boekt? Ga je uit van een gevoel van verbetering, of kun je cijfermatig aantonen dat je de goede kant opgaat? Hiervoor zul je een administratie bij moeten houden. Om ‘validated learning’ mogelijk te maken doorloop je in de lean startup de zogeheten ‘build-measure-learn’-cyclus (het derde principe). In een continu herhaald proces formuleren lean startup-ondernemers hypothesen over verbeteringen van hun product, werken die uit, meten het effect op gebruikers en leren vervolgens van de resultaten. Uit het geleerde volgen nieuwe ideeën voor verbeteringen, waarna de cyclus weer van voren af aan begint.
In dit derde principe is de link met de oorspronkelijke ‘lean’-gedachte het meest zichtbaar. Stel alles in het werk om deze cyclus steeds zo snel mogelijk te doorlopen, benadrukt Ries, en weersta de (zeer menselijke) neiging om tijd te besteden aan zaken die niet direct bijdragen aan het leerproces.
Het mag duidelijk zijn dat een lean startup het tegendeel is van ongericht, ad hoc innoveren. Voor Ries is een startup een organisatievorm als alle andere, maar wel een met de focus op het ontdekken van valide bedrijfsmodellen. ‘Entrepreneurship is management’ stelt Ries daarom in het vierde principe, en hoe gestructureerder je hierbij te werk gaat, hoe groter de kans op succes. Met het vijfde principe, ‘entrepreneurs are everywhere’, betoogt Ries tenslotte dat ondernemers overal te vinden zijn. Niet alleen in de spreekwoordelijke garagebox van Steve Jobs en Steve Wozniak, maar ook binnen grotere organisaties. En dus ook in universiteitsbibliotheken.
Bibliotheekproject
In 2013 kreeg de Universiteitsbibliotheek Utrecht de lean startup in het vizier. Dat jaar had zij een groot project afgerond, waarbij onder andere de mobiele website van de bibliotheek (m.library.uu.nl) was vernieuwd. De gebruikersstatistieken toonden na enige tijd aan dat er een grote spreiding was in de populariteit van de verschillende mobiele site-onderdelen. Dit leidde tot de onvermijdelijke conclusie dat een deel van alle tijd en moeite is gespendeerd aan functionaliteiten waar bezoekers simpelweg niet op zaten te wachten.
Ook kwam een ander punt aan het licht: wil je functionaliteiten ontwikkelen die precies aansluiten op de gebruikerswensen, dan is enkel netjes projectmatig werken niet voldoende. Een systematische aanpak om de zin (of onzin) van ogenschijnlijk goede ideeën te kunnen bepalen, leek dus een nuttig instrument in de ontwikkelaars-‘toolbox’. Besloten werd te onderzoeken hoe de lean startup zinvol zou kunnen worden toegepast binnen de setting van een universitaire bibliotheek.
Een nieuw project kreeg als einddoel het uitproberen van de methode. Als casus werd gekozen voor het radicaal vernieuwen van een bestaande applicatie, namelijk de overzichtspagina van alle door de bibliotheek aangeboden databases, met vooral academische literatuur. Die applicatie bood een goede gelegenheid om een aantal nieuwe ideeën uit te proberen. Het al dan niet opleveren van een nieuwe (of beter gezegd: vernieuwde) applicatie stond in dit project op de tweede plaats.
Dit onderscheid in prioriteiten maakte het makkelijker voor het projectteam (én de organisatie daaromheen) om zich te richten op dat ene einddoel – en zich niet te laten afleiden door fraaie technische mogelijkheden of door diepgaande inhoudelijke discussies over academische databases.
Theoretische aspecten
De lean startup-principes komen erop neer dat je zo snel en efficiënt mogelijk (zo ‘lean’ mogelijk) probeert te achterhalen of een initieel idee voor een nieuwe dienst of product hout snijdt. Je haalt het leermoment – dat in Utrecht pas enkele maanden na lancering van de mobiele website plaatsvond – zoveel mogelijk naar voren. Schuif je eigen overtuiging dat je idee fantastisch is opzij en begin, aldus het advies van Ries, met bedenken wat de meest simpele, snelle en goedkope vorm is om de geldigheid van je idee te controleren.
Maak een prototype, of liever nog een ‘mock up’, of nee, nog beter: begin met simpelweg polsen bij je gebruikers of zij net zo enthousiast zijn over jouw idee als jijzelf. Besteed ook pas tijd aan het uittekenen van ‘mock ups’ als je bevestigd hebt gekregen dat je met je idee een bestaand probleem voor gebruikers weet op te lossen. En laat dat eerste prototype ook pas ontwikkelen als de ‘mock ups’ je genoeg hebben geleerd over hoe dat eerste prototype eruit zou moeten zien.
Vaak genoeg, zo stelt Ries, blijkt dat een initieel idee bijgesteld moet worden. Omgekeerd: wanneer je aan de slag gaat met de uitwerking van een eerste idee, puur op basis van je eigen overtuiging, dan is de kans groot dat pas laat – vaak té laat – blijkt dat je toch niet volledig juist zat.
Aan de slag
Theoretisch goed voorbereid begon het Utrechtse projectteam met het exploratief interviewen van bibliotheekgebruikers, om te achterhalen of de ideeën voor een nieuwe interface voor de academische databases aansluiten bij hoe mensen dat overzicht in de praktijk gebruiken. Deze eerste stap leek de geldigheid van die ideeën te bevestigen: veel gebruikers gaven aan dat ze een opknapbeurt wel zagen zitten.
Na die bemoedigende signalen werden er mock ups gemaakt, die weer aan diverse gebruikers werden voorgelegd. De gesprekken over de mock ups gaven het team inhoudelijke informatie over hoe een eerste functionerend prototype eruit zou moeten zien. Ook gaven die gesprekken inzicht in hoe lastig het is om te bepalen welke wensen gebruikers hebben. Praten óver een applicatie, ook al is het aan de hand van uitgewerkte schetsen, is heel anders dan zien hoe een applicatie daadwerkelijk wordt gebruikt.
Om deze reden én omdat er bij de gebruikersgroep een wens voor een geüpdate applicatie leek te bestaan, werd besloten een prototype van een vernieuwde interface te ontwikkelen. Dat prototype werd naast de bestaande applicatie aangeboden, zodat de zogenaamde ‘early adopters’ die nieuwe applicatie ook al in de praktijk konden gebruiken. Met behulp van Google Analytics kon vervolgens het werkelijke gebruikersgedrag worden gemonitord.
Met een functionerend prototype, de mogelijkheid om het gebruikersgedrag te monitoren en een lijst met nog uit te proberen ideeën leek de route naar succes er een van simpelweg uitproberen en bijschaven. Maar de praktijk bleek weerbarstig.
Eureka-moment
Bij het projectteam leefde de hoop (en de verwachting) dat met elk verder uitgewerkt prototype het aantal ‘early adopters’ zou toenemen. De statistieken lieten een ander beeld zien: het aantal gebruikers nam nauwelijks toe. Steeds moest geconcludeerd worden dat een doorgevoerde aanpassing geen duidelijke verandering in de statistieken gaf.
Het was tijd voor reflectie: klopte de methode niet? Was de toepassing ervan in een universitaire setting een brug te ver? Werd de methode niet goed toegepast?
Na een analyse bleek juist dat de methode precies raak was. Het probleem was dat het projectteam te zeer overtuigd was geraakt van de eigen ideeën over de nieuwe interface. Wat bleek: met het overzicht van academische databases beantwoordt de universiteitsbibliotheek een vraag die gebruikers als zodanig nauwelijks stellen. Het overzicht is namelijk een antwoord op de vraag: welke databases biedt de bibliotheek mij allemaal? Vanuit het perspectief van een universiteitsbibliotheek lijkt het ongehoord dat deze vraag niet leeft bij de gebruikers, maar bij navraag bij gebruikers bleek deze conclusie te kloppen: ja, gebruikers zijn nauwelijks geïnteresseerd in deze vorm van overzicht.
Achteraf gezien verklaart dit de vlakke statistieken: er is een beperkte vraag naar een overzicht van aangeboden academische databases – en dus ook een beperkte vraag naar een mooiere interface voor die gegevens. De feedback van de gebruikers voor een nieuwe interface was oprecht positief, maar het team leidde daar een werkelijk bestaande gebruikersbehoefte uit af. Onterecht, zo bleek naderhand.
Gefaald?
Heeft het experiment gefaald? Nee, juist niet. Door de lean startup-principes toe te passen heeft de universiteitsbibliotheek vroegtijdig ontdekt dat het geen zin zou hebben gehad om veel tijd en middelen te steken in een vernieuwde interface. Zonder de gekozen aanpak zou de bibliotheek deze les pas hebben geleerd ná de ontwikkeling van een volledig uitgewerkte interface.
Bovendien zijn er talloze grote en kleine inzichten opgedaan, zowel over de methode als over zaken waar gebruikers wél behoefte aan hebben. Die inzichten zullen worden meegenomen in de ontwikkeling van nieuwe diensten en producten. Die zullen, waar maar even mogelijk, ook als lean startups worden uitgevoerd.
Lessons learned
Het project bij de Universiteitsbibliotheek Utrecht heeft verschillende ‘lessons learned’ opgeleverd. Bijvoorbeeld dat bibliotheekgebruikers uiterst behulpzame gebruikers zijn. Of dat het lastig is om kort en bondig uit te leggen waar de lean startup precies om draait. Maar de belangrijkste geleerde lessen komen hierop neer: innovatie is erg gebaat bij een systematische aanpak, en tegelijkertijd voelt zo’n gestructureerde aanpak soms erg tegen-intuïtief. Toch is de kans op een mislukking groot als je vooral op je gevoel afgaat: je raakt overtuigd van je eigen goede idee en krijgt (ironisch genoeg mede door je eigen enthousiasme) vooral bevestigende signalen. Vol goede moed ga je aan de slag – niet met toetsen, maar met implementeren. En pas veel later, als je idee toch niet helemaal raak bleek te zijn, leer je wat je had moeten doen. De lean startup behoedt je voor zulke valkuilen.
Veelgehoorde reacties
Noodzakelijkerwijs bestaat een flink deel van innovatieve projecten uit communiceren over ‘wat je nu eigenlijk allemaal aan het doen bent’. In de loop van de tijd viel daarbij op dat in het lean startup-project van de Universiteit Utrecht een aantal reacties vaker terugkwam.
1 ‘Wat je beschrijft is gewoon hetzelfde als agile software ontwikkelen.’
De lean startup en agile software ontwikkelen hebben veel overeenkomsten, met name als het gaat om de iteratieve aanpak in de ‘build, measure, learn’-cyclus. Wel hebben ze elk een heel andere focus: de lean startup is gericht op het vinden van een valide bedrijfsmodel en ook goed toepasbaar voor innovaties waar helemaal geen softwareontwikkeling aan te pas komt. In trajecten waar dat wel gebeurt, kunnen beide methodes goed worden gecombineerd.
2 ‘Maar er is toch niks nieuws aan deze aanpak?
Dit zijn allemaal open deuren!’ De lean startup-aanpak is in essentie niet meer dan een slimme combinatie van bestaande concepten en methoden, die afzonderlijk allemaal erg logisch klinken. Toch zie je, om je heen kijkend, maar weinig innovatieprojecten die als uitgangspunt hebben dat een (ogenschijnlijk) goed idee gedegen getoetst moet worden. Integendeel: uit enthousiasme en overtuiging wordt vaak direct de sprong van idee naar implementatie gemaakt. Dat laat zien dat de lean startup-aanpak niet zo voor de hand ligt.
3 ‘Wat je beschrijft – dat doen wij allemaal al.’
In veel innovatietrajecten zie je afzonderlijke stappen uit de lean startup terug – vandaar dat een andere veelgehoorde reactie is dat het allemaal open deuren zijn. Spreken we over de scherpe focus op toetsing van ideeën, het zoeken naar een valide businessmodel en het leren over gebruikers, dan zegt bijna nooit iemand: ‘Dat doen wij allemaal al’.
Bedenker lean startup-methodiek komt naar Nederland
Vier ‘fans’ hebben er via een crowdfundingcampagne voor gezorgd dat Eric Ries, bedenker van de lean startup-methodiek, op 3 maart naar Nederland komt. Tijdens deze mini-conferentie geeft Ries een keynote; ook zullen er cases worden behandeld en vinden debatten plaats. Meer informatie is te vinden op tinyurl.com/mwoydoz.
Johan Tilstra is gecertificeerd project- en programmamanager bij de afdeling Innovatie & Ontwikkeling van de Universiteitsbibliotheek Utrecht. Hij was projectmanager van het in dit artikel genoemde project.
Deze bijdrage komt uit IP nr. 1 / 2015. Het gehele nummer kun je hier lezen