Validering af dine ideer og antagelser
Dette er den femte del af vores Illustrated Guide to Product Development-serie.
Igennem denne serie har vi udvidet en produktidé til et forretningskoncept, begyndelsen på en Go-to-Market Plan og udviklet personas til at svare til alle disse dele. Vi har også advaret gentagne gange om, at den største risiko, en virksomhed, et nyt produkt eller en service har, er at lave noget, ingen ønsker.
I denne artikel skal vi dissekere nogle få antagelser, vi har lavet, hvordan de påvirker vores arbejde, og hvordan vi kan teste dem. Mange af aspekterne af vores forretningsplan kræver, at den tidligere antagelse er sand, men hvis den tidligere antagelse pludselig er forkert, kan og bør store dele af det fremtidige arbejde springes over.
For at gøre dette, vil du måske lige ved at komme i gang gennemgå "Elevator Pitch", mens vi diskuterer vores løsning til Social Local Mobile Food Alerts, kærligt kaldet SoLoMoFoo.
Lad os gå tilbage til et par nøglescener fra vores storyboard om SoLoMoFoo. I dette storyboard ser vi Baking Bridget glad bringe cupcakes med på arbejde, advare sine kolleger, og Hangry Henry nyde en snack. For at gøre det endnu tydeligere har jeg ommærket storyboardet med antagelserne.
Ved en tilfældighed er størrelsen af antagelserne i orden, men det er typisk, at hver celle i fortællingen er afhængig af en tidligere antagelse.
Fornuft tjekker vores første antagelse
Folk vil lave mad og vil give det væk gratis på arbejdet.
Hvordan kan vi teste, om Baking Bridgets og Bobs er ægte?
For at SoLoMoFoo kan være nyttigt, skal det give en sund frekvens af advarsler om gratis mad og nok gratis mad med hver advarsel om, at brugere skal finde en snack, hvis de vil have en, og ikke en af hundredvis af mennesker, der dukker op til cupcake rester. Ved at engagere vores crack-team af analytikere kan vi bestemme et optimalt forhold mellem frekvens: mad: brugere: lykke.
Nu hvor vi har en fin og kompliceret formel for afkast på bagte cupcakes, kan vi sende en undersøgelse til 100 gennemsnitlige kontormedarbejdere og spørge dem:
- Hvor mange gange om året bringer du gratis mad ind?
- Hvor mange portioner er der i gennemsnit?
Med disse data og vores formel kan vi få en fornemmelse af, om der virkelig er nok bagebridgetter og bober.
Hvad hvis undersøgelsen giver data, vi ikke kan lide?
Det bedste scenarie er, at din hurtige test siger, at du er 100 % korrekt. Dette er sjældent og usædvanligt i dit første forsøg, så det kan være en god ide at dobbelttjekke!
På den anden side bør du være begejstret, hvis undersøgelsen siger, at dine antagelser er forkerte! På dette tidspunkt har vi investeret tiden i at lave et storyboard, tænke på vores storyboard, snakke om vores storyboard og tiden til at lave og sende en undersøgelse. Hvis vi finder ud af, at vores idé ikke virker, har vi stadig tid til at ændre vores idé, før vi løber tør for tid og penge!
Tænk på, hvor dyrt det ville have været at bygge hele denne platform, blot for at finde ud af, at udbudssiden ikke virker!
Efter at have taget et par dybe vejrtrækninger for at samle os selv, er det nu tid til at begynde at tænke på et andet scenarie, hvor produktet stadig kunne fungere. Vi har bemærket på vores eget kontor, at mens Baking Bridget kan dukke op en gang i kvartalet, er der to gange om ugen et frokostmøde med forplejning, og frokostmøde Larry bestiller altid et par ekstra måltider for at dække kostpræferencer og begrænsninger. Sandt at sige, så spilder jeg muligvis nogle rester på mit tastatur, mens jeg skriver dette...
At sætte det sammen
Dette storyboard viser de første tre antagelser på listen, en empirisk test til at validere eller afvise hypotesen og en potentiel ændring af vores storyboard, hvis vi har brug for at iterere.
Gennem vores storyboards fyldte vi bevidst vores eksempler med masser af ubeviste hypoteser, da vi tror på vores forretning og på din, kommer vi konstant med store påstande og antagelser, som vi bliver nødt til at teste og gentage på.
Andre store antagelser, vi gjorde
-
Der er endda et ønske om dette produkt frem for blot at efterlade gratis mad i køkkenet, hvilket ser ud til at fungere godt nok ...
-
HR ville være målkunden til faktisk at betale for dette
-
IT vil med sikkerhedshensyn være villig til faktisk at implementere applikationen og derefter have tid til at gøre dette
-
Ledelsen ønsker, at medarbejderne bruger mere tid på at spise cupcakes og mindre tid på at lave TPS-rapporter
-
Hvilke andre store antagelser så du her?
Grave dybere med minimum levedygtige produkter
At identificere, teste og gentage dine produktantagelser er en af de vigtigste dele af produktudviklingen. Meget få forretningsideer eller antagelser er korrekte, og det er kun ved metodisk at teste, lære og forbedre, at du vil være i stand til at skabe produkter i verdensklasse.
Min absolutte yndlingsbog om dette emne er Lean Startup af Eric Ries, som jeg genlæser jævnligt. Han har taget dette koncept med utrolig stram feedback og testsløjfer og parret dem med løsningen med at lave et Minimum Viable Product (MVP). En MVP er den billigste enklest mulige løsning/prototype til at se, hvordan rigtige kunder reagerer på dine ideer, og det muliggør kraftfuld læring til en brøkdel af prisen.
Efter år med mine egne produktudviklingserfaringer fandt jeg filosofierne om MVP'er og Agile Development gentaget af det, jeg havde set igen og igen, men ikke havde terminologien eller et 10.000 fods synspunkt til at forklare. Da jeg, Aaron Sherman, skabte Storyboard That, var mit mål fra dag ét at give produktudviklere mulighed for at
-
Kunne sætte sig ned og udtrykke deres produktideer på en mere naturlig, fortællende måde
-
Gør det nemt at dele ideer (tænk på, hvor enkle og klare eksemplerne har været)
-
Få reel feedback fra interessenter og potentielle kunder
-
Dette er MVP.
Ved at parre dette med alle de øvelser, vi har lavet, har vi nu værktøjerne og viden til at tænke som en kunde, skabe simple prototyper og få feedback for at sikre, at du ikke er en del af de 90 % af startups, der fejler, 42 % fra bygge et produkt, ingen ønskede ( Forbes ).
Nu er det din tur!
Nu hvor du har oprettet en stor portefølje af storyboards, kunderejsekort, personas og alle dine andre aktiver, så brug lidt tid på at lede efter dine store antagelser. Tænk over, hvad du skal bevise for at vide, om dine antagelser er sande, og hvad du kan gøre for at teste dem.
Når du er begyndt at udarbejde en liste, skal du bruge skabelonen nedenfor til at dokumentere dine resultater og derefter gå i gang med den sjove proces med at bevise og modbevise dine hypoteser. Jeg opfordrer dig kraftigt til at bruge mindst en time og skrive dine tanker ned; det gør det meget nemmere over tid at verificere, at du virkelig lærer og forhindre revisionistiske antagelser!
Storyboard That 's Illustrated Guide til produktudvikling
Om Aaron Sherman
Aaron Sherman ( @AaronBenSherman ) er den administrerende direktør og Skaberen af Storyboard That (www.storyboardthat.com) - den prisbelønnede, verdens førende inden for digital storytelling teknologi. Aaron grundlagt Storyboard That i 2012 efter 10 år arbejdet for alle typer af produktudvikling roller (Udvikler, projektleder, Product Owner, og Long Term strateg) på tværs af tre kontinenter (Nordamerika, Europa og Australien) til grundlæggende at forbedre, hvordan produkter blev internt prototype og diskuteret.
Aron har talt som en gæst lektor til MBA-studerende på Northeastern, og med Generalforsamlingens førende workshops om produktudvikling.
© 2024 - Clever Prototypes, LLC - Alle rettigheder forbeholdes.
StoryboardThat er et varemærke tilhørende Clever Prototypes , LLC og registreret i US Patent and Trademark Office