Een app bouwen… waar begin je?

Geschreven door Elien Phernambucq.

elien@dwvd.nl
06 29 27 84 12

Een app bouwen kan een flinke investering zijn, dus voordat je die duik in het diepe neemt wil je eerst met je tenen voelen hoe warm het water is. Je wilt valideren of de app ook echt de sociale en/of financiële impact heeft die je zou willen. Dit kun je doen door een minimum viable product (MVP) te bouwen. Maar hoe bouw je zo’n app? Wat zijn cruciale keuzes? Hoe ziet het proces eruit? Dit zijn precies de vragen waarmee mensen bij ons aankloppen. In dit artikel lichten we een tipje van de sluier over het minimum viable product en het inrichten van experimenten zonder een app.

“The minimum viable product is that version of a new product a team uses to collect the maximum amount of validated learning about customers with the least effort.”

Minimum viable product

Door een MVP app te bouwen verzamel je maximale informatie met minimale uitgaven. Je bouwt ‘om te leren’ in plaats van ‘om te leveren/verkopen’. We noemen dit proces ook wel validated learning.

Een MVP is de versie van je app met álleen de hoognodige functionaliteit en broodnodige gebruikerservaring, meer niet. Zo’n minimale versie van de app zet je in om bij potentiële gebruikers feedback te verzamelen. Om meer te weten te komen over het probleem dat je app moet oplossen in de toekomst.

Het MVP is dus een middel om precies uit te vogelen hoe je de app en aansluitende service of business in de toekomst moet uitrollen. Je wilt hierover meer leren alvorens je ook écht de investering doet om een customer-ready app helemaal te laten ontwikkelen en bouwen (door een externe partij).

Je test deze app niet zomaar met een random publiek. Je selecteert een groep gebruikers waarvan je verwacht dat ze vergevingsgezind zijn: de early adaptors. Dit zijn mensen die zich sterk identificeren met de visie en het toekomstdoel van de app. Ze zien het toekomstige potentieel van de app en kunnen daarom door de hick-ups heenkijken. Met deze groep vroege app gebruikers probeer je uit te vinden hoe hun probleem écht in elkaar steekt.

“If you built it right, the minimum viable product tells you what really makes people tick”

Onze ervaring leert dat tijdens het testen van de MVP vaak betere oplossingen opkomen die niet in de originele roadmap zaten. Een klassiek gevalletje ‘kill your darlings’ waar niet iedere ondernemer tegen bestand is. Functionaliteiten waarvan je dacht dat ze cruciaal waren blijken bijzaak. De gebruikers kaarten dingen aan die nu niet in je concept zitten, maar diepgeworteld in het concept zouden moeten zitten.

 

Validated learning

Wij noemen het inbouwen van continue validatie in je ontwikkelingsproces validated learning. De dingen die je wilt valideren kunnen uit elkaar lopen. Je kunt bijvoorbeeld willen valideren of er wel genoeg vraag is naar je product (markt), hoe het complexe probleem dat je oplost in elkaar steekt (insight driven research) of wat het beste price point is (business model). Je vertaalt je eigen ideeën naar een als hypothese geformuleerde aanname. Deze aanname toets je vervolgens in een experiment.

In sommige gevallen is voor het opzetten van een experiment geen app nodig. Je kunt dan bijvoorbeeld ook met een landingspage, typeform of facebook advertentie uit de voeten. In andere gevallen wil je een combinatie van product functionaliteiten testen, of twee doelgroepen samenbrengen. Hiervoor is het ontwikkelen van een app wel handig. Maar hoe kies je eigenlijk of je eerst experimenten gaat runnen, of (meteen) een MVP app moet laten bouwen? En wat is eigenlijk het verschil?

 

Een minimum viable product of een (ander) experiment?

Om lean startup guru Eric Ries te quoten: “It requires judgement to figure out, for any given context, what minimum viable product makes sense.” Kortom, ieder proces is maatwerk. Maar wellicht helpen onderstaande tips and tricks je de goede richting op.

 

Probeer het app bouwen zo lang mogelijk uit te stellen
Het klinkt een beetje gek uit de mond van een app bouwer, maar wij adviseren vaak om het bouwen van de app uit te stellen. Omdat een app bouwen kostbaar is, kun je je altijd afvragen of er een alternatieve manier is om antwoord te krijgen op de aannames. Bedenk dus eerst of er een manier is waarbij je de reactie van gebruikers kunt testen zonder een hele app te bouwen. Voorbeeld: wij ontwikkelden de app Fello. Een familie agenda app die recent werd overgenomen door coöperatie DELA. Om het verdienmodel van de app te valideren, experimenteerden we tijdens de ontwikkeling achter de schermen met de betaalbereidheid van potentiële klanten. We tuigden een experiment op met Facebook-advertenties die (nog) niet bestaande agenda functionaliteit toonden. Door te meten hoeveel mensen op welke advertentie klikten, leerden we meer over waar de gebruiker naar op zoek was. Met deze ‘dummy’ konden we tractie van verschillende proposities doormeten. Het was niet nodig om daadwerkelijk de app te bouwen. Omdat we pas begonnen te bouwen met de app toen we précies wisten welke propositie bij de families aansloeg, hebben we ontwikkelingskosten kunnen besparen. Wil je hier meer over weten? Mijn collega Niels schreef een blog over hoe dit in z’n werk ging.

 

