Hvad koster det at videreudvikle et digitalt produkt?
Videreudvikling efter lancering koster typisk 20–40 procent af den oprindelige udviklingsudgift om året. Et produkt der er udviklet for 1,6 mio. DKK, har altså brug for et årligt budget på cirka 320.000–640.000 DKK til ny funktionalitet. Budgettet kan organiseres som et kontinuerligt team eller som bestillingsdrevet udvikling. Valget afhænger af forandringstakten.
Efter lanceringen deler produktets økonomi sig i tre budgetter: drift (at det kører), vedligeholdelse (at det bliver ved med at fungere) og videreudvikling (at det bliver bedre). Denne side handler om den tredje: den der afgør om produktet er mere værd næste år end i år.
Tommelfingerreglen: 20–40 procent af udviklingsudgiften om året
En brugbar planlægningsregel er at aktiv videreudvikling koster 20–40 procent af den oprindelige udviklingsudgift om året. Et produkt der er udviklet for 1,6 mio. DKK, har altså brug for 320.000–640.000 DKK om året for at blive udviklet i et rimeligt tempo.
Hvor i spændet I bør ligge, afhænger af tre ting:
- Konkurrencepres. Et kundevendt produkt på et marked i bevægelse kræver mere; et stabilt internt værktøj mindre.
- Fase. Det første år efter lanceringen ligger de fleste højt: Her samles alt det der blev nedprioriteret, plus erfaringerne fra reel brug.
- Ambition. Skal produktet bare følge med, eller er det et konkurrenceparameter der skal trække fra?
Hvad tæller som videreudvikling?
Nye funktioner, forbedrede flows, nye integrationer, understøttelse af flere platforme og større designopgaver: alt der gør produktet mere værd end da det blev lanceret. Hold det adskilt fra vedligeholdelsen, som holder produktet i funktionsdygtig stand og typisk koster 15–25 procent af udviklingsudgiften om året, og fra driften, som betaler servere og licenser.
Tre budgetter, tre forskellige beslutninger: Driften er obligatorisk, vedligeholdelsen nødvendig og videreudviklingen en investering der skal begrundes med sin effekt. Blandes de sammen, æder det akutte altid det vigtige.
To måder at organisere budgettet på
| Model | Sådan fungerer den | Passer når |
|---|---|---|
| Kontinuerligt team | Fast udviklingskapacitet hver måned der arbejder ud fra en prioriteret backlog | Høj forandringstakt og et produkt der er centralt for forretningen |
| Bestillingsdrevet | Behov samles og bestilles som pakker med tilbud pr. initiativ | Lav eller ujævn forandringstakt med klart afgrænsede behov |
Det kontinuerlige team giver fart og opbygget produktviden, uden opstartstid når noget skal bygges, men kræver at I fodrer det med prioriteret indhold hver måned. Den bestillingsdrevne model giver kontrol med hver udgift, men hvert initiativ betaler for at leverandøren skal sætte sig ind i opgaven, og viden om jeres produkt går tabt mellem gangene.
En almindelig mellemvej: en mindre fast kapacitet der holder tempoet oppe, suppleret med større initiativer der gives særskilt tilbud på. Uanset hvilken model I vælger: Skriv ind i aftalen hvor hurtigt kapaciteten kan skaleres op og ned så budgettet følger forretningen og ikke omvendt.
Prioriteringen der får budgettet til at række
Budgetter til videreudvikling bliver sjældent spildt på dyre timer. De bliver spildt på de forkerte ting. En enkel proces rækker langt:
- Saml alle ønsker ét sted, fra brugere, support, sælgere og ledelse.
- Vurder effekt og indsats groft: Høj, mellem og lav er nok. Kræv at effekten knyttes til noget målbart.
- Byg høj effekt og lav indsats først. Det lyder selvfølgeligt og gøres overraskende sjældent.
- Revurder hvert kvartal i stedet for at låse en årsplan. Virkeligheden når at ændre sig.
- Mål bagefter. Blev effekten reel? Svaret skærper næste kvartals beslutninger.
Og tør sige nej. Hver funktion der bygges, skal også vedligeholdes: Et ja i dag er en løbende udgift i morgen. Nye ønsker i løbet af kvartalet må gerne tages ind, men så ryger noget andet ud; et budget uden den regel vokser i det stille indtil nogen opdager det i årsregnskabet.
Regneeksempel: årsbudget for en bookingapp
En bookingapp udviklet for 1,3 mio. DKK får året efter lanceringen et budget til videreudvikling på 30 procent: 390.000 DKK, cirka 32.000 DKK om måneden i fast kapacitet. Første kvartal bruges på det mest efterspurgte fra lanceringen: et forbedret betalingsflow og påmindelser. I andet kvartal bygges integrationen med kassesystemet, som havde ventet på påvist efterspørgsel. Redesignet af forsiden, med høj indsats og uklar effekt, må vente til målingerne begrunder det. Sådan holder et begrænset budget produktet i offensiven.
Hos Weapp arbejder vi helst med netop prioriteret, målingsdrevet videreudvikling: Det er her et produkt tjener sin udviklingsudgift hjem. Vil du drøfte det rette niveau for jer? Kontakt os.
Ofte stillede spørgsmål
Hvad er forskellen på vedligeholdelse og videreudvikling?
Vedligeholdelse holder produktet i funktionsdygtig stand: fejlrettelse, sikkerhedsopdateringer og support. Videreudvikling tilfører ny værdi: funktioner, forbedrede flows, nye integrationer. De bør budgetteres og aftales hver for sig, ellers æder det akutte altid det vigtige.
Hvor stort bør budgettet være det første år efter lanceringen?
Ofte i den øvre del af spændet 20–40 procent af udviklingsudgiften. Det første år samler alt det der blev nedprioriteret før lanceringen, plus erfaringerne fra rigtige brugere. Det er normalt årets mest værdifulde udviklingsbudget og ikke en fiasko.
Kan man sætte videreudviklingen på pause for at spare penge?
Ja, til forskel fra vedligeholdelsen er videreudvikling frivillig. Et stabilt internt produkt kan hvile uden dramatik. For produkter i konkurrence er prisen i stedet at I sakker bagud på funktionalitet og oplevelse. Hold pause som en bevidst beslutning med en dato for revurdering, ikke af glemsomhed.
Hvordan afgør jeg om en funktion er værd at bygge?
Vurder den forventede effekt mod den anslåede indsats, og knyt effekten til noget målbart: flere lukkede salg, færre supporthenvendelser, sparet sagsbehandlingstid. Byg den mindste version der kan påvise værdien før I bygger hele visionen. Og husk at alt der bygges, også skal vedligeholdes.
Hvem bør prioritere hvad der bygges?
En hos jer med mandat og tæt på forretningen, ofte i rollen som product owner. Leverandøren kan facilitere processen og bidrage med estimater af indsatsen, men prioriteringen er en forretningsbeslutning. Uden et tydeligt ejerskab er det den der råber højest, der bestemmer.