Effektiv produktutvikling: Lag det folk vil kjøpe!

Jeg opplever en rastløshet blant kunder jeg møter som vil lage et nytt produkt. I get it! Jeg er en utålmodig person sjøl, og vil gjerne bare lage greiene og ikke bruke så mye tid på prosess og metode.

Men selv om du synes ideen du har er god, betyr ikke det at folk vil kjøpe produktet ditt! For å unngå å lage produkter ingen vil ha bør du ta deg tid til å lære om behovet og validere at produktet har livets rett før du bruker masse penger på utvikling. Det kalles på start-up-språket å oppnå “Problem - Solution Fit”, et sterkt undervurdert stadie i produktutviklingen.

Hvis du ikke har dette på plass vil du aldri oppnå entreprenørens hellige gral: “Product - Market Fit”, som i bunn og grunn er å lage et produkt mange vil bruke og betale for. (Og ja, først etter det igjen kan du skalere og bli rik 😉 )

Jeg mener ikke at du skal bruke månedsvis på innsikt og brukerundersøkelser. Tvert imot! Du må teste akkurat nok til å ha en indikasjon på at det du driver med er smart! Så handler det jo om å få ut en enkel versjon av produktet, så du får testet det i markedet.

Så hva er den enkleste måten å få validert eller falsifisert om folk vil bruke og kjøpe produktet ditt? Her kommer et forslag på hvordan du gjør det, med minst mulig prosess og metode. Her er det sunn fornuft basert på min og andres erfaring med produktutvikling, krydra med verktøy som funker bra for å huske hva du lærer underveis, og for å være tydelig på hva du vil oppnå.

1. Lytt til folk i målgruppa di før du lager noe!

Du bør starte med å lære hva som er viktig for kundene dine (det er essensielt for å lykkes!), og du burde du snakke med dem så kjapt som mulig. Gjerne før du har laga en eneste skisse. Du må finne ut om behovet, og problemet, faktisk eksisterer der ute, som du har en idé til løsning på. Det tar ikke lang tid! Kast deg ut i det, så er hele dette steget gjort på et par dager.

Hva er lurt å ha på plass før du snakker med dem?

Hypotese av hva behovet er og hvem som har behovet. Skriv den ned, så alle er enige om hva hypotesen er. For eksempel:

• Hva tenker/føler kunden?
• Hva tror vi problemet er?
• Hva tror vi løsningen burde være?

