Meerwaarde bouwen in plaats van applicaties

Het bouwen van software blijft een vaak complex proces waarin heel veel opeenvolgende stappen en activiteiten goed overdacht en gesynchroniseerd moeten worden. Vaak komen daar verschillende teams en deskundigen bij kijken, met elk hun eigen agenda, specialisaties en gevoeligheden. In zulke omstandigheden zijn fouten snel gemaakt. 

Bij Pàu Studio, het interne ontwikkelteam van de Antwerpse IT- en designconsultant Pàu, kennen ze het probleem. Om niet in dit soort valkuilen te trappen, maken zij – als het kan – graag gebruik van Lean Startup. “Lean Startup is een soort methodologie die ervoor zorgt dat je snel de juiste inzichten in een project kunt verkrijgen en die je een project snel laat bijsturen”, zegt Kevin Wenninger, Digital Product Expert bij Pàu. “De kernideeën zijn opgesteld in het boek The Lean Startup, dat in 2011 werd uitgebracht door de Amerikaan Eric Ries. Daarin beschrijft hij hoe je als start-up snel, kostenefficiënt en doelmatig een product kunt uitbrengen, de zogenaamde lean product development. En die methodes passen wij nu toe op softwareontwikkeling.” 

Wie zit er op te wachten?

Lean Startup drijft op twee grote principes, zegt Wenninger. “Stel dat je als bakker een nieuwe bakkerij wil openen, dan heb je al veel veel referenties en best practices waaraan je je kunt spiegelen. Je weet ongeveer hoe je winkel eruit zal zien, welke producten je zult moeten maken, hoeveel klanten je ongeveer kunt verwachten. Bij een nieuw product, een nieuw idee of een nieuwe feature heb je die luxe meestal niet. Vaak weet je niet exact wat het gaat worden of hoe het precies gaat werken. Je maakt veel assumpties over je product, maar eigenlijk weet je het niet. Je eerste stap wordt dus het testen van die assumpties. Wat jij aanneemt over je product, klopt dat wel? Of meer zelfs: willen mensen jouw product wel? Is er vraag naar? Zit iemand er op te wachten?”

Het klinkt bizar, maar het zijn fundamentele vragen die veel bedrijven zich vergeten te stellen, zegt Wenninger. En hij kan het weten. “Ik had ooit het idee om een app te maken waarmee je een bouwaanvraag kunt vereenvoudigen. In Duitsland (zijn geboorteland, red.) werd op een gegeven moment door de overheid een nieuw document gepubliceerd van 250 pagina’s dat bouwheren moesten doorlopen en waar ze uren mee bezig zouden zijn. Wij dachten dat we dat met onze digitale app geweldig konden vereenvoudigen. En dus begonnen we als gekken te programmeren. We gingen een platform bouwen om gebruikers te beheren, we voegden features toe om met verschillende gebruikers aan eenzelfde document te werken, op een gegeven moment waren we zelfs al betaalfuncties aan het integreren (lacht).”

“We waren met zoveel dingen tegelijk bezig dat het minstens een jaar zou duren eer we een eerste versie van de app zouden klaar hebben. Nog erger: we beseften ook pas heel laat dat planners zo’n app eigenlijk niet nodig hadden. Hadden we ons niet verloren in al die overbodige features zouden we dat inzicht allicht veel sneller gekregen hebben.” 

En dat is een plaag die veel softwareprojecten teistert, zegt Kevin Wenninger. Vaak worden projecten zo uitgebreid dat niemand meer weet waar het in de kern eigenlijk om draait. En op die manier wordt heel veel tijd en geld verspild. 

Build, Measure, Learn

Het tweede principe is dat in Lean Startup gewerkt wordt in korte, behapbare tussenstappen die ontwikkelaars snel de juiste inzichten over hun product laten krijgen. “Elke tussenstap wordt gevalideerd volgens het principe van ‘build, measure and learn’”, legt Wenninger uit. “Build is het pure ontwikkelproces, bijvoorbeeld in Scrum. Daarbij werk je met korte sprints waarin je features toevoegt. Dat kan ook gebeuren met low code- of no code-platformen, dat maakt in principe niet uit.”

“In Measure ga je de juiste verwachtingen en resultaten definiëren. Als ik bijvoorbeeld dit, dit en dit programmeer en toevoeg, kan ik zoveel extra gebruikers van mijn software verleiden om een account aan te maken. Ik ga dus meten. In dit geval of mijn conversion rate omhoog gaat. In Learn ga je na of de aanname die je had (“dankzij deze features gaat mijn conversion rate omhoog”) ook de juiste was. Als dat zo is, prima. Als dat niet zo is, zal je moeten zien of je een andere oplossing vindt om je assumptie te valideren of dat je jouw assumptie moet aanpassen.” 

Een zeer belangrijk punt in de Learn-fase is het betrekken van gebruikers, zegt Kevin Wenninger. “Je moet niet alleen meten of en hoeveel mensen een account aanmaken. Maar ook waarom ze dat al dan niet doen, bijvoorbeeld door interviews. Dat levert vaak onmisbare inzichten op om je software beter te maken in de volgende Build-fase. Want ‘Build, Measure, Learn’ is als een oneindige cyclus die constant doorgaat.”

