- En guide til sikrere fiasko

1. Overlat produktledelsen til en teknolog

Hva kan gå feil når du lar en dyktig teknolog ta ansvaret for å styre produktutviklingen? Det korte svaret er “alt” og det nyanserte svaret er at du kan ha flaks. Det er lett å forstå hvorfor startups setter en dyktig CTO høyt på prioriteringslista. Møtet med teknologer er ofte vanskelig, vi føler oss prisgitt andres vurderinger uten kunnskap til å etterprøve valgene selv. Ja, det er betryggende å ha en flink CTO på laget, men din respekt for teknologi-folk gjør prosjektet sårbart og åpner for dype fallgruver.

Vi har en tendens til å overvurdere den teknologiske utfordringen og undervurdere viktigheten av riktige prioriteringer, brukerfokus, design, UX og store ører mot markedet. Du kan ha flaks og finne en genial CTO med alle disse egenskapene i en pakke. Slike finnes faktisk. Jeg har møtt to slike i min karriere, men det er større sjanse for at din CTO bare er en dyktig teknolog. Det betyr at produktledelse må eies av folk som er nærmest markedet, kundebehovet og forretningen. Det er kanskje deg? Alt for ofte ser vi at teknisk leder får for stor definisjonsmakt, og blir et filter mellom markedsforståelse og løsning.

2. Hent akkurat nok penger til å komme deg til lansering

Bootstrapping kan være sunt. Det tvinger dere til harde prioriteringer og holder helikopterutgiftene nede. Men det er ETTER lansering at lærekurven og den egentlige utviklingen starter. Planlegg for lanseringsfest ved whiteboarden og sørg for evne, midler og kapasitet til å reagere på innspillene og innsikten dere får fra de første brukere. Nå har du nemlig ekte brukere, og dersom forbedringene og endringene ikke skjer nå, mister du fart, lojalitet og muligheter raskere enn du rekker si “kriseemisjon”.

3. Vent med å lansere

Det er skummelt å lansere. Det er da drømmer og tusenvis av arbeidstimer møter den rå og ofte brutale virkeligheten. Dagene før lansering er gjerne tidspunktet for den plutselige innsikten om at produktet ditt bare MÅ ha denne lille, ekstra funksjonen for å fly. Det finnes gründere som ALDRI lanserer, men mest vanlig er utsettelser som aldri burde vært gjort. Har du gjort forarbeidet godt nok, (og det har du vel?) skal du lansere med det du har og gjøre endringene i etterkant.

4. Bygg for mye

Vår tommelfingerregel er 6 måneder fra oppstart til lansering. Det gir riktig grad av press og energi i prosjektet og sikrer deg mot å ta for mange gale valg og prioriteringer. Alle har hørt om konseptet MVP (minimum viable product), men nesten ingen er forberedt på hvor hardt det er å gjøre alle de tøffe valgene som må tas for å holde prosjektet lite nok, slik at du lansere akkurat nok til å løse behovet. 

Bygger du for mye, er det mye vanskeligere å forstå hvorfor brukerne ikke elsker tjenesten, det er mye mer som må endres og du risikerer å gå deg vill i endringer som egentlig ikke tar deg i riktig retning. 

5. Bygg for suksess

Du leste riktig! Du MÅ ikke automatisere ALLE prosesser fra dag en. Sjansen er stor for at du ikke har en million brukere fra lansering og du vil få tid til å lage helt riktige prosesser i takt med brukerveksten. De aller fleste gründere fnyser av tanken på å jukse litt på bakrommet, å gjøre manuelle prosesser for å lære og validere. Men slik gjorde Uber og en lang rekke av dagens digitale suksesser det. Fake it until it's validated!

6. Stol på deg selv

Du skal stole på deg selv, din egen intuisjon, ideer, innsikt og genialitet, men ikke før det er brukertestet og validert. Du er din egen minst verdifulle bruker og er fullstendig verdiløs som testbruker. Lær deg å elske brukere som ikke forstår et plukk av grensesnittet deres og lytt til surmagede tilbakemeldinger som om det er den vakreste poesi. Løsninger testes generelt for lite, på for få, med for få iterasjoner. Testing av design, UX, løsninger, prototyper, demonstratorer og ideer er billig, raskt og gir uendelig mye mer innsikt enn å ikke gjøre det.

7. Hold fast på roadmappen etter lansering

Det er bra med en plan for planer må man ha. Lag gjerne en plan for videreutvikling etter lansering, men gjør deg klar til å kaste den. Innsikten du får fra brukeradferd og tilbakemeldinger vil garantert snu opp ned på prioriteringene deres. Omfavn det og bruk energien på å løse ekte problemer. Planlegg for endring og gjør endring til noe naturlig og verdifullt for deg og teamet ditt.

8. Kjøp “billig” utvikling

Hvor skal jeg starte? Du får utvikling for 20 dollar timen om du gidder åpne noen spam-mail fra hyperaktive selgere. Men hva betyr det egentlig, når noen av disse folka kan gjøre skade for 1000-vis av dollar for hver time de får klatte på prosjektet ditt? Etter 10 år i bransjen har jeg ikke tall på gründere som har kommet til oss med tom pengesekk og teknisk havari. Få startups har tid eller penger til å bygge nytt, og vi har sett MYE crazy kode opp igjennom. Dette handler faktisk mindre om landet utviklingen har skjedd i, enn om fagmiljøet som er brukt. Gode utviklere har en tendens til å tiltrekkes av gode fagmiljøer, og i en global industri med sug etter dyktige ingeniører, kan “billig” raskt bli skikkelig dyrt. Husk at du ikke kjøper utviklingstimer, selv om det er det som står på fakturaen. Du kjøper virkeliggjøring av ideen din som en fungerende, levende tjeneste brukerne dine elsker.

9. Skaff et team som gjør det de får beskjed om

Det er deilig med ja-folk og lydighet, men det er ikke det du trenger. Du trenger et team som forstår forretningsideen din, som har satt seg inn i brukerbehovet, som kanskje til og med kan identifisere seg med brukergruppen din og, som en følge av alt dette, kan stille kritiske spørsmål og berike konseptet ditt med en uvurderlig sildring av små gullkorn. Selv har jeg alltid jaktet etter team som kan kna et godt utgangspunkt til det skinner, som kommer tilbake med en bedre løsning enn jeg hadde forestilt meg og stiller kritiske spørsmål ved alle sider av konseptet.

10. “Alt virker etter at kritisk masse er nådd”

Du MÅ ha en plan for hvordan du skal få de 50 første brukerne, hvordan de skal vokse til 500, 5000 og ja, du forstår…. ALT er lett når du har en million brukere, så du skal konsentrere deg om det som er skikkelig vanskelig; Brukervekst fra null, kundekonvertering, churn, brukerverdi og forretningsmodeller som liten.

Ta gjerne kontakt med oss for en uforpliktende prat:

Fra bloggen

Se alle nyheter
  • Bli kjent med vår nye venn Twingly

    I løpet av mai måned ble det inngått avtale med det spennende Linköping-selskapet Twingly om et samarbeid. Nå i juli har et av våre Ruby-team i Lviv kommet langt med å bygge løsningen for Twinglys nye Customer Dashboard.

  • – Fordi vi ikke lager bullshit

    Chris Klemmetvold Sandvik har tatt over som leder av Innocode fordi han tror på at vi ikke bare har idéer og god kode, men løser ekte problemer for ekte mennesker.