Proof-of-concept vs. Prototype vs. Minimum Viable Product

10 Apr 2019
Nikolas avatar
Nikolas Taillieu
Digital Product Manager

Inleiding

Proof-of-concept, prototype en Minimum Viable Product zijn veelgebruikte en -gehoorde termen voor iedereen die met zijn start-up of innovatieteam op weg is van idee naar een succesvol (digitaal) product.

Maar wat zijn dat nu precies? Wanneer gebruik je welke aanpak? In dit artikel gaan we dieper in op de definitie, gelijkenissen en verschillen tussen de drie. Benieuwd? In de conclusie van dit artikel vind je alvast een samenvatting!

Vanuit onze eigen ervaring zullen de hierna aangehaalde definities, tools en voorbeelden echter voornamelijk komen uit de wereld van web- en mobiele applicaties.

Proof-of-Concept vs. Prototype vs. Minimum Viable Product

Er zijn dus verschillen, maar laten we beginnen met wat ze met elkaar gemeen hebben: het zijn minimale of gedeeltelijke versies van een (digitaal) product, gebouwd om zo assumpties te proberen valideren over dat product en haar gebruikers. Test before you invest. Dankzij boeken als Lean Startup en Running Lean hebben ze aan populariteit gewonnen en worden ze voornamelijk door start-ups en innovatieteams gebruikt.

Het is geen of-of verhaal: elk van de aanpakken heeft een eigen toepassingsveld en welke aanpak het best bij jouw noden past, hangt af van wat je wil bereiken. Hoe je die beslissing maakt, ontdek je verderop, waar we elk van de aanpakken van dichterbij bekijken.

Proof-of-Concept

Een proof-of-concept (POC) bouwen is een manier om problem-solution fit te valideren vanuit de vraag: "kán ik het probleem van mijn (toekomstige) klant technisch oplossen?".

Een proof-of-concept is bedoeld om technische assumpties te testen, voor een klein deel van het uiteindelijk product, niet het gehele systeem.

Het is dus een eerder technische aangelegenheid, waarbij geen rekening gehouden wordt met de uiteindelijke user experience of user interface. Een proof-of-concept moet er dus ook niet goed uit zien en moet zelfs niet bugvrij zijn. Eindgebruikers zullen namelijk nooit met de proof-of-concept in aanraking komen.

Er is geen one-size-fits-all oplossing voor het bouwen van zo'n proof-of-concept. Je bouwt vanuit de vraag "kan deze technologie wat ik denk dat die kan?", dus is de aanpak voor elke technologie alle jobs-to-be-done anders.

Het resultaat varieert dan ook van een eenvoudige webpagina, al dan niet opgemaakt, gestuurd door complexe algoritmes, tot command line tools.

Digiplis Antwerpen - Circulair Zuid Proof-of-Concept
Voorbeeld van een proof-of-concept voor de werking van een blockchain-ecosysteem.
De proof-of-concept hierboven, een webapplicatie, simuleert 24 uur in het leven
van een burger die beloond worden met digitale munten als hij water bespaart.
De proof-of-concept bewijst dat dit mogelijk is met blockchaintechnologie.

Van zodra het duidelijk is dat je het probleem kán oplossen (of niet), heeft de proof-of-concept zijn nut bewezen. Je bent klaar voor de volgende stap en dan kan, nee moet, de proof-of-concept verwezen worden naar de prullenbak. Een POC is niet bedoeld om op verder te bouwen en mag ook niet zo gebouwd worden.

Prototype

Een prototype is eveneens een manier om problem-solution fit te valideren, maar dan meer vanuit de vraag "ben ik het probleem van mijn klant op de juiste manier aan het oplossen?".

Waar een proof-of-concept zich concentreert op één technisch deel van een oplossing, is een prototype bedoeld om de gehele oplossing te testen. Een prototype bouwen hoeft geen technische aangelegenheid te zijn: een écht werkend prototype is geen vereiste, het moet de werking van het product enkel goed kunnen simuleren. VHet prototype moet zelfs niet visueel aantrekkelijk zijn (design - user interface), maar moet wel werken zoals het finale product dat ook zou doen (functionaliteit - user experience).

Tools die vaak gebruikt worden voor het bouwen van een prototype voor web- en mobiele applicaties zijn Balsamiq, Sketch, Invision en Marvel. De ruimte ontbreekt om ze individueel toe te lichten, maar kort door de bocht zijn het wireframing tools die je toelaten de individuele web- of mobiele pagina's uit je product vorm te geven. De hoeveelheid detail beslis je zelf (low fidelity vs. high fidelity) . In een laatste stap worden de designs van de individuele pagina's aan elkaar gestitcht tot een interactief, klikbaar prototype.

epcon.ai - Prototype
Voorbeeld van een high-fidelity prototype voor epcon.ai, dat op zoek was naar een manier
om bij stakeholders te valideren hoe een goed dashboard voor het beheer van
anti-tuberculosemaatregelen er uit ziet. Het prototype is een klikbare,
maar niet-functionele versie van het mogelijke product.

