Hva koster det å videreutvikle et digitalt produkt?
Videreutvikling etter lansering koster typisk 20–40 prosent av den opprinnelige utviklingskostnaden per år. Et produkt som ble bygget for 1,9 millioner kr, trenger altså et årsbudsjett på omtrent 370 000–750 000 kr til ny funksjonalitet. Budsjettet kan organiseres som et kontinuerlig team eller som bestillingsdrevet utvikling, og valget styres av endringstakten.
Etter lansering deler økonomien i produktet seg i tre budsjetter: drift (at det kjører), forvaltning (at det fortsetter å fungere) og videreutvikling (at det blir bedre). Denne siden handler om det tredje, det som avgjør om produktet er mer verdt neste år enn i år.
Tommelfingerregelen: 20–40 prosent av utviklingskostnaden per år
En nyttig planleggingsregel er at aktiv videreutvikling koster 20–40 prosent av den opprinnelige utviklingskostnaden per år. Et produkt som ble bygget for 1,9 millioner kr, trenger altså omtrent 370 000–750 000 kr i året for å utvikles i et fornuftig tempo.
Hvor i spennet dere bør ligge, styres av tre ting:
- Konkurransepress. Et kundevendt produkt i et marked i bevegelse krever mer, et stabilt internt verktøy mindre.
- Fase. Det første året etter lansering ligger de fleste høyt. Da samles alt som ble nedprioritert, pluss lærdommene fra faktisk bruk.
- Ambisjon. Skal produktet bare henge med, eller er det et konkurransevåpen som skal dra fra?
Hva regnes som videreutvikling?
Nye funksjoner, forbedret brukerflyt, nye integrasjoner, støtte for flere plattformer og større designarbeid: alt som gjør produktet mer verdt enn da det ble lansert. Hold det atskilt fra forvaltningen, som holder produktet i fungerende stand og typisk koster 15–25 prosent av utviklingskostnaden per år, og fra driften, som dekker servere og lisenser.
Tre budsjetter, tre ulike beslutninger: Driften er obligatorisk, forvaltningen nødvendig og videreutviklingen en investering som må begrunnes med effekten. Blandes de sammen, spiser det akutte alltid opp det viktige.
To måter å organisere budsjettet på
| Modell | Slik fungerer den | Passer når |
|---|---|---|
| Kontinuerlig team | Fast utviklingskapasitet hver måned som jobber mot en prioritert backlog | Høy endringstakt og et produkt som er sentralt for forretningen |
| Bestillingsdrevet | Behov samles og bestilles som pakker med tilbud per initiativ | Lav eller ujevn endringstakt med tydelig avgrensede behov |
Det kontinuerlige teamet gir fart og opparbeidet produktkunnskap uten oppstartstid når noe skal bygges, men krever at dere fyller det med prioritert innhold hver måned. Den bestillingsdrevne modellen gir kontroll per krone, men hvert initiativ må betale for at leverandøren setter seg inn i produktet på nytt, og kunnskapen om produktet går tapt mellom rundene.
En vanlig mellomløsning er en mindre fast kapasitet som holder tempoet oppe, supplert med større initiativer som prises i egne tilbud. Uansett hvilken modell dere velger, bør avtalen si hvor raskt kapasiteten kan skaleres opp og ned slik at budsjettet følger virksomheten og ikke omvendt.
Prioriteringen som får budsjettet til å strekke til
Budsjetter for videreutvikling sløses sjelden bort på dyre timer. De sløses bort på feil ting. Med en enkel prosess kommer dere langt:
- Samle alle ønsker på ett sted, fra brukere, support, selgere og ledelse.
- Anslå effekt og innsats grovt. Høy, middels og lav er nok. Krev at effekten knyttes til noe målbart.
- Bygg høy effekt og lav innsats først. Det høres selvsagt ut og gjøres overraskende sjelden.
- Vurder på nytt hvert kvartal i stedet for å låse en årsplan. Virkeligheten rekker å endre seg.
- Mål etterpå. Ble effekten reell? Svaret skjerper beslutningene neste kvartal.
Og våg å si nei. Hver funksjon som bygges, skal også forvaltes: Et ja i dag er en løpende kostnad i morgen. Nye ønsker underveis i kvartalet kan gjerne tas inn, men da må noe annet ut. Et budsjett uten den regelen vokser i det stille til noen oppdager det i årsoppgjøret.
Regneeksempel: årsbudsjett for en bookingapp
En bookingapp som ble bygget for 1,5 millioner kr, får året etter lansering et videreutviklingsbudsjett på 30 prosent: 450 000 kr, omtrent 37 000 kr i måneden i fast kapasitet. Første kvartal går til det som har vært mest etterspurt siden lanseringen: forbedret betalingsflyt og påminnelser. Andre kvartal bygges integrasjonen mot kassesystemet som hadde ventet på dokumentert etterspørsel. Ny utforming av forsiden, med høy innsats og uklar effekt, må vente til målingene gjør den berettiget. Slik holder et begrenset budsjett produktet på offensiven.
Hos Weapp jobber vi helst nettopp med prioritert videreutvikling styrt av målinger. Det er der et produkt tjener inn utviklingskostnaden sin. Vil dere diskutere hva som er riktig nivå for dere? Ta kontakt.
Ofte stilte spørsmål
Hva er forskjellen på forvaltning og videreutvikling?
Forvaltning holder produktet i fungerende stand: feilretting, sikkerhetsoppdateringer og support. Videreutvikling tilfører ny verdi: funksjoner, forbedret brukerflyt og nye integrasjoner. De bør budsjetteres og avtales hver for seg, ellers spiser det akutte alltid opp det viktige.
Hvor stort bør budsjettet være det første året etter lansering?
Ofte i den øvre delen av spennet på 20–40 prosent av utviklingskostnaden. Det første året samles alt som ble nedprioritert før lansering, pluss lærdommene fra virkelige brukere. Det er normalt årets mest verdifulle utviklingsbudsjett, ikke et nederlag.
Kan man sette videreutviklingen på pause for å spare penger?
Ja, i motsetning til forvaltningen er videreutvikling frivillig. Et stabilt internt produkt kan ligge i ro uten dramatikk. For konkurranseutsatte produkter er prisen i stedet at dere sakker akterut på funksjonalitet og opplevelse. Gjør pausen til en bevisst beslutning med en dato for ny vurdering, ikke til noe som skjer av glemsomhet.
Hvordan avgjør jeg om en funksjon er verdt å bygge?
Anslå forventet effekt mot antatt innsats, og knytt effekten til noe målbart: flere salg, færre supporthenvendelser, spart saksbehandlingstid. Bygg den minste versjonen som kan bevise verdien før dere bygger hele visjonen. Og husk at alt som bygges, også skal forvaltes.
Hvem bør prioritere hva som bygges?
Noen hos dere med mandat og nærhet til forretningen, ofte i rollen som produkteier. Leverandøren kan fasilitere prosessen og bidra med anslag over innsats, men prioriteringen er en forretningsbeslutning. Uten tydelig eierskap styrer den som roper høyest.