Snelheid en haast zijn niet hetzelfde
Bij Blis Digital zien we dagelijks de uitdagingen waar innovatieve bedrijven mee worstelen. Ze komen bij ons met een idee en meestal is dat idee echt goed. Maar een goed idee is niet hetzelfde als een idee dat klaar is voor ontwikkeling. Niet altijd een makkelijk verhaal om te moeten vertellen aan een opdrachtgever die het product liever gisteren dan vandaag in de markt wil zetten. Toch is haastig beginnen aan een product niet altijd de snelste weg naar succes.
“We willen zo snel mogelijk iets hebben, want de markt wacht niet.” Vaak is dat het argument om snel te willen beginnen met bouwen van software. En het is niet alleen de markt die druk uitoefent op bedrijven met een nieuw, innovatief product. Vaak zijn er al beloftes gedaan aan stakeholders of investeerders, of het budget is beperkt. Maar los van de spanning tussen snelheid en kwaliteit, die ieder creatief vak met zich meebrengt is er nog een belangrijke reden om niet meteen code te gaan schrijven.
Tijd nemen om na te denken
Want nu tijd nemen om even goed na te denken levert je straks enorme tijdswinst op. Of, om het negatief te formuleren: als je nu overhaast begint, duurt de ontwikkeling waarschijnlijk langer. Of je product haalt, in het ergste geval, de eindstreep helemaal niet.
Het financiële risico van een MVP is namelijk al behoorlijk groot. We zien nog steeds vaak dat de interpretatie van ‘agile’ neerkomt op ‘we zetten iets live en dan zien we wel’. En het kan zijn dat je op die manier tot een goed resultaat komt, maar het is bijna nooit de snelste en zeker niet de goedkoopste manier.
Vanaf dag één van een productontwikkeltraject strijden wij dus altijd voor het nemen van voldoende tijd nemen om na te denken, ook al weten we dat we snel moeten leveren.
Want we willen niet zomaar een product maken, we willen een product maken dat mensen ook echt willen hebben. En daar zit precies de uitdaging. Want overhaaste beslissingen – dat wil zeggen: beslissingen die zijn genomen zonder de juiste kennis van de markt – kunnen later duur kunnen uitpakken.
Een andere kijk op productontwikkeling
Bij Blis weten we uit ervaring ook dat een doordachte aanpak uiteindelijk sneller tot een mooi en commercieel succesvol resultaat leidt. Daarom hebben we een aanpak ontwikkeld die het beste van twee werelden combineert: het elimineren van risico’s én snelheid van ontwikkeling.
Die snelheid halen we vooral uit onze ervaring, uitgebreide toolset en efficiënte manier van werken. Het elimineren van risico’s doen we vooral met onze ondernemersblik. Want bij Blis hebben we de ambitie om niet alleen developmentprojecten tot een goed eind te brengen, maar ook om mee te ondernemen met de mensen die de producten bedenken en in de markt zetten. Soms gaat dat zo ver, dat we aandeelhouder worden, maar meestal neemt dat mee-ondernemen de vorm aan van kritisch kijken naar product en markt en de keuzes die daarbij horen. Daar hoort het begeleiden en adviseren van product owners bijvoorbeeld ook bij.
Het belang van de juiste focus
Heel vaak zien we dat bedrijven vaak al in de juiste ‘problem space’ zitten: ze hebben een waardevol probleemgebied gevonden waar uitdagingen opgelost moet worden en waar dus geld te verdienen is. Ze kennen hun markt, kortom, goed genoeg om een algemeen beeld te hebben van waar hun potentiële klanten mee worstelen. Maar dat is niet genoeg, want een succesvol digitaal product lost geen algemene, maar hele specifieke, concrete problemen op. En die specifieke problemen, die hebben veel bedrijven nog niet te pakken als ze bij ons komen. Voor een succesvol product moeten we de probleemstelling dus nog verfijnen.
De overtuiging dat je dit kunt doen met pilotprojecten leidt vaak tot problemen, omdat je bij het bouwen van die pilot(s) vaak nog steeds specifieke, cruciale en concrete problemen niet scherp genoeg in beeld hebt. Terwijl je aan de bouw wel veel geld uitgeeft. Dit is waar onze aanpak zich onderscheidt. In plaats van direct te beginnen met bouwen, nemen we eerst de tijd om het probleem scherper te krijgen. Want we weten uit ervaring dat deze investering in de voorbereidingsfase zich dubbel en dwars terugbetaalt.
Ons stappenplan naar een succesvol product
We doen dus meer dan alleen een stuk software ontwikkelen – we worden echt partner in het proces van productontwikkeling en we denken dus ook mee over het vinden van product-market fit en het slim besteden van het investeringsbudget.
Dit is het stappenplan dat we daarbij volgen:
-
Concept en visualisatie – de ‘concept car’
Voor een heldere productvisie heb je eerst een helder beeld nodig van wat je aan het maken bent. We beginnen dus met een goede conceptplaat of visualisatie, zoals de auto-industrie markt en innovatie vaak bij elkaar brengt met het tonen van een concept car. Beelden en modellen spreken nou eenmaal meer aan dan woorden alleen. Zo maken we stakeholders, potentiële investeerders en eindgebruikers al enthousiast en dwingen we onszelf onze ideeën concreet te maken. Deze aanpak helpt ons om nog beter te begrijpen waarom het idee waardevol is voor de verschillende stakeholders en de business. Het visuele concept dat we in deze fase ontwikkelen is, hoewel het technisch nog ‘niets doet’, voldoende om deze zeer waardevolle informatie te verzamelen. Door inzet van dit soort technieken kunnen we, als we eenmaal gaan bouwen, streven naar ‘one-time-right’ en dus het budget veel gerichter besteden.
-
Werkend prototype
Een eerste prototype geeft antwoord op de cruciale vraag: hebben we het probleem nou scherp? Het kan een mini-app zijn, maar ook een klikbaar Figma-prototype. Op geen enkele manier lijkt dit op productieklare software (het lijkt meer op een frisdrankautomaat waar een software developer in zit om handmatig het geld te tellen en op het juiste moment een blikje drinken naar buiten te gooien), maar het kan al wel aan gebruikers laten zien hoe de software gaat werken. En dus kunnen wij als ontwikkelaars het gebruiken om waardevolle kennis over onze gebruiker te verzamelen.
-
Proof of Technology
Nu gaat het om het bewijzen dat we de techniek werkend kunnen krijgen. We laten alle mooi vormgegeven schermen even weg en maken een technisch prototype. Als we een commando intypen, zien we het systeem reageren, de juiste API-calls maken en met data terugkomen. Het is de digitale variant van het ‘breadboard’, een bord waarop elektronicaspecialisten nieuwe schakelingen testen (en wat er voor het ongeoefende oog uitziet als een plank waar een wilde bos draden uit steekt): niemand behalve een developer snapt er iets van, maar het geeft het team het vertrouwen dat wat we willen bouwen ook echt mogelijk is.
-
MVP (Minimum Viable Product)
Als alle voorgaande stappen succesvol zijn, komen techniek en concept samen in het MVP. We bouwen dit nu met het vertrouwen dat de grote risico’s er al uit zijn en kunnen het dus snel uitrollen naar een markt waarvan we min of meer zeker weten dat die erop zit te wachten.
De rol van kritiek en validatie
De kern van de zaak is: zorg dat je zo snel mogelijk kritiek op je product verzamelt in de echte wereld, bij echte gebruikers – wat wij noemen: get out of the building. Bij Blis vinden we dit cruciaal, omdat we in de praktijk nog steeds soms dingen bouwen die anders hadden gemoeten. Of die we achteraf gezien beter achterwege hadden kunnen laten.
Keer op keer blijkt weer dat bedrijven de kosten van development onderschatten. Mission critical software is altijd complex van aard en altijd arbeidsintensief om te maken. En dus niet goedkoop. Development is en blijft werk voor schaarse specialisten die ieder uur maar één keer kunnen besteden. Daarom moet je goed nadenken over alles wat je bouwt, voordat je het bouwt. Het goede nieuws is dat je ontzettend veel kunt testen voordat je een MVP maakt.
De moed om niet alles te weten
Terug naar de ondernemer die bij ons komt en ‘zo snel mogelijk iets wil hebben’. In eerste instantie zit die misschien niet te wachten op onze kritische vragen, maar meestal hebben ze al snel door dat wij dingen vragen die ze simpelweg nog niet weten. En dat er dus, om de risico’s uit het project te halen, meer onderzoek nodig is.
En dat is de allerbeste manier om je innovatiebudget en je ontwikkeltijd slim te besteden: toegeven dat je bepaalde dingen gewoon niet weet. Dat betekent helemaal niet dat we je idee in de prullenbak moeten gooien. Je idee kan nog steeds geniaal zijn, maar misschien op een net iets andere manier dan je eerst dacht.
En vergeet niet ook nog wat budget te bewaren voor als je MVP live is. Want na het MVP begint het echte leren pas. Een eerste versie is nou eenmaal nooit een optimale versie en juist als je product echt gebruikt wordt door echte gebruikers ga je dingen ontdekken die je eerder niet kon weten. En dan ga je pas echt waarde toevoegen.
Bekijk ons whitepaper
Wil je meer lezen over Product ontwikkeling? Lees dan ons whitepaper: Waarom je geen product owner wilt worden (en 4 dingen die je moet doen als je al PO bent en succesvolle innovaties wilt afleveren). Hierin onze 4 gouden tips om als product owner succesvolle projecten op te leveren en te werken aan je eigen status in de organisatie.