Neem ‘problem interviews’ af
Het probleem dat je app oplost zit in de werkelijkheid misschien net iets anders in elkaar dan je denkt. Middels een problem interview probeer je zonder oordeel te achterhalen hoe het probleem precies in elkaar steekt, wat de doelgroep al gedaan heeft om dat probleem op te lossen en of het probleem groot genoeg is voor de doelgroep. Cruciaal bij een problem interview is dat je niet pitcht welk idee je zelf voor een app hebt, maar je puur focust op het probleem. Jouw idee komt dus op geen moment ter sprake! Hier een filmpje over hoe je problem interviews wel en niet moet afnemen.

 

Formuleer user stories
Besluit je toch om een app te gaan bouwen? Definieer dan wat de core van het concept is en welke functionaliteiten bijzaak zijn. Maak een lijst met alles wat de app moet doen. Dit kun je doen door ‘user stories’ te formuleren. Definieer iedere ‘story’ zo klein mogelijk en splits functionaliteiten op waar dit kan. Verdeel de stories dan op in de clusters ‘absolutely crucial’, ‘must have’, ‘nice to have’. Wees kritisch. Je kunt dit eventueel ook met je doelgroep samen doen. Heb je moeite om producteigenschappen in de juiste categorie te stoppen? Eerder schreef ik een artikel over het verschil tussen delight features, lineaire features en de basishygiëne.

 

Definieer de kritische succesfactoren van je app
Wat zijn kritische succesfactoren van je app? Voorbeeld: als je een groepschat wilt bouwen biedt je app alleen waarde wanneer er meerdere mensen in een groep zitten. Heel simpel gezegd: iemand die alleen in een groepschat zit ervaart totaal geen waarde. Je moet er dus voor zorgen dat zoveel mogelijk mensen die een groep starten andere gebruikers uitnodigen in de groep. Je zou dit een kritische succesfactor kunnen noemen. Hier kun je op kleine schaal mee gaan experimenteren. Je aanname luidt dan bijvoorbeeld “Ik verwacht dat wanneer ik 100 mensen de productdemo laat zien, 70 mensen de actie ondernemen een vriend/vriendin uit te nodigen”.

 

Bedenk een mechanisme om je meest risicovolle aanname te testen
Om de meest risicovolle aanname uit het bovenstaande voorbeeld te testen hoef je niet de hele groepschat te programmeren. Je kunt dit ook testen in een click model. Bijvoorbeeld: Je kunt een dummy maken van de onboarding, daarna de product demo laten zien (plaatjes, video, etc) en meten of de testpersonen daadwerkelijk overgaan tot het invoeren van telefoonnummers van hun vrienden. Waak er wel voor dat je oprecht en duidelijk bent over je intenties tegen gebruikers. Mensen als testvee gebruiken is nooit een goede start van een startup. Je wilt een goede test kunnen afnemen (dus mensen onbevooroordeeld en ongeïnformeerd laten starten), maar je wilt achteraf wel de eerlijke intenties kunnen toelichten.

 

Formuleer een definition of succes
Begin een experiment niet zonder eerst met je team af te stemmen wanneer je een aanname als gevalideerd beschouwd en wanneer hij faalt. Wanneer je enthousiast bent over je app concept, is het een hardnekkige valkuil om een gefaald experiment toe te schrijven aan toevalligheden. Deze valkuil herken je wanneer je jezelf hoort zeggen “..wanneer we het design anders hadden gedaan was het wellicht wel goed gegaan..”. Of “Ja, maar die gebruiker was gewoon echt dom, met X en X zou het wel lukken..”. Wees helder over je definitie van succes. Maak er eentje waarin niet is te tarten. Bijvoorbeeld: De aanname is gevalideerd als we 200 unieke bezoekers hebben binnen 24 uur waarvan minimaal 25 unieke bezoekers op de download button drukt. Hier vind je een formatje om dit in te doen.

 

Formuleer de grenzen van je experiment
Het actiemiddel om mee te testen kan een deel van een website zijn, een functionaliteit, een advertentie, een folder, een deel van een app, je kunt het zo gek niet bedenken. Stel ook hier een harde deadline of richtlijnen waarover niet valt te twisten. Bijvoorbeeld: We besteden maximaal 10 uur design en 25 uur programmeerwerk aan het bouwen van deze landingspage. Hij moet voor vrijdag 12 uur af. We nemen het experiment af in precies 24 uur en besteden maximaal €200,-.

 

 

We helpen je graag!

Met ons digitale bureau De Wortel van Drie hebben we vier jaar lang gewerkt aan Fello, ons eigen app idee. In maart 2018 verkochten we die app aan coöperatie DELA. Gedurende de jaren hebben we veel ervaring opgedaan met het ontwikkelen van minimum viable products, het bouwen van een eigen app en het runnen van een startup. Deze kennis zetten we nu graag in voor klanten.

Een keertje vrijblijvend sparren over jouw app idee? Je bent van harte welkom op ons kantoor in Delft. Bij De Wortel van Drie werken we met een vast team van strategen, designers en developers. Als je langskomst zorg ik natuurlijk voor de koffie!

 

alle artikelen

app laten ontwikkelen?

Neem geheel vrijblijvend contact op voor een prijsindicatie of afspraak.