Het resultaat is een prototype waar de gebruiker zich een een weg doorheen kan klikken, alsof het echt werkt. Zo krijgt jouw toekomstige klant een duidelijk beeld van hoe het uiteindelijke product zou werken. Als product owner krijg jij dan weer een exclusieve inkijk in hoe eindgebruikers met jouw product interageren. Aan de hand van die feedback, kan je jouw oplossing verder verfijnen.

Nadat een prototype zijn werk heeft gedaan, mag het verwezen worden naar de prullenbak. Wat niet wegneemt dat heel veel van het uitgevoerde werk hergebruik kan worden: bv. plaatsing van knoppen in de interface, de interactie tussen de verschillende pagina's van het product, ...

Minimum Viable Product

Een Minimum Viable Product (MVP) is bedoeld om product-market fit te valideren. Het is een volwaardig (!) product dat op zichzelf kan staan, voorzien van een gebruiksvriendelijk en visueel aantrekkelijke design, maar dat functioneel enkel de belangrijkste functionaliteit bevat.

Het is dus een soort light-versie van je product, waarbij je veel van de nice-to-have functionaliteit achterwege laat en focust op het aanbieden van een product dat met minimale functionaliteit toch het grootste probleem oplost van de klant die jij voor ogen hebt: de must-have functionaliteit.

De MVP is niet enkel een testversie van je product, het is een product dat effectief in de markt wordt gezet. Een MVP mag dus nooit een eerste stap zijn, maar wordt gebouwd op basis van een gevalideerde assumpties rond problem-solution fit. De core gedachte blijft dezelfde: zo weinig mogelijk investeren om zoveel mogelijk te weten te komen over je klanten en hun bereidwilligheid om je product te gebruiken én ervoor te betalen: je valideert met andere woorden de marktvraag naar jouw product.

Het moet gezien worden als een eerste versie van je product. Het moet functioneel werken, betrouwbaar zijn, gebruiksvriendelijk en -indien mogelijk- ook aantrekkelijk zijn. Samengevat: aan de hand van een minimaal product bewijs je de eindgebruiker de meerwaarde die jouw product voor hen kan bieden.

startups.be - Minimum Viable Product
Voorbeeld van een Minimum Viable Product, de in 2015 gelanceerde kaart van het Belgische
start-up ecosysteem door Datascouts en startups.be, die ondertussen al sterk evolueerde.
De digitale kaart toont in de MVP een eenvoudig overzicht van alle start-ups in België. Later werd
door Datascouts functionaliteit aan de kaart toegevoegd op basis van marktintelligentie.

Uit ervaring weten we dat het bepalen van de scope bij veel bedrijven een grote uitdaging is. Verlies de 'minimum' uit het oog en je riskeert waardevolle uren te investeren in een product dat niemand wil. Verlies de 'viable' uit het oog en je riskeert geen product te hebben, maar een zwart gat.

Doordat een MVP een eerste minimale versie van je product is, hoeft ze tegenstelling tot een proof-of-concept en prototype, niet weggegooid na de validatie van je hypothese. Het product kan in functionaliteit groeien op basis van de noden van de klant, maar vermijd dat je teveel tijd investeert in het over-engineeren van een product dat op een dag vervangen zal worden door een volwaardige en schaalbare versie van je product. Dan is het moment gekomen om van nul een product te bouwen dat de nu goed in te schatten hoeveelheid gebruikers aan kan.

Conclusie

Of je een proof-of-concept, prototype of Minimum Viable Product nodig hebt, hangt voornamelijk af van wat je wil bereiken:

  • een proof-of-concept valideert problem-solution fit voor een klein, strak afgelijnd deel van je digitale product. Enkel intern gebruik.
  • een prototype valideert problem-solution fit voor je gehele oplossing. Validatie gebeurt samen met eindgebruikers.
  • een Minimum Viable Product valideert product-market fit door een minimale versie van de gehele oplossing in de markt te zetten.

Deze uitleg is universeel geldig: voor zowel hardware- als softwaregebaseerde digitale producten.

Bij elk van de drie methodologieën is het belangrijk dat je op voorhand goed bepaalt welke assumpties je wil valideren. De scope van je proof-of-concept, prototype of Minimum Viable Product bepalen is van cruciaal belang. Besteed hier dus voldoende tijd aan, of laat je bijstaan door ervaren Product Owners zoals BallistiX. Is dat allemaal duidelijk, dan is het tijd om te gaan bouwen - met je eigen team van developers of een externe partner.

Hulp nodig? Bij BallistiX zijn we trots op onze lean digital products aanpak. Een aanpak die een lean startup mindsetcombineert met technologische expertise en daardoor uitermate geschikt is voor de definite en bouw van een proof-of-concept (POC), prototype en/of Minimum Viable Product (MVP).

Zin om aan de slag te gaan? Vraag hier een vrijblijvende, eerste gesprek aan! We zetten de koffie en thee alvast klaar.

Share
Let's stay in touch

Thank you!