Van bierviltje tot ontwikkelplan

Geplaatst door Ralfop 27 maart 2020

Regelmatig komen mensen naar mij toe en vertellen ze over hun idee voor een app of platform. Soms uitgetekend op een bierviltje, maar vaker nog alleen een gedachtenspinsel. De vraag daarna is vaak “wat kost dat?” of “hoe moet ik dit verder aanpakken?”. Om die eerste vraag zinvol te kunnen beantwoorden moeten de wensen en eisen iets concreter zijn. Maar hoe pak je dat dan aan? 

Je hebt een plan nodig. Met jouw ontwikkelplan kunnen wij en andere ontwikkelaars je een betere inschatting geven wat het bouwen kost. Daarnaast helpt het je ook bij het zoeken van eventuele financiering en bij de uiteindelijk ontwikkeling van je product. Kortom, erg waardevol!

Hieronder leg ik uit welke 4 stappen wij (ook in onze workshops) grofweg volgen om tot zo’n ontwikkelplan te komen:

  1. Doelgroepen
  2. Waardepropositie
  3. Wensen & eisen
  4. Uitwerking

Dit proces wordt ook wel conceptontwikkeling genoemd.

Stap 1 - Doelgroepen

Het begrijpen en beschrijven van je doelgroep of doelgroepen is misschien wel de belangrijkste stap. Als je een product of dienst verkoopt, dan vallen hier ook je klanten onder. Uit wat voor mensen bestaat de doelgroep? Wat voor taken en verantwoordelijkheden hebben ze (jobs)? Welke problemen hebben ze nu (pains)? Waar worden ze gelukkig van (gains)?

Empathie 

Om daarachter te komen moet je contact opnemen met de mogelijk toekomstige gebruikers van je product of dienst. Stel ze vragen en loop eventueel een dag met ze mee. Hoe beter je ze begrijpt, hoe beter je plan wordt en hoe beter het eindresultaat wordt. Zet ook op papier wie er nog meer een belanghebbende is of kan zijn. Denk bijvoorbeeld aan leveranciers, partners, een andere afdeling en/of jijzelf.

Interessant hulpmiddel: Empathy map van IDEO

Persona’s

Als je voldoende informatie hebt over je belangrijkste gebruiker(s), dan kan je eventueel ook persona’s maken. Persona’s zijn fictieve personen met een profiel dat typisch is voor je doelgroep of een deel van je doelgroep. Het opstellen van persona’s is subjectief werk en daarom niet ideaal, maar voor sommige mensen zijn ze handig in stap 2 en 3. Geef je persona dan een naam, een gezicht en een minibiografie van een paar alinea’s. Neem daarin ook zaken op zoals leeftijd, werk, opleiding, hobby’s, etc. Beperk je tot maximaal 3 persona’s.

Op Frankwatching staat een artikel met meer informatie over persona’s inclusief een voorbeeld.

Stap 2 - Waardepropositie

Zodra je je potentiële klant of eindgebruiker kent, dan kan je daar ook de waardepropositie van je product of dienst op afstemmen. Kortom, de beschrijving wat en welke meerwaarde je de klant precies biedt. Welke functionaliteiten en eigenschappen moet je idee bieden waardoor het geluk van de doelgroep toeneemt (gain creators)? Waarmee verminder je pijnpunten bij je klanten (pain relievers)?

Onderscheidende propositie

Een goede propositie is niet alleen afgestemd op de doelgroep, maar verschilt ook van concurrenten in de pains en gains waarop gericht wordt. Dus kijk welke pains en gains andere aanbieders proberen op te lossen en maak zelf waar mogelijk andere keuzes. De beste waardeproposities richten zich op een klein aantal grote pains en/of gains. Ook overtreffen deze proposities de concurrent significant op minimaal één aspect en zijn ze lastig te kopiëren.

Value Proposition Canvas

Beeld uit het boek: Value proposition design

Business model canvas

Zet je propositie ook in een business model canvas. Dat dwingt je om na te denken over onder andere de inkomsten, uitgaven en partnerships. Op die manier krijg je een eerste indruk van de haalbaarheid en levensvatbaarheid van je idee. Met de inschatting van de ontwikkelingskosten (na stap 3 en 4) en de validatie van je propositie (iets voor een volgende blog) kan je dit canvas continu blijven aanvullen, aanpassen en verbeteren.

Business Model Canvas

Beeld uit het boek: Business model generation 

Stap 3 - Wensen & eisen

Als je voorgaande stappen hebt doorlopen, dan kan je de wensen en eisen voor je product of dienst op papier gaan zetten. Dit is vooral een stap waar je de breedte in gaat. “Expanding the solution space”, zoals ze in het Engels zeggen. Dus denk niet teveel over elk dingetje na. Dat komt later wel. Maar hoe schrijf je de requirements het beste op?

User stories

Een van vormen die je kan gebruiken om dit snel en goed te doen is door elke wens van een gebruiker (of andere stakeholder) te beschrijven als een “user story”. Hiervoor kan je het volgende model gebruiken:

Als een <stakeholder> wil ik <wens>, zodat <waarde>

Stakeholder (wie)

Waarbij stakeholder dus een bepaalde doelgroep kan zijn, zoals je die in stap 1 in kaart hebt gebracht. De meeste wensen zullen geredeneerd zijn vanuit de klant, maar je kan ook zelf wensen hebben. Denk bijvoorbeeld aan het kunnen analyseren van het gebruik van je dienst of het leveren van support op je product.

Wens (wat)

De wens is wat deze doelgroep wil kunnen met je product of dienst. Bijvoorbeeld snel contact met je kunnen opnemen bij een probleem of het e-mailadres kunnen wijzigen.

