Allokering før rangeringAllocation before ranking
Bestem hvor mye kapasitet hver strategiske investeringskategori skal få før enkeltinitiativer rangeres. Initiativene konkurrerer deretter kun mot andre i samme kategori.Decide how much capacity each strategic investment category receives before ranking individual initiatives. Initiatives then compete only against others in the same category.
Hvorfor dette er viktigWhy this matters
Uten dette steget favoriserer prioritering naturlig initiativer med umiddelbar, synlig avkastning, typisk kundefunksjoner og inntektsmuligheter. Teknisk gjeld, plattformforbedringer, etterlevelse og utforskende innovasjon vinner sjelden, fordi gevinstene er langsiktige og vanskeligere å knytte direkte til inntekt.Without this step, prioritisation naturally favours initiatives with immediate, visible returns, typically customer features and revenue opportunities. Technical debt, platform improvements, compliance work and exploratory innovation rarely win, because their benefits are longer-term and less directly attributable to revenue.
EksempelExample
En utviklingsorganisasjon har kapasitet til 100 utviklerdager neste kvartal. Ledelsen blir først enige om fordelingen:A software organisation has capacity for 100 developer-days next quarter. Leadership first agrees on the allocation:
- 60 % produktutvikling → 60 utviklerdager60% product development → 60 developer-days
- 30 % drift og pålitelighet → 30 utviklerdager30% operations & reliability → 30 developer-days
- 10 % teknisk gjeld og plattform → 10 utviklerdager10% technical debt & platform → 10 developer-days
Nå konkurrerer initiativene kun innenfor sin kategori.Initiatives now compete only within their category.
| Produktutvikling (60 dager) | Prioritet |
|---|---|
| Kundeportal v2 | 1 |
| AI-søk | 2 |
| Mobilvarsler | 3 |
| Drift og pålitelighet (30 dager) | Prioritet |
|---|---|
| Forbedret overvåking | 1 |
| Redusert responstid ved hendelser | 2 |
| Test av katastrofegjenoppretting | 3 |
| Teknisk gjeld (10 dager) | Prioritet |
|---|---|
| Oppgradere database | 1 |
| Erstatte utdatert bibliotek | 2 |
| Refaktorere autentiseringsmodul | 3 |
Selv om ingen teknisk gjeld-sak har sterkere business case enn neste kundefunksjon, investeres de planlagte 10 prosentene likevel, fordi ledelsen allerede har besluttet at plattformhelse er strategisk viktig.
| Product development (60 days) | Priority |
|---|---|
| Customer Portal v2 | 1 |
| AI Search | 2 |
| Mobile Notifications | 3 |
| Operations & reliability (30 days) | Priority |
|---|---|
| Improve monitoring | 1 |
| Reduce incident response time | 2 |
| Disaster recovery testing | 3 |
| Technical debt (10 days) | Priority |
|---|---|
| Upgrade database | 1 |
| Replace obsolete library | 2 |
| Refactor authentication module | 3 |
Even if no technical debt initiative has a stronger business case than the next customer feature, the planned 10% is still invested, because leadership has already decided that platform health is strategically important.
Hva skjer uten allokering?What happens without allocation?
Med én samlet prioriteringsliste blir topp ti gjerne kundefunksjoner med inntektseffekt dette kvartalet. Teknisk gjeld utsettes, plattformforbedringer forsinkes, interne verktøy får ingen investering, og pålitelighetsarbeid skyves gang på gang. Det ser effektivt ut i noen kvartaler, men så bremser leveransen, hendelsene øker, og ingeniørene bruker mer tid på å reparere enn å bygge. Organisasjonen har ubevisst brukt morgendagens kapasitet på å maksimere dagens leveranse.With one combined priority list, the top ten become customer features with revenue impact this quarter. Technical debt is postponed, platform improvements delayed, internal tools receive no investment, and reliability work is repeatedly deferred. It looks efficient for a few quarters, but then delivery slows, incidents increase, and engineers spend more time fixing than building. The organisation has unintentionally consumed tomorrow's capacity to maximise today's output.
Et produktstyre beslutter at årlig utviklingskapasitet fordeles slik:
| Investeringsområde | Allokering |
|---|---|
| Kundeprodukter | 50 % |
| Interne produkter og plattformer | 20 % |
| Drift og pålitelighet | 20 % |
| Teknisk gjeld og modernisering | 10 % |
Når Product Vanguard rangerer initiativer, konkurrerer hvert initiativ innenfor sin allokering, og veikartet viser faktisk kapasitetsbruk mot mål per produkt («Over mål +7pp»). Ikke noe kortsiktig inntektspress kan eliminere investeringen i plattformhelse, fordi den allerede er beskyttet gjennom strategisk allokering, og avvik er synlige som en ledelsesbeslutning, ikke stille drift.
A product board decides that annual engineering capacity is allocated as follows:
| Investment area | Allocation |
|---|---|
| Customer products | 50% |
| Internal products & platforms | 20% |
| Operations & reliability | 20% |
| Technical debt & modernisation | 10% |
When Product Vanguard ranks initiatives, each competes within its allocation, and the roadmap shows actual capacity spend against target per product ("Over target +7pp"). No amount of short-term revenue pressure can eliminate the investment in platform health, because it is already protected through strategic allocation, and deviation is visible as a leadership decision, not silent drift.
Bestem hvor mye kapasitet hvert strategiske investeringsområde fortjener før enkeltinitiativer prioriteres, slik at hver kategori konkurrerer rettferdig innenfor sin egen ramme i stedet for å bli fortrengt av kortsiktige prioriteter.Decide how much capacity each strategic investment area deserves before prioritising individual initiatives, so every category competes fairly within its own allocation instead of being crowded out by short-term priorities.