Minimum Viable Product

Naast het valideren van assumpties en de ‘Build, Measure, Learn’-cyclus, is er nog een belangrijk principe binnen Lean Startup, en dat is het Minimum Viable Product of MVP. “Het MVP is een versie van het product dat van minimale functionaliteiten is voorzien, maar dat al meteen een meerwaarde aan de gebruiker geeft”, legt Wenninger uit. “Stel dat je een mobiliteitsoplossing moet ontwikkelen. Je stelt een team samen, je begint keihard te werken en na pakweg vijf jaar presenteer je…een nieuwe auto. In Lean Startup pak je dat compleet anders aan. Je begint te ontwikkelen en na een half jaar kom je naar buiten met een step. Die is lang niet zo comfortabel als een auto. Maar je kunt er tenminste wel al lange afstanden mee afleggen.”

“Het is een Minimum Viable Product dat gebruikers al meteen meerwaarde geeft, want ook met een step kunnen ze zich verplaatsen. Je kruipt terug in je kelder en een paar maanden later, terwijl iedereen al je step gebruikt, kom je naar buiten met een step waar een motor aan toegevoegd is. Alweer: meerwaarde, want de verplaatsingen gaan nu een stuk sneller. Nog wat later voeg je twee extra wielen toe. Je hebt dan een soort go-cart, die een stuk comfortabeler is dan een step. En daarna pas ga je die go-cart zo verbeteren dat je uiteindelijk een auto krijgt. Je gaat dus in elke tussenstap meerwaarde inbouwen via voortschrijdend inzicht en feedback. En tegelijk zorgt het Minimum Viable Product er ook voor dat elke nieuwe generatie van je product nog altijd aansluit bij je oorspronkelijke assumpties.” 

Een andere aanpak, een ander idee

Door voortdurend rekening te houden met die oorspronkelijke assumpties en door de drang om snel en constant meerwaarde te leveren, kan het gebeuren dat klanten bij Pàu aankloppen met een bepaald idee. Maar dat tijdens het proces het idee totaal van richting verandert, zegt Kevin Wenninger.

“Als we naar projecten kijken die zeer complexe algoritmes of AI bevatten, kan het zeker nuttig zijn om die assumpties daarrond te challengen en eerst eens te bekijken hoe waardevol de resultaten voor de gebruikers zijn. AI is vaak erg ingewikkeld en soms duurt het lang tot je het juiste algoritme hebt gemaakt dat precies aansluit op de noden van de gebruikers. Dit in vraag stellen, kan resulteren in een compleet andere aanpak van het project. Het zou bijvoorbeeld kunnen dat we de ontwikkeling van het algoritme pas later doen, nadat we inzichten van gebruikers hebben verzameld. Op die manier kan je bijvoorbeeld berekeningen die AI zou doen, manueel uitvoeren, in pakweg Excel. Met natuurlijk een disclaimer dat de data pas binnen enkele uren of dagen beschikbaar zijn (lacht).” 

Op die manier wordt dan een basis gevormd om met de gebruikers in gesprek te gaan en duidelijk te bepalen wat nu eigenlijk de verwachtingen zijn. Het is dan nog altijd perfect mogelijk dat ze aangeven dat ze bijvoorbeeld hun data toch in realtime willen. Of dat een ander soort berekening nuttig zou zijn. “Op die manier weet je snel wat er precies ontwikkeld moet worden en kan je dit efficiënt inplannen met een lager risico”, aldus Kevin. 

Niet alleen worden softwareprojecten vaak te snel uitgebreid en veranderen ze in een onoverzichtelijk kluwen. Door veel tijd en centen te steken in ongeteste en misschien zelfs ongewenste features zullen bedrijven ook niet snel geneigd zijn om die features er weer uit te halen. Ze hebben immers “geld gekost”. Veel innovatieve producten worden daarnaast ook nog te veel ontwikkeld met een ‘founders’-mentaliteit, zegt Kevin. “Die mentaliteit is: we gaan alles nu meteen ontwikkelen en toevoegen. En liever nog vandaag dan morgen (lacht). Dus in plaats van te testen gaat men als gekken programmeren. Zonder de broodnodige inzichten te verzamelen en in stappen te bouwen. Zo doet men dan verder tot het budget op is. En dan is er vaak nog geen definitief product.” 

Strategische partner

De Lean Startup-aanpak daarentegen komt dus met een pak voordelen. “Je kunt snel naar de markt trekken met een applicatie en heel dicht bij de gebruikers komen. We gaan hen zo snel mogelijk betrekken, want hun feedback is cruciaal. Zij moeten het product uiteindelijk gebruiken. Zo krijgen we ook heel snel inzicht of de richting waar we naartoe willen wel de juiste is en wordt het budget dat we hebben optimaal ingezet. Op die manier wordt Pàu ook meer dan een app-bouwer. Wij zijn een strategische partner in heel het ontwikkelproces en leveren meerwaarde in plaats van gewoon een applicatie.”