Uw ideeën en veronderstellingen valideren
Dit is het vijfde deel van onze serie Illustrated Guide to Product Development.
Doorheen deze reeks hebben we een productidee uitgebreid tot een bedrijfsconcept, het begin van een Go-to-Market-plan en persona's ontwikkeld die overeenkomen met al deze onderdelen. We hebben ook herhaaldelijk gewaarschuwd dat het grootste risico dat een bedrijf, nieuw product of dienst heeft, is iets maken wat niemand wil.
In dit artikel gaan we een paar aannames ontleden die we hebben gemaakt, hoe deze ons werk beïnvloeden en hoe we ze kunnen testen. Veel van de aspecten van ons bedrijfsplan vereisen dat de vorige aanname waar is, maar als de vorige aanname ineens onjuist is, kunnen en moeten grote delen van toekomstig werk worden overgeslagen.
Om dit te doen, wil je misschien net beginnen met het bekijken van The "Elevator Pitch" terwijl we onze oplossing voor sociale lokale mobiele voedselwaarschuwingen bespreken, liefkozend SoLoMoFoo genoemd.
Laten we teruggaan naar een paar belangrijke scènes uit ons storyboard over SoLoMoFoo. In dit storyboard zien we Baking Bridget vrolijk cupcakes naar het werk brengen, haar collega's waarschuwen, en Hangry Henry genieten van een snack. Om het nog duidelijker te maken, heb ik het storyboard opnieuw gelabeld met de aannames.
Toevallig is de omvang van de aannames in orde, maar het is typerend dat elke cel in het verhaal op een eerdere aanname vertrouwt.
Gezond verstand controleert onze eerste veronderstelling
Mensen gaan eten maken en willen het op het werk gratis weggeven.
Hoe kunnen we testen of Baking Bridgets en Bobs echt zijn?
Om SoLoMoFoo nuttig te laten zijn, moet het een gezonde frequentie van waarschuwingen voor gratis eten en voldoende gratis eten bieden bij elke waarschuwing dat gebruikers een snack moeten vinden als ze er een willen, en niet een van de honderden mensen die komen opdagen voor cupcake overblijfselen. Door ons team van analisten in te schakelen, kunnen we een optimale verhouding bepalen van frequentie : eten : gebruikers : geluk.
Nu we een mooie ingewikkelde formule hebben voor het rendement op gebakken cupcakes, kunnen we een enquête sturen naar 100 gemiddelde kantoormedewerkers en hen vragen:
- Hoe vaak per jaar breng je gratis eten binnen?
- Hoeveel porties zijn er gemiddeld?
Met deze gegevens en onze formule kunnen we aanvoelen of er echt genoeg Baking Bridgets and Bobs zijn.
Wat als de enquête gegevens geeft die we niet leuk vinden?
Het beste scenario is dat je snelle test zegt dat je 100% gelijk hebt. Dit is zeldzaam en ongebruikelijk bij je eerste poging, dus misschien wil je het nog een keer controleren!
Aan de andere kant zou je blij moeten zijn als uit de enquête blijkt dat je aannames niet kloppen! Op dit moment hebben we de tijd geïnvesteerd om een storyboard te maken, na te denken over ons storyboard, te praten over ons storyboard, en de tijd om een enquête te maken en te versturen. Als we ontdekken dat ons idee niet werkt, hebben we nog tijd om ons idee te veranderen voordat we geen tijd en geld meer hebben!
Bedenk hoe duur het zou zijn geweest om dit hele platform te bouwen, alleen om erachter te komen dat de aanbodzijde niet werkt!
Na een paar keer diep adem te hebben gehaald om tot onszelf te komen, is het nu tijd om een ander scenario te bedenken waarin het product nog steeds zou kunnen werken. In ons eigen kantoor hebben we gemerkt dat Baking Bridget misschien één keer per kwartaal verschijnt, maar twee keer per week een verzorgde lunchbijeenkomst en dat Lunchbijeenkomst Larry altijd een paar extra maaltijden bestelt om dieetvoorkeuren en beperkingen te dekken. Eerlijk gezegd mors ik misschien wat restjes op mijn toetsenbord terwijl ik dit schrijf ...
Samenvoegen
Dit storyboard toont de eerste drie genoemde aannames, een empirische test om de hypothese te valideren of te verwerpen, en een mogelijke wijziging van ons storyboard als we moeten herhalen.
In onze storyboards hebben we onze voorbeelden opzettelijk bezaaid met veel onbewezen hypothesen, omdat we in ons bedrijf en in dat van u geloven, doen we voortdurend grote beweringen en veronderstellingen die we moeten testen en herhalen.
Andere grote veronderstellingen die we hebben gemaakt
-
Er is zelfs een verlangen naar dit product in plaats van gewoon gratis voedsel in de keuken te laten staan, wat goed genoeg lijkt te werken ...
-
HR zou de beoogde klant zijn die hier daadwerkelijk voor betaalt
-
IT zou bereid zijn met beveiligingsproblemen om de applicatie daadwerkelijk te implementeren en dan de tijd te hebben om dit te doen
-
Het management wil dat medewerkers meer tijd besteden aan het eten van cupcakes en minder aan het maken van TPS-rapporten
-
Welke andere grote veronderstellingen zag je hier?
Dieper graven met minimaal levensvatbare producten
Het identificeren, testen en herhalen van uw productaannames is een van de belangrijkste onderdelen van productontwikkeling. Zeer weinig zakelijke ideeën of aannames zijn correct, en alleen door methodisch te testen, te leren en te verbeteren, kunt u producten van wereldklasse maken.
Mijn absoluut favoriete boek over dit onderwerp is Lean Startup van Eric Ries, dat ik regelmatig herlees. Hij heeft dit concept van ongelooflijk strakke feedback- en testloops genomen en deze gekoppeld aan de oplossing om een Minimum Viable Product (MVP) te maken. Een MVP is de goedkoopste, eenvoudigste mogelijke oplossing/prototype om te zien hoe echte klanten op uw ideeën reageren, en het maakt krachtige lessen mogelijk tegen een fractie van de kosten.
Na jaren van mijn eigen productontwikkelingservaringen merkte ik dat de filosofieën van MVP's en Agile Development echoden door wat ik keer op keer had gezien, maar ik had niet de terminologie of een gezichtspunt van 10.000 voet om uit te leggen. Toen ik, Aaron Sherman, Storyboard That, was mijn doel vanaf de eerste dag om productontwikkelaars in staat te stellen om
-
In staat zijn om te gaan zitten en hun productideeën op een meer natuurlijke, verhalende manier uit te drukken
-
Maak het eenvoudig om ideeën te delen (denk aan hoe eenvoudig en duidelijk de voorbeelden waren)
-
Krijg echte feedback van belanghebbenden en potentiële klanten
-
Dit is de MVP.
Door dit te combineren met alle oefeningen die we hebben gedaan, hebben we nu de tools en kennis om als een klant te denken, eenvoudige prototypes te maken en feedback te krijgen om ervoor te zorgen dat u geen deel uitmaakt van de 90% van startups die falen, 42% van een product bouwen dat niemand wilde ( Forbes ).
Nu is het uw beurt!
Nu je een groot portfolio van storyboards, customer journey maps, persona's en al je andere assets hebt gemaakt, moet je even de tijd nemen om naar je grote veronderstellingen te zoeken. Bedenk wat u zou moeten bewijzen om te weten of uw aannames waar zijn, en wat u kunt doen om ze te testen.
Nadat u bent begonnen met het samenstellen van een lijst, gebruikt u de onderstaande sjabloon om uw bevindingen te documenteren en begint u vervolgens aan het leuke proces van het bewijzen en weerleggen van uw hypothesen. Ik moedig je ten zeerste aan om minstens een uur de tijd te nemen en je gedachten op te schrijven; het maakt het na verloop van tijd veel gemakkelijker om te verifiëren dat u echt aan het leren bent en voorkomt het maken van revisionistische aannames!
Storyboard That 's Illustrated Guide to Product Development
Over Aaron Sherman
Aaron Sherman ( @AaronBenSherman ) is de CEO en de Schepper van Storyboard That (www.storyboardthat.com) - de bekroonde, wereldwijd marktleider in digital storytelling technologie. Aaron opgericht Storyboard That in 2012 na 10 jaar werken het volledige gamma van productontwikkeling rollen (ontwikkelaar, Project Manager, Product Owner, en Long Term Strategist) verspreid over drie continenten (Noord-Amerika, Europa en Australië) om fundamenteel te verbeteren hoe de producten intern werden prototype en besproken.
Aaron heeft gesproken als gastdocent aan MBA-studenten op Northeastern, en met de Algemene Vergadering van toonaangevende workshops over Product Development.
© 2024 - Clever Prototypes, LLC - Alle rechten voorbehouden.
StoryboardThat is een handelsmerk van Clever Prototypes , LLC , en geregistreerd bij het US Patent and Trademark Office