Gjør AI teamet ditt til en funksjonsfabrikk?

Teamet ditt leverer mer enn for to år siden. Øker inntektene også?

Siden AI-kodeverktøyene tok av, er forespørselen vi hører oftest fra kunder en variant av «Kan dere legge til <sett inn 5 nye tilfeldige funksjoner>?» Vi kan bygge dem raskere enn noen gang, men de fleste vil ikke flytte et eneste tall, fordi ingen sjekket om brukerne faktisk ville ha dem først.

Hver dag rapporterer GitHub stadig flere pull requests, men som du kan forestille deg, blir de fleste av dem aldri merget eller ser aldri dagens lys i produksjon. Det gapet har et navn: AI-produktivitetsparadokset.

AI endrer også hvor raske folk føler seg. I en randomisert studie fra METR brukte erfarne utviklere som jobbet i kodebaser de allerede kjente, omtrent 19 % lengre tid på å fullføre oppgaver med AI-verktøy. De trodde likevel at de var raskere.

Som tallene over viser, ble god programvare sjelden holdt tilbake av skrivehastighet. Den trege og krevende delen har alltid vært å bestemme hva som skal bygges – hva som skal tiltrekke flere kunder og få de eksisterende til å bli lenger.

Så når det blir så billig å bygge, blir det også billig å bygge feil ting. Slik ender team opp med å drive en funksjonsfabrikk.

Funksjonsfabrikk (subst.) – kritisk betegnelse på et produkt- og utviklingsteam som måler suksessen sin etter hvor mange funksjoner det leverer (output), i stedet for den faktiske verdien eller problemet som løses for brukerne (outcome)

Når utviklingen går så raskt, er det lett å gå seg vill i retromøter og i lister med funksjonsideer som dukket opp for noen mens de lagde middag eller var på treningssenteret. Kreativitet er ikke problemet. En kunde uten kreativitet ville aldri ha bygget et produkt i utgangspunktet – problemene starter når ideer bygges på optimisme i stedet for data.

Husker du da AI-API-ene først kom? Plutselig var neste funksjon i hvert eneste produkt «AI». Det fantes ingen klar grunn til hvorfor produktet trengte AI, hvilke data det kunne bruke for å skape noe verdifullt, hva det ville koste eller hvordan det skulle passe inn i kundens arbeidsflyt … Jeg kunne fortsatt, men du skjønner poenget.

Det var annerledes før. Når en kompleks funksjon betydde én til to måneders venting, tok kundene seg tid: De tenkte gjennom tilnærmingen, sjekket antagelsene sine mot ekte brukerdata og bestemte først da om funksjonen var verdt innsatsen.

AI fjernet den ventetiden, og «tenkingen» forsvant sammen med den. Det som er igjen, er lav bruk av nye funksjoner – og for kunden betyr det penger brukt på utvikling og null kroner tilbake.

AI har gjort det raskere å bygge for oss også: AI-agenter koder nye funksjoner → ingeniørene våre gjennomgår dem. Dermed går mindre av tiden deres til å skrive kode, og mer til arkitektur, avveininger, kodegjennomganger og produktbeslutninger. Mesteparten av tiden vi sparer, går til prioritering av funksjoner: å avgjøre hva som er verdt å bygge før vi begynner å skrive kode.

Slik fungerer det i et kundeprosjekt:

1. En produktleder utfordrer briefen. Hvert prosjekt ledes av en produktleder som forstår kundens forretning. Når en liste med fem nye funksjoner havner på bordet vårt, er det første spørsmålet hvilket kundeproblem hver av dem løser, og om den flytter produktet dit det bør være om to år.
2. Vi ser på dataene produktet allerede har. Før vi planlegger noe nytt, sjekker vi hvordan folk bruker dagens funksjoner: hvilke de kommer tilbake til, hvilke de ignorerer, og hvor de faller fra.
3. Hver funksjon får en tydelig spesifikasjon. Vi skriver strukturerte spesifikasjoner som beskriver hva funksjonen gjør, hvem den er for, og hvordan vi vet at den fungerte. Det er ofte når dette skrives ned at en svak idé faller gjennom – og det er langt billigere enn å oppdage det etter lansering.
4. Vi lager prototyper før vi bygger. Vi designer funksjoner i Figma og bruker AI til å gjøre dem om til klikkbare prototyper, som vi deretter bruker til å vise ideen til kunden – og helst til noen av kundens egne kunder.
5. Vi leverer i sprinter og sjekker resultatene. Arbeidet leveres i sprinter. Hvis vi ser at en funksjon ikke treffer brukerne, oppdager vi det tidlig og justerer neste sprint i stedet for å stable flere funksjoner oppå.

Det er med denne arbeidsflyten vi tok Reggy fra idé til en MVP som sikret finansieringen deres, og videre til en plattform som landet de første kundene.

Utviklingsteam kan nå bruke AI til å levere mer, og det kommer ikke til å endre seg – men mer utvikling ≠ flere kunder. Teamene som får reell verdi ut av AI, bruker tiden de sparer på å se på bruksdata, snakke med kundene sine og si nei til de fleste ideene på listen.

Så neste gang «Kan dere legge til disse fem funksjonene?» dukker opp, start med et spørsmål: hvilke av dem kommer brukerne dine faktisk til å bruke?

Hvis backloggen din bare vokser mens nye funksjoner ikke gir deg flere kunder, møt teamet bak prosessen vår og diskuter ideen din med oss.