Smidig og forretningsutvikling i et livssyklusperspektiv

Vi som tilhører “smidigmiljøet” må nok innrømme at forretningsutvikling har blitt stemoderlig behandlet alt for lenge. Vi har riktignok hele tiden hatt fokus på kunden og brukerne, og at mye av poenget med smidig var å maksimalisere på kundeverdi. 

Mantra:

“Vi må bruke kreftene på det som betyr mest for brukerne – og det er feedbacken fra korte iterasjoner som gir oss kunnskap om dette”.

Dette er bra, men ikke nok. Vi hadde nok en naiv ide om at forretningsutvikling først og fremst skjedde i en tidlig fase i et produkts levetid – og at Produkteier sammen med “forretningssiden” tok seg av dette. Det var en stadig tilbakevendende frustrasjon om at vi ikke maktet å integrere forretning og utvikling på en god nok måte. Produkteiere i Scrum var ofte i villrede og maktet alt for sjelden å finne ut hva som faktisk betyr mest for brukerne.

LivssyklusEnkel

Vi manglet gode metoder for forretningsutvikling og det var derfor kjærkomment når Eric Ries publiserte boka Lean Startup i 2011. Boka fikk stor oppmerksomhet og jeg husker ennå “lyden av puslespillbrikken som falt på plass”. Dette var jo en svært iterativ prosess, laget for å identifisere kundebehov, beskrevet av en utvikler – som til og med var Certified Scrum Master! Mantraet i Scrum om å “feile så fort som mulig” stemmer veldig godt overens med iterasjonene til Eric Ries. Man hans perspektiv er selvsagt “tidlig fase” når man skal finne ut om selve produktideen (visjonen) er verd å investere penger i.

Fram til Lean Startup boka hadde jeg (og mange andre kursholdere) undervist i begrepet Minimal Marketable Feature (MMF) som en god tankegang for Scrum Product Owners: Lag det minst mulige produktinkrementet som brukerne kan tenkes å oppleve som verdifullt. Hvis de ikke liker det, kaster du inkrementet. Hvis de liker det, deploy og benytt anledningen til å finne ut hvilke utvidelser de trenger.

Eric Ries definerer Minimal Viable Product (MVP) i Lean Startup. Dette er omtrent det samme som en MMF, men Ries (som på Berkeley-Haas var elev av Steve Blank, mannen bak Customer Development) fokuserte begrepet mot initiell fase og mao til å omfatte helt uferdige prototyper og nærmest “skisser” som ofte kan være nok til å sette i gang en fruktbar samtale med brukerne. Dette er altså optimalisert på å finne ut mest mulig om kundebehov på en raskest og billigst mulig måte. Samtidig gjelder det å bruke all feedbacken man kan samle på denne måten til å overbevise investorer om at her bør vi legge inn penger og skalere opp en større satsning!

LivssyklusReell

Mange erfarer at man må utvikle en rekke MVPer før man (eventuelt) har en solid nok hypotese på hva man skal lage. Det kan med andre ord gå flere iterasjoner før man får finansiering til å sette i gang med utviklingsfasen. Men det er ingen grunn til å slutte med Lean Startup-tankegangen nå! Smidig (og Scrum) kan fremdeles profitere på denne tankegangen med MVPer. Det er fort gjort å glemme at vi fremdeles har kompleksitet og dynamikk og at både eksisterende og kommende kunder er uforutsigbare. Det er uansett lurt å betrakte produktinkrementer som en måte å validere (mer eller mindre sterke) hypoteser på. Og for ordens skyld; de små, blå MVP-ene i figuren kan godt gjøres av det samme teamet som bemanner utvikling og vedlikehold. Det er ikke noe problem å innlemme MVP-er i en vanlig Scrum Produktkø.

Når et produkt har vært i markedet en stund og vi er inne i “vedlikeholdsfasen”, vil vi ha mest fokus på å holde kundene fornøyde med minst mulig innsats – altså en slags “innhøstingsfase”. Men også her kan det fremdeles være fornuftig å teste ut hypoteser i form av MVPer – som potensielt kan føre til en ny vår for produktet i spesielle markeder.

Så vår konklusjon er at Lean Startup komplementerer smidig og Scrum på en etterlengtet måte. Men Lean Startup svarer heller ikke på alt. Hvordan jobber vi fram en god forretningsmodell?  Hvordan finner vi kundene? Hvordan sikrer vi at kundene ikke bare liker det vi lager, men også er villige til å betale en god pris? Det er faktisk mange eksempler på “vellykkede” produkter som mange kunder elsker, men som allikevel ikke skalerer godt nok og derfor aldri vil oppnå en positiv nåverdi.

Her kommer to andre konsepter inn i bildet. For det første kan vi bruke Alexander Osterwalders Business Model Canvas som på en utmerket måte støtter opp under diskusjonen om den best mulige forretningsmodellen. For det andre kan vi gå tilbake til Eric Ries sin læremester Steve Blank sin Customer Development modell. Felles for disse er at de er svært iterative og fokusert på rask læring. Og de kombinerer på en utmerket måte med smidig.

Benjamin Sommer forklarer hvordan Customer Development og Smidig sammen med Business Model Canvas utgjør en kraftig kombinasjon i en lyntale på Smidig2014.

 

Leave a Reply