Hoe veranker je continue klantvalidatie in je innovatieproces?

Validated Learning: wat was het ook alweer?

Validated Learning is een kreet die vooral populair geworden is door The Lean Start-up, van Eric Ries. Het beschrijft het proces waarin je je aannames of ideeën vertaalt naar hypotheses, die je vervolgens in een experiment toetst, meestal bij eindgebruikers. Je verwerkt de data, en leert er van. In een schemaatje:

Denk bijvoorbeeld aan aannames over welk van je features klanten straks het meest zullen waarderen. In een experiment met een dummy landingpage kan je vervolgens testen of die aannames kloppen. Zo groei je stapje voor stapje naar je product of service toe, door te weten in welke kant je moet bewegen. Andersom: start-ups die hebben gefaald kunnen bijna allemaal aanwijzen waar Validated Learning hen had kunnen behoeden. ‘Maar we dáchten dat sms-sen met een hoelahoep écht in een behoefte voorzag…’.

Lang vóórdat je een MVP maakt, kan je Validated Learning al gebruiken om te ontdekken of een MVP überhaupt het bouwen waard is. En parallel aan je MVP voor je product, kan je ook allerlei andere zaken testen. Denk maar eens aan je algemene voorwaarden, of — iets sexier — je visual identity. Of je marketing website. Of je prijsstelling. Of je servicedesk. Of, of… Enfin, je snapt ‘m wel. Maar hoe organiseer je dat?

Het begin: creëer duidelijke tracks

De meeste beginnende Corporate start-ups hebben de handen vol aan een heel plethora aan al die verschillende to-do’s. Vaak ontbreekt ook een backlog met alles wat er moet gebeuren. Iedereen werkt gewoon kneiterhard, en zolang we allemaal ons best doen en elkaar helpen zijn we het snelste klaar. Grote kans dat je nog gelijk hebt ook. In het begin.

Maar na verloop van tijd wil je toch meer grip hebben op wat er moet gebeuren, ook omdat het steeds belangrijker wordt dat er niks van de kar valt. Dat is het moment dat het loont om verschillende tracks te maken rond het specifieke product of de dienst die je aan het ontwikkelen bent. Bijvoorbeeld: Product Development, Marketing, Legal, Compliance, Service Desk, Community Building en zo voort. Maar hoe organiseer je die?

Scrum geeft ritme

Een oplossing begint bij Scrum. Even een plaatje om het geheugen wat op te frissen:

Ik ben de laatste om te zeggen dat Scrum een panacee is voor alles en iedereen, maar ik heb gezien dat Scrum heel behulpzaam kan zijn in de ontwikkeling binnen deze tracks.

Je kan Scrum bijvoorbeeld ook op het marketing track toepassen. En op het Legal track. En als je die tracks in tempo met elkaar synchroon laat lopen, dan brengt dat vanzelf ritme. Zoals een basso continuo in muziek, zorgt het voor voorspelbaarheid en houvast op de voortgang. Dat zou dat er bijvoorbeeld zo uit kunnen zien:

Dat synchroon lopen betekent dus in de praktijk ook dat alle tracks in de Sprint Demo hun voortgang kunnen demo-en. Mooi bijkomend effect is dat iedereen goed begrijpt waar we met zijn allen mee bezig zijn. Dat wil in mijn ervaring nog wel eens ondersneeuwen in alle hectiek.

Betekent dat dat elk track een eigen productowner krijgt? Niet per sé. In de laatste corporate venture die ik adviseerde was dat wel zo, maar daar bestond het team dan ook uit een man of twintig. Je kan in een kleinere start-up de tracks onderscheiden, maar besluiten om de tracks te verdelen over de teamleden.

Bonustrack: Validated learning

Je ziet dus dat alle tracks parallel lopen. Een bijzondere track die we daaraan toevoegen is het Validated Learning track. Even een eenvoudig voorbeeld met alleen een development track:

Je ziet dat de output van de development sprint, bijvoorbeeld een prototype van een Wizard, gebruikt kan worden als input voor de volgende Lean Cycle. In die Lean Cycle testen we bijvoorbeeld of de consument de wizard begrijpt en waardeert. De output van die Lean Cycle, bijvoorbeeld een verbeteringsvoorstel voor diezelfde wizard, kan dienen als input voor de volgende Sprint.

