Bouw snel, begrijp eerst: wat Finny ons leerde

We bouwden Finny twee keer. De tweede keer begrepen we eerst het probleem

Twee adviezen in productontwikkeling lijken elkaar tegen te spreken. Enerzijds moet je grondig scopen voordat je bouwt. Anderzijds moet je snel starten, omdat je pas leert wanneer een product echt gebruikt wordt. In werkelijkheid gaan deze adviezen over verschillende dingen.

Dat inzicht leerden we door Finny twee keer te bouwen.

De “snelle” start die dat niet was

Finny begon als een zijproject binnen een grotere financiële tool. Uiteindelijk werd het een ogenschijnlijk eenvoudige toepassing: een tool om financiële plannen te maken. De scope leek beperkt, dus we deden wat onderzoek en begonnen snel te bouwen.

De fout zat in wat we precies scopeden. We definieerden de oplossing, niet het probleem. In de praktijk werden financiële plannen opgebouwd in Excel, waar accountants volledige flexibiliteit hadden om modellen aan te passen aan elke situatie.

Zonder het expliciet te maken, probeerden we die flexibiliteit in software te vangen. Dat bracht een complexiteit met zich mee die we onderschat hadden.

Het gevolg was dat de software al snel onder druk kwam te staan door use cases waar ze niet voor ontworpen was.

Feedback die het probleem blootlegde

De feedback van gebruikers maakte het probleem duidelijk. Het ging niet om kleine verbeteringen, maar om fundamentele beperkingen. Bepaalde scenario’s konden simpelweg niet gemodelleerd worden.

Dit was geen kwestie van extra features toevoegen. De basis klopte niet. We hadden te snel gebouwd op een onvolledig begrip.

De enige logische stap was opnieuw beginnen.

Herstarten met de juiste focus

Bij de tweede poging namen we de tijd om het probleem echt te begrijpen. Hoe worden financiële plannen opgebouwd? Waar is flexibiliteit essentieel en waar niet? Wat is de structuur achter de variaties die Excel mogelijk maakt?

Dit voorbereidende werk maakte een groot verschil. Het voorkwam herwerk en gaf duidelijke richting aan de ontwikkeling. Grondig scopen is geen vertraging, maar een investering die later veel tijd bespaart.

Toch snel blijven bouwen

Tegelijkertijd bleven we snel itereren. We brachten zo snel mogelijk een werkend product naar gebruikers.

Probleembegrip en productontdekking zijn verschillende fases. Het eerste gebeurt vooraf. Het tweede alleen in gebruik.

Belangrijke features ontstonden tijdens gebruik:

• Onboarding evolueerde naar een AI-ondersteund proces na observatie van gebruikersproblemen.

• Chatfunctionaliteit ontstond uit de behoefte om plannen eenvoudig aan te passen.

• Business plans werden toegevoegd toen bleek dat gebruikers alles in één omgeving wilden.

Deze inzichten kwamen niet uit plannen, maar uit gebruik.

De echte les

De tegenstelling tussen beide adviezen is schijn.

Begrijp het probleem grondig voordat je bouwt. Daar zit de complexiteit die je project kan maken of breken.

Ontdek het product terwijl je bouwt. Daar ontstaan de beste features.

De eerste versie van Finny was snel gebouwd op een zwakke basis. De tweede versie was even snel, maar gebouwd op een sterk begrip.

De snelheid bleef gelijk. Het inzicht veranderde alles.