Interne produkter har kunderInternal products have customers
Programvare bygget for ansatte bør styres etter de samme produktprinsippene som programvare solgt til eksterne kunder. De interne brukerne er produktets kunder: saksbehandlere, økonomi, kundeservice, HR eller ledere. De har konkrete problemer som skal løses, alternativer som Excel, e-post og manuelle arbeidsprosesser, og de vil bare ta løsningen i bruk dersom den skaper reell verdi.Software built for employees should be governed by the same product principles as software sold to external customers. The internal users are the product's customers: case handlers, finance, customer service, HR or managers. They have concrete problems to solve, alternatives such as Excel, email and manual processes, and they will only adopt the solution if it creates real value.
Et internt produkt er derfor ikke vellykket fordi det er levert. Det er vellykket når medarbeiderne velger å bruke det som sin naturlige arbeidsflate.An internal product is therefore not successful because it has been delivered. It is successful when employees choose it as their natural way of working.
Prosjekttankegang versus produkttankegangProject mindset versus product mindset
| Prosjekttankegang | Produkttankegang |
|---|---|
| Suksess = levert i tide | Suksess = adoptert og i aktiv bruk |
| Måler leveranser (output) | Måler effekter (outcome) |
| Krav spesifiseres én gang | Brukerbehov utforskes kontinuerlig |
| Teamet avslutter etter leveranse | Teamet forbedrer produktet kontinuerlig |
| «Vi leverte det som ble bestilt.» | «Løste vi faktisk brukernes problem?» |
| Project mindset | Product mindset |
|---|---|
| Success = delivered on time | Success = adopted and in active use |
| Measures deliveries (output) | Measures effects (outcome) |
| Requirements specified once | User needs explored continuously |
| Team disbands after delivery | Team improves the product continuously |
| "We delivered what was requested." | "Did we actually solve the users' problem?" |
Eksempel: digital risikostyringsplattformExample: digital risk management platform
En virksomhet ønsker å erstatte Excel-baserte risikoregistre med en digital risikostyringsplattform.A company wants to replace Excel-based risk registers with a digital risk management platform.
ProsjekttankegangProject thinking
Prosjektet leveres til avtalt tid og budsjett. Alle planlagte funksjoner er implementert, og brukerne har fått opplæring. Tre måneder senere vedlikeholder de fleste ledere fortsatt egne Excel-ark. Risikogjennomganger forberedes utenfor systemet, ledergruppen mottar PowerPoint-presentasjoner i stedet for levende dashboards, og plattformen inneholder utdatert informasjon. Prosjektet ble levert som planlagt. Forretningen fikk likevel liten gevinst.The project is delivered on time and on budget. All planned features are implemented, and users have been trained. Three months later most managers still maintain their own spreadsheets. Risk reviews are prepared outside the system, the executive team receives PowerPoint presentations instead of live dashboards, and the platform contains outdated information. The project was delivered as planned. The business still gained little.
ProdukttankegangProduct thinking
Produktteamet behandler ledere og risikoeiere som kunder og måler faktisk verdiskaping:
- Aktiv bruk: Hvor stor andel av risikoeierne oppdaterer risikoene sine hver måned?
- Dekning: Hvor mange forretningsområder bruker plattformen som sitt primære risikoregister?
- Effektivitet: Hvor mye tid spares i den kvartalsvise risikorapporteringen?
- Beslutningskvalitet: Benytter ledermøtene levende data direkte fra plattformen?
Gjennom intervjuer oppdager teamet at oppdatering av en risiko krever for mange klikk. Arbeidsflyten forenkles, påminnelser legges til, og løsningen integreres med Microsoft Teams. Seks måneder senere bruker 90 % av risikoeierne plattformen aktivt. Manuell rapportering er redusert med 70 %, lederdashboardene henter data direkte fra systemet, og de parallelle Excel-arkene forsvinner gradvis fordi de ikke lenger gir merverdi.
The product team treats managers and risk owners as customers and measures actual value creation:
- Active use: What share of risk owners update their risks each month?
- Coverage: How many business units use the platform as their primary risk register?
- Efficiency: How much time is saved in the quarterly risk reporting?
- Decision quality: Do leadership meetings use live data directly from the platform?
Through interviews the team discovers that updating a risk takes too many clicks. The workflow is simplified, reminders are added, and the solution is integrated with Microsoft Teams. Six months later, 90% of risk owners use the platform actively. Manual reporting is reduced by 70%, executive dashboards draw data directly from the system, and the parallel spreadsheets gradually disappear because they no longer add value.
Product Vanguard behandler interne produkter som en egen produkttype på samme porteføljetavle som kommersielle produkter. Begge konkurrerer om kapasitet, men vurderes etter hver sin verdilogikk. Kommersielle produkter styres primært av markeds- og inntektssignaler. Interne produkter styres av adopsjon, bruk, effektivisering og risikoreduksjon. Begge må dokumentere verdi gjennom objektive signaler før de får videre investering. Den strategiske kapasitetsallokeringen beskytter samtidig interne produkter mot å bli systematisk nedprioritert av kortsiktige inntektsinitiativer.Product Vanguard treats internal products as a distinct product type on the same portfolio board as commercial products. Both compete for capacity, but each is judged by its own value logic. Commercial products are governed primarily by market and revenue signals. Internal products are governed by adoption, usage, efficiency gains and risk reduction. Both must document value through objective signals before receiving further investment. At the same time, the strategic capacity allocation protects internal products from being systematically deprioritised by short-term revenue initiatives.
Et internt produkt må fortjene brukerne sine hver eneste dag. Det er ikke implementeringen som avgjør om produktet lykkes, men om ansatte velger å bruke det fordi det gjør arbeidet enklere, raskere eller bedre. Derfor måles suksess i adopsjon, engasjement og dokumenterte forretningsresultater, ikke i antall leverte funksjoner eller om prosjektet ble levert til avtalt tid.An internal product must earn its users every single day. It is not the implementation that determines whether the product succeeds, but whether employees choose to use it because it makes their work simpler, faster or better. Success is therefore measured in adoption, engagement and documented business results, not in the number of features delivered or whether the project was delivered on time.