(Det finnes gode tips i boken “The Entrepreneur's Guide to Customer Development” av Brant Cooper og Patrick Vlaskovits.)

Liste over folk du vil snakke med, som er potensielle kunder av produktet eller tjenesten din. Alternativt kan du finne det beste stedet for å møte folk fra målgruppa di. Planlegg når du skal dra dit og hvor mange du skal snakke med.

Intervjuguide basert på hypotesen din. Vær minst mulig ledende i spørsmålsformuleringene. Lytt til hva de sier, ikke putt ord i munnen på dem. Husk at du skal lære fra dem, ikke selge inn løsningen din! Skriv ned ord og formuleringer de bruker.

Et annet tips her er å stille spørsmål om hva de har gjort, og ikke hva de ville gjort hvis de sto overfor en hypotetisk situasjon eller i fremtiden.

Eksempel på dårlig spørsmålsformulering:
“Hvor mange ganger tenker du å jogge denne måneden?”

Litt bedre, men fortsatt ikke bra nok formulert:
“Hvor mange ganger i uka jogger du?”

En bedre spørsmålsformulering vil være:
“Hvor mange ganger har du jogget den siste måneden?”

Du bør også gjøre en enkel undersøkelse av hva som finnes i markedet allerede som ligner det du tenker å lage. Ta med et spørsmål om dette når du snakker med folk, da finner du enkelt hvem som er de ekte konkurrentene dine.

Innsikten du får i disse samtalene kan oppsummeres for eksempel i et Value Proposition Canvas.

Jeg har også god erfaring med å benytte et mulighetstre (Opportunity Solution Tree) for å matche innsikt med hypoteser og for å få god oversikt over alle fremtidige hypoteser du kan jobbe med. Innsikten du får gjennom disse samtalene er gull verdt, og viktig å ta vare på videre. Det er nøkkelen til å vinne over konkurrerende tilbydere.

2. Når du vet det finnes et behov, finn beste og enkleste løsning for å dekke behovet!

Det finnes ikke bare én måte å løse et problem på! Det finnes en million! Eller i alle fall veldig mange. Når du vet hva behovet og problemet til kundene dine er, bør du utforske mulige måter å løse det på. Ikke hopp på den første idéen du kommer på. På den måten er du mer sikker på å velge den beste måten å løse problemet på.

Når du utforsker måter å løse problemet på, bør du gjøre det i et team med folk som er ulike deg selv. Jeg tror at jo mer tverrfaglig og mangfoldig teamet ditt er, jo flere ulike løsninger på problemet dukker opp. Og flere løsninger er bra(!), selv om det ikke er den løsningen du kanskje tenkte på da du starta arbeidet.

Når du har generert en skokk løsningsforslag, bør du vurdere dem opp mot noen kriterier du har satt i forkant. Kriteriene bør være noe sånt som:

1. investeringskostnad for å realisere løsningen
2. potensiell gevinst

Altså for å finne hvilke av idéene som gir mest verdi for kundene deres for den laveste kostnaden for dere. Et kriterie kan også være hvor mye kompetanse dere har på den type løsning fra før. Hvis det for eksempel krever å ansette et helt utviklerteam med ny teknologikompetanse, bør det tas med i beregningene allerede her.

Når du har tatt et valg på hvilken av løsningene du tror mest på, må du snakke med folk i målgruppen din igjen.

Det du bør ha på plass for å snakke med dem denne gangen er ikke veldig ulikt fra det du hadde sist. Men i denne runden bør du bli mer konkret på hva produktet skal være og gjøre:

Oppdatert hypotese av hva behovet er og hvem som har behovet. Basert på samtalene du har hatt med potensielle kunder allerede har du nå en hypotese som er validert. Du vet hva som er viktig for kundene dine, men du vet ikke hvordan du fikser det.

Enkel skisse eller beskrivelse av løsningen din. Noe som gjør det lett å validere eller falsifisere om du er på rett vei eller ikke.

En ny liste over folk du har lyst til å snakke med eller planlegge sted der du skal stå å huke tak i folk nå for å se på skissene dine.

Intervjuguide basert på hypotesen din og skissen du vil teste. Vær minst mulig ledende i spørsmålsformuleringene. Si ting som “hva ville du gjort her?”, ikke “hva synes du om denne?”. Observer hva de gjør uten å lede de på rett vei.

3. Definér produktet og test om folk vil kjøpe det

Når du har gått noen runder med #1 og #2 og endt opp med å få validert en løsning som dekker et reelt problem har du oppnådd det som kalles “Problem -Solution Fit”. Nå er det klart for å begynne å bygge greiene. På dette stadiet har noen allerede laget en POC (Proof Of Concept) mens andre bare har en enkel mockup eller prototype av produktet eller tjenesten. Det avhenger av hva du lager. Men det er uansett lurt å lage minst mulig hele tiden før man har validert hva som faktisk skal til for å løse problemet til kundene og om de er villige til å kjøpe det.

Hva er lurt å ha på plass før du lager en pilot?

Definér forretningsmodell. Ikke en forretningsplan, men en enkel businesscase. Denne kan du sparke i gang ved å holde en Business Model Canvas-workshop. Produktutvikling er jo ikke så annerledes enn god gammeldags forretningsutvikling, så ikke vær redd for å bruke metoder du allerede kjenner godt til: SWOT, Vrio, Five Forces etc er også smarte verktøy for å finne ut om dette produktet har livets rett. Men ikke bruk for mye tid på modeller og skrivebordsundersøkelser! Det er viktigere å lære av de du håper at blir kundene dine.

Deretter kan du skrive ut et kort dokument (maks tre A4-sider, helst mindre) som kan inneholde noe sånt som:

• Forretningskontekst, knyttet til selskapsstrategi
• Beskrivelse av problemet
• Beskrivelse av løsningen av problemet
• Forretningsmulighetene
• Antatte fordeler ved å gjøre dette
• Informasjon om markedet og målgruppen
• Produktvisjon og strategi
• Risikoanalyse og antagelser
• Veikart for produktet

Dette dokumentet kan brukes som underlag for å skaffe budsjett til utviklingen hvis du trenger det. For eksempel hvis du skal presentere ideen for investorer, styret eller andre. Her er flere tips for å skaffe penger til produktutviklingen. En annen fordel med dette er at alle i teamet vet hva som gjelder.

Test betalingsvillighet! For å ha grundig brukerinnsikt bør du bruke både kvalitativ og kvantitative metoder. Testene og intervjuene jeg har beskrevet til nå er kvalitative og dekker et fåtall mennesker. På dette stadiet kan det være lurt å introdusere en kvantitativ test. Dette kan gjøres med en såkalt “fake door test”. Her kan du se hvordan vi gjorde dette for Folio.

Grunnen til at jeg anbefaler å kjøre en sånn test før du lager en fullverdig pilot, er at brukere ofte sier noe men gjør noe helt annet når de står overfor valget om å faktisk kjøpe produktet ditt (Nudgelab skriver om dette her). I en test som dette får du målt hvor mange som faktisk tok valget om å kjøpe produktet ditt, og hvor mange som ikke gjorde det.

4. Lag en pilot

Nå veit du hva du skal lage og at folk sannsynligvis er villige til å betale for produktet ditt! Da er du klar til å lage en pilot eller MVP (Minimum Viable Product, altså en levedyktig minimumsvariant av løsningen). Da er det på tide å få opp en liste over funksjonalitet, en såkalt backlog. Poenget med denne lista er å kunne notere ned all funksjonalitet du og andre interessenter ønsker og drømmer om (mer om backlog).

Det viktigste du gjør nå, er å prioritere hardt. Hvor lite funksjonalitet kan du ha på plass for å gi verdi til kundene dine? Hva er det aller minste du kan lage for å lære hva som funker? Jo før du får ut piloten jo bedre! Melissa Perry, forfatter av boka “Escaping the build trap“ har gode råd på hvordan du kan prioritere riktig og unngå å havne i en situasjon mange av oss kjenner altfor godt. At vi vil ha for mange features inkludert i produktet og ender opp med å bruke altfor lang tid på å få produktet ut i markedet og lager masse greier som ikke gir reell verdi for kundene våre. For mange features kan ofte ødelegge brukeropplevelsen og gjøre produktet mindre attraktivt enn det hadde vært med mindre funksjonalitet.

Du kommer uansett til å jobbe masse med å forbedre og legge til funksjonalitet etter den første lanseringa. I første omgang må fokus være på å få løsninga ut i verden, og begynne å måle hva som funker og ikke. Det er jo først da du virkelig ser om produktet flyr. For å komme i gang med å lage produktet kan det funke å kickstarte teamet med en sprint.

Når det kommer til å strukturere opp utviklingsprosessen for digitale produkter har jeg etter å ha jobba med produkt- og prosjektledelse i over 15 år blitt ganske pragmatisk. Jeg er ikke fan av å slavisk følge en av de klassiske metodikkene (Scrum, Kanban, Agile, Lean or what not), men å jobbe etter sunn fornuft:

• Alltid ha prioritert en liste over funksjonalitet.
• Ha en overordnet plan over hva du skal få til i kommende periode.
• Plukk et lite sett av de viktigste oppgavene basert på hva som gir brukerne verdi. Jobb i en uke eller to med de. Brukerteste, ferdigstille, produksjonsette.
• Gjør det igjen og igjen til det du oppnår det du anser som nødvendig for å gå live med piloten.
• Lansér pilot og lær av tilbakemeldingene.

5. Lær og gjør produktet ditt bedre

Når du har fått lansert en pilot kan du begynne å måle brukeradferden på ekte. Hurra! 🎉 Nå får du sett om folk faktisk kjøper og bruker produktet ditt. Nå er det superviktig at du observerer brukeradferden og se om du får validert forventningene. Det aller minste du kan gjøre her, er å ha definert noen måleparametre (KPIer - Key Performance Indicator) i forkant som du nå ser hvordan det går med.

Gode KPI-er er:

• Spesifikke og tidsbundet.
• Aggressive, men realistiske.
• Målbare og etterprøvbare.

Hvis noe ikke går veien, må du prøve å finne ut hvorfor. Du kan finne ut mye av å studere analyseverktøyet for nettsiden og søkeloggen (hvis produktet ditt er digitalt). Hvis det er vanskelig å tolke hva som skjer vil jeg anbefale å kombinere statistikk med kvalitative metoder igjen. Altså faktisk snakke med folk og brukerteste løsningen.

Jeg synes i tillegg at OKR-metoden (Objectives and Key Results) er et fint overbygg for et produktteam for at det skal være tydelig for alle involverte hvor produktet er på vei, og hva som er det viktigste fokusområdene fremover. Dette er en fleksibel måte å tenke strategi på, som gjør deg tilpasningsdyktig i markedet og fokusert.

Etterhvert som du lærer hva som funker og ikke, justerer du løsningen din til responsen du får. På denne måten vet du at det du utvikler er det markedet vil ha. Hvis du jobber med brukerinnsikt hele veien når du legger til funksjonalitet, risikerer du ikke å bruke masse penger på å lage feil ting. Og ja: I praksis er det vanskeligere enn det høres ut som 😉 Ofte har organisasjonen, sjefen, samarbeidspartnere eller andre interessenter mange tanker om hva du bør lage og når det må være ferdig. Din jobb bør være å argumentere for å jobbe kundeorientert. Verdien av å gjøre det er nemlig effektiv produktutvikling der du lager det folk faktisk ender opp med kjøpe!

Bruk mindre tid på prosess og mer på riktige folk

Helt til slutt - det finnes enorme mengder av prosesser og metoder for produktutvikling. Hvilke du velger å bruke er ikke så viktig. Jeg er enig med Marty Cagan, forfatter av boka Inspired, som mener at ledere bør bruke mindre tid på prosess og metodikk og mer tid på å ansette riktige folk og bygge en kultur for produktutvikling.

Cagan sier at det ideelle er når team får jobbe autonomt og tverrfaglig mot det de tror vil gi mest effekt, og samtidig har folk rundt seg som investerer tiden sin i å støtte og videreutvikle dem gjennom veiledning. Da vil nemlig produktteamet selv finne de beste verktøyene og prosessene for å lage et bra produkt, og i samme slengen gradvis bygge en kultur for moderne produkt- og tjenesteutvikling.