Het kunnen dus hypotheses zijn ten aanzien van het product, maar zoals ik al zei, dat kunnen ook hypotheses zijn uit andere tracks. Denk aan de hypothese: ‘de klant bereid is 2,99 per maand te betalen voor het product’ of: ‘de klant begrijpt de algemene voorwaarden.’

Die hypotheses kunnen dan vanuit die andere tracks gevoed worden aan het Validated Learning track, en de uitkomsten ervan kunnen teruggeleverd worden. Schematisch zou dat er als volgt uit kunnen zien:

Het werk van de Learning Owner

Naar analogie van de Product Owner in Scrum, wijzen we voor het Validated Learning track een Learning Owner aan. Dat is de man of vrouw die verantwoordelijk is voor het leveren van learnings, op basis van de input van anderen. De formele functie van zo iemand zou UX Researcher kunnen zijn, maar what’s in a name. Hoe dan ook; goed testen is beslist een vak. Stapsgewijs zou dat proces er als volgt uit kunnen zien:

1. Product Owners uit de andere tracks voeren gaandeweg hun werk hun hypotheses in in de Hypotheses Board, die je bijvoorbeeld in Trello of Jira houdt. Het is belangrijk dat het mentale eigenaarschap bij de productowner blijft liggen: hij/zij wil graag iets leren, immers!
2. De Learning Owner scherpt de hypotheses aan, vraagt waar nodig om verduidelijking en helpt de productowner om het scherp te krijgen. Hypotheses schrijven blijkt in de praktijk nog vaak wat oefening te vergen.
3. De Learning Owner stelt een set hypotheses samen die in deze cycle worden getoetst, en schetst er globaal de experimenten bij. Denk aan interviews, Facebook testcampaigns, surveys, observaties, et cetera.
4. De Learning Owner koppelt deze sprintplanning terug aan de productowners, en samen kijken ze of de prioriteiten kloppen: zijn dit de experimenten die we nu willen doen?
5. De Learning Owner voert de experimenten uit. Zij beschikt over een hele set aan testmethodes, en kiest wat het beste past.
6. De Learning Owner verwerkt de uitkomsten van de experimenten en documenteert die in het Hypothesis Board.
7. De Learning Owner koppelt een samenvatting van de learnings terug in de Sprintdemo, waar alle andere tracks ook hun voortgang demo-en.

En deze cycle doorlopen we dus elke twee weken. Je zou kunnen denken dat er alleen rond de demo informatie wordt uitgewisseld, maar dat zou de boel erg vertragen, en dat heb ik alleen gedaan om het schema helder te maken. In de praktijk gaat er input en output heen en weer zo snel als maar kan. We hebben haast, immers!

Lean en Scrum ineen: Scream Framework

In feite is dit dus een combinatie van de Lean Cycle en de Scrum Methode, vandaar de naam Scream. Ik noem het een framework, omdat het een raamwerk is waar je naar hartelust je eigen tracks in kan stoppen. Misschien speelt Legal voor jou helemaal geen rol, en is het opzetten van een servicedesk juist veel actueler. Het is een flexibele oplossing, die je gaandeweg naar je eigen start-up kan plooien. Inspect & Adapt, een van de belangrijkste Agile principes, weet je nog?

Hoewel het framework voor iedereen relevant is, en we ook liever niet al teveel management willen, is het wel verstandig om expliciet iemand aan te wijzen die de lead heeft om het framework zo effectief mogelijk te houden. Zoek iemand met een liefde voor processen en Agile.

Dus hoe ga je te werk:

• Ontwerp samen je eigen framework in een ochtend
• Maak iemand ‘eigenaar’ van het framework
• Besteed er in de retro aandacht aan, en pas aan waar nodig

Kortom:

Validated Learning zorgt dat je Corporate Venture de juiste beslissingen neemt. Het begint al eerder dan je MVP, en het gaat over meer dan alleen je product. Scream is een praktisch toepasbaar framework dat Validated Learning verankert in je corporate start-up.

Ik weet natuurlijk dat er al meerdere frameworks bestaan. Toch is mijn ervaring dat deze aanpak lekker praktisch en daarmee relatief eenvoudig te implementeren is.