Waarde (waarom) 

Het opschrijven wat mensen willen is vaak het makkelijkste deel, maar voor ontwikkelaars (en eigenlijk ook voor jezelf) is het belangrijk dat je ook weet waarom. Het laatste deel van de user story beschrijft de waarde van de wens voor de gebruiker en/of de waarde voor je product of dienst. 

Ter illustratie: Je ziet vaak een versienummer in een app staan, maar waarom? Met de volgende user story wordt duidelijk voor wie en waarom dat belangrijk is:

Als een supportmedewerker wil ik weten welk versienummer van de app de klant gebruikt, zodat ik kan controleren of mijn klant wel de laatste versie gebruikt.

Meer weten? Lees dan ook het het artikel van Mike Cohn over user stories.

Best practices

Soms kunnen er meerdere redenen zijn waarom een stakeholder een wens heeft. Schrijf die dan altijd zoveel mogelijk als losse user stories op.

Probeer in de user stories zo min mogelijk de oplossing al te beschrijven. Soms zijn er namelijk betere oplossingen te bedenken voor de wens van de gebruiker. De vertaling naar oplossingen doe je later samen met de ontwikkelaar.

Het opschrijven van user stories werkt daarnaast het beste als je dat in korte sessies doet, van bijvoorbeeld 10 a 15 minuten. Focus je in elke sessie op één van de stakeholders. Dan kan je je echt in die persoon of doelgroep verplaatsen en zo makkelijker en sneller allerlei wensen bedenken. Probeer te wisselen van stakeholder tussen opeenvolgende sessies. Dat houdt je scherp en creatief.

Post-its zijn handig als je met meerdere mensen tegelijk user stories schrijft. Gebruik dan wel een dikke stift, zodat je gedwongen wordt om details achterwege te laten. Liever veel korte user stories dan een paar lange!

Product backlog

Om je user stories makkelijker te kunnen beheren en bewerken moet je ze digitaal vastleggen. Hiervoor zijn allerlei apps te vinden, maar een spreadsheet zoals excel of numbers werkt ook prima. Heb je de user stories op post-its geschreven? Dan heb je nog wat extra werk te doen.

Het handigste is om voor de stakeholder, wens en waarde kolommen te maken in je spreadsheet. Zo krijg je een lange lijst met user stories onder elkaar. Zo’n lijst noemen ontwikkelaars de product backlog.

Stap 4 - Uitwerking

In de vorige stap ben je de breedte in gegaan. Daardoor heb je nu een lijst met belangrijke, onbelangrijke, zinvolle en futuristische wensen in willekeurige volgorde. Hoe moet je hiermee verder?

Groeperen

Als eerste kun je vaak user stories op je backlog groeperen. Denk bijvoorbeeld aan samenhangende user stories die bij een bepaald onderdeel van je propositie horen. Zo zien we bij de platformen die wij ontwikkelen vaak een app voor de eindgebruikers en een apart dashboard voor de beheerders. Dat groeperen kan je vrij eenvoudig doen door één of meerdere kolommen toe te voegen aan je spreadsheet. Daarin kan je dan -in dit voorbeeld- “app” of “dashboard” zetten en later op sorteren. Eenvoudigere proposities kunnen dit ook overslaan.

Prioriteren

Daarna moet je de user stories prioriteren. Hiervoor kan je ook weer een extra kolom toevoegen waarin je de prioriteit zet. Een getal is vaak het handigste, omdat je daarop makkelijk kan sorteren. Wat wij vaak doen is starten met een prioriteit tussen 0 en 1000 waarbij we stappen van 200 gebruiken o.b.v. het MoSCoW systeem:

  • 800 = Must have
  • 600 = Should have
  • 400 = Could have
  • 200 = Won’t have (this time)

Tip: Door deze grote stappen heb je later altijd nog voldoende ruimte om de prioriteiten verder te verfijnen.

Roadmap

Zodra je de backlog op volgorde van prioriteit hebt staan, dan kan je ook vaststellen wat de eerste minimale versie van je product zou kunnen worden. Dit doe je door een grens te trekken bij een bepaalde prioriteit. Alles boven die grens kan dan onderdeel worden van de eerste versie van je product of dienst. 

Zo kan je ook extra grenzen trekken in je backlog, waardoor je een planning kan maken voor meerdere toekomstige versies. Het geplande versienummer zet je dan in een extra kolom, zodat je een beeld krijgt welke user stories wanneer ontwikkeld moeten worden. De tijdlijn met meerdere versies noemen we ook wel een roadmap.

Aan de slag met je ontwikkelplan

De resultaten van alle bovenstaande stappen vormen samen je ontwikkelplan. Dat wil niet zeggen dat je plan dan niet meer verandert, want een product of dienst moet je blijven onderhouden en verbeteren. Op basis van bijvoorbeeld nieuwe inzichten, feedback van gebruikers of eigen ideeën kan je je ontwikkelplan verder verfijnen, aanpassen en uitbreiden. 

Als ontwikkelplan voldoende compleet is, dan kunnen mensen zoals ik je helpen met een inschatting van de benodigde tijd en kosten. Daarnaast is de backlog de input voor ontwikkelaars bij het bouwen van een prototype of de eerste versie van je product.

”To me, ideas are worth nothing unless executed. They are just a multiplier. Execution is worth millions.” - Steve Jobs

Dus pak dat idee op je bierviltje en ga ermee aan de slag!

Wil je meer weten over conceptontwikkeling? Lees dan verder in onze gerelateerde artikelen:


(Header-afbeelding van mnm.all via Unsplash, Post-its foto van Kelly Sikkema via Unsplash)