Lean Startup-bevægelsen startede blandt andet, fordi startupper Eric Ries brugte lang tid på at bygge et produkt, som det viste sig ingen ville have. Det er han langt fra den eneste der har gjort, men hvordan undgår man den fælde? Kan man validere sin ide uden at bygge og launche hele produktet?
Scrum er en af de arbejdsmetoder som sikrer at vi får hurtig feedback på vores produkt. Det kræver dog en hel del abstraktionsevne at se en vertical slice blive præsenteret og så se om hele produktet er på vej i den rigtige retning. Scrum hjælper os med at få bygget tingene rigtigt, men ikke nødvendigvis at få bygget det rigtige.
Lean Startup omfatter blandt andet begreber såsom Minimum Viable Product (MVP), Split Testing og Learn-measure-build-cyklussen – alle brugt for at eliminere den usikkerhed, der er forbundet med at lave nye produkter. MVP passer rigtig godt ind i den agile udviklingstankegang – det er bare en definition af hvilke features du prioriterer til at starte med, nemlig det minimale produkt du kan sælge/bruge (frem for f.eks. den del af produktet som der er størst usikkerhed omkring, som nogle Scrum-folk foretrækker at starte med).
At bygge læring ind i sit produkt med f.eks. split testing er ikke noget Scrum omtaler direkte, men product owneren har selvfølgelig magt til at gøre det. Det kan være et af værktøjerne i PO’ens kasse med tricks – det er jo PO’en som skal sikre produktets succes.
Learn-Measure-Build-tankegangen er svær for mange. Du sætter en hypotese op om dit produkt. Du tester om hypotesen holder (altså uden at bygge hele produktet) og får dermed din ide/dit produkt valideret så billigt som muligt – Eric Ries kalder dette for the magic test. Et af de mest brugte eksempler på denne tankegang ført ud i livet er Zappos, som sælger sko. Inden de byggede hele forretningen op lavede de en simpel webshop uden at have leverandører og den slags på plads. Først når kunderne bestilte i denne webshop gik Zapposfolkene ned i en skobutik og købte ordren og sendte den til kunden. Den manuelle proces kaldes ofte at gøre brug af en “mechanical turk”.
Hos Google har de også haft fokus på denne type tankegang og det er der kommet et meget simpelt koncept ud af: Pretotyping. Pretotyping dækker i alt simpelhed over nogle metoder til at validere ideer hurtigt – f.eks. ved hjælp af “Mechanical Turk”-metoden. Andre metoder har de navngivet “Fake Door”, “Pinocchio”, “Impersonator”, “Minimum Viable Product” (MVP) og “One Night Stand”.
MVP har vi allerede snakket om, men jeg vil lige hurtigt løbe igennem de andre.
Fake Door
Fake Door går i simpelthed ud på at lade som om produktet allerede eksisterer. Lav en hjemmeside til det og forsøg så at sælge det – hvis en kunde forsøger at købe det, så giv en fejlbesked og kompenser evt. kunden for den dårlige oplevelse af ikke at kunne købe produktet. Med en statistik i hånden omkring hvor mange der gerne vil købe, har du et billede af din situation, når produktet er færdigt (hvis du altså ikke bliver overhalet af en konkurrent i byggeprocessen eller verden når at ændre sig). Hvis det ikke er et fuldt produkt, men bare en feature i et eksisterende produkt, så kan du f.eks. oprette et menupunkt/link til featuren og tælle hvor mange der forsøger at bruge den.
Pinocchio
Pinocchio-metoden har det navn fordi den handler om at lave en ikke-levende version af produktet – ligesom Pinocchio ikke var en rigtig dreng (Spoiler: men det blev han). Hvis det er et fysisk produkt, så lav en dummy først f.eks. af træ, som legenden siger at Palm Pilot-bagmanden Jeff Hawkings gjorde. Jeff tog træ-prototypen i lommen og hver gang der var en brugssituation, som produktet skulle kunne understøtte, tog han træ-prototypen op af lommen og gennemtænkte scenariet. Efter sigende gjorde han det i et par måneder før han kom med et bud på Palm Piloten.
Impersonator
Impersonator-metoden er gammel vin på nye flasker – altså sådan helt bogstaveligt. I den metode tager man et eksisterende produkt og giver det en ny indpakning for at teste om kunderne vil være mere interesseret i produktet i den indpakning. Eksemplet ofte givet er sodavand – i stedet for at udvikle en ny sodavand, så lav indpakningen dertil, hæld en eksisterende sodavand i og se om kunderne køber den (man kunne forestille sig at det var sådan Cola Zero var testet med Cola light på ny dåse). Kan naturligvis kun bruges, hvis dit nye produkt er en variant af et eksisterende produkt.
One-night-stand
One-night-stand-metoden minder om mechanical-turk-metoden. Sæt en engangoplevelse op, som fuldt ud giver oplevelsen af produktet, men uden at man har lavet den nødvendige infrastruktur til at kunne levere oplevelsen igen og igen. Altså vent med at takle skalerings-problemerne og sikr dig først at du får skaleringsproblemer.
MVP har jeg allerede nævnt, så det var de 6 metoder til at indsamle viden til at bygge det rigtige produkt. Pretotyping er interessant at kigge på for de fleste startups (og folk til Startup Weekend-arrangementer) og det kan være et anderledes værktøj til Scrum PO’er.
Hvis vi lige skal tage den sorte hat på et øjeblik, så vil den største risiko ved pretotyping nok være at give kunden en dårlig oplevelse. Fake door, MVP og Impersonator-metoderne er især i den kategori, mens problemet ikke vil være så stort med mechanical turk og one-night-stand (du leverer jo produktet fuldt ud denne ene gang) og Pinocchio (det er tydeligt at det er er en falsk udgave af produktet). Andre ulemper kan være at man ikke kan regne med resultatet af testene fordi man kan blive overhalet indenom af konkurrenter eller verden kan ændre sig mens man bygger produktet, men det er jo ikke anderledes end hvis man ikke havde lavet pretotyping – i det mindste har man en valideret ide.
Bruger I allerede pretotyping eller sidder I i en situation, hvor det ikke er brugbart? Er du skeptisk eller entusiastisk? Smid en kommentar og del dine erfaringer.
(Hvis du vil vide mere om pretotyping, kan du f.eks. starte med at se den forelæsning som Alberto Savoia holdt på Stanford i 2012)
[…] iværksættermiljøet er læring også det hotteste. Lean Startup og pretotyping sætter det på formel at man skal afprøve ting og fejle hurtigt, så man kan lære noget nyt. At […]