Business canvas og MVDP
Emneknagger: #dataprodukter, #data product canvas, #MVDP, #Minimum Viable Data Product
Fra ‘bra idé’ til noe folk faktisk tør å bygge på.
Business canvas for et dataprodukt
Mange dataprodukt-initiativ feiler ikke på teknologi, men på uklarhet: uklare kunder, uklar verdi, uklart ansvar — og dermed uklare prioriteringer.
En kort business canvas tvinger fram det som ellers blir skjøvet på: hvorfor finnes dette, hvem bruker det, og hva koster det å holde det i drift?
Når er det verdt å bruke canvas?
Bruk canvas når minst én av disse er sant:
- flere team skal bygge på samme definisjoner
- dere bruker tid på avstemming (“hva betyr egentlig kunde/ordre/omsetning?”)
- endringer skaper bråk eller risiko
- run cost er reell, men verdien er uklar
Hvis ingen av dem er sant, er det ofte bedre å holde leveransen som komponent.
Data Product Business Canvas (eksempel: “Kunde 360 – Core”)
| Del | Innhold |
|---|---|
| Navn / kort beskrivelse | Kunde 360 – Core: stabil definisjon av “kunde” og nøkkel-attributter for analyse og rapportering |
| Problem / mulighet | Ulike kundedefinisjoner og join keys gir avvik mellom CRM, kundeservice og rapportering. Tid går til oppslag og avstemming. |
| Kunder (navngitte) | CRM-team, Kundeservice, Salgsanalyse |
| Bruk (én setning) | “Gi et konsistent, beslutningsklart bilde av kunde på tvers av flater.” |
| Verdihypotese | Redusere tid til kundeoppslag og avstemming, og øke tillit til kundetall og segmentering. |
| Målepunkter (1–3) | 1) Median tid fra oppslag til “beslutningsklart bilde”. 2) Antall avvik mellom CRM-tall og rapportert kundebestand. 3) Antall konsumentmiljøer (adopsjon). |
| Produktflate (offisiell) | analytics.customer_360_core (current state). Historikk: analytics.customer_360_history (SCD2). |
| Ikke-scope | Ikke realtime. Ikke operativ transaksjonslogikk. Ikke “alle kundebegreper” – kun definisjonen for analyse/rapportering. |
| Avhengigheter | Kilde for kundeidentitet, samtykkegrunnlag, referansedata, pipelines som produserer keys og status. |
| Risiko / compliance | PII, tilgangsstyring, logging/audit, endringer i kilder (ID-logikk). |
| Cost to serve | Compute/lagring + drift/varsling + support/forvaltning. Må eies, ellers blir løftet urealistisk. |
| Livsløp / neste 90 dager | Nå: definisjon + keys + grunnkvalitet. Neste: historikk + segmentregler. Senere: enriched attributter + bedre observability. |
Slik bruker dere canvasen uten at det blir papirarbeid
- Fyll den ut sammen med 1–2 kunderepresentanter (30–60 min).
- Bli enige om én produktflate og én verdihypotese.
- Avklar hvem som eier run cost-prioritering.
- Oppdater den når dere endrer løftet (ikke når dere refaktorerer motorrommet).
Minimum Viable Data Product (MVDP)
MVDP er det minste dere må ha på plass for at en kunde skal tørre å bruke produktet — og for at dere skal kunne stå i det over tid.
En vanlig feil er å gi MVDP-status til noe som egentlig bare er en komponent. MVDP gir først mening når dere faktisk har bestemt at dette skal være et dataprodukt (kunder + team + eierskap).
Start med bruk, ikke skjema
Det dere trenger først er én setning dere kan si høyt:
- Hvem er kunden?
- Hva prøver de å oppnå?
- Hva må være stabilt for at de skal tørre å bygge på det?
Definition of Done: MVDP (minimum som gir verdi)
A Definert bruk og verdi Én kundegruppe og én brukssituasjon i én setning, pluss en verdihypotese som kan etterprøves.
B Én tydelig produktflate Én anbefalt måte å konsumere produktet på (tabell/view/API/semantisk lag). Join keys og tidslogikk er forklart.
C Enkelt løfte om endring Hva dere leverer, hva dere ikke leverer, og hvordan større endringer varsles og håndteres (med en overgang).
D Grunnkvalitet som sjekkes 3–5 valideringer som betyr noe for bruken. Og hvis kvalitet feiler, skjer det noe (stopp/degrader/varsel).
E Tilgang uten friksjon Dokumentert tilgangsmønster og tydelig godkjenning.
F Synlig eierskap Eierteam og kontaktpunkt er synlig i katalog/README, og teamet har beslutningsrett på forretningslogikken produktet implementerer.
Hva dere bevisst kan utsette
Det er helt greit å utsette:
- full semantisk modell for hele virksomheten
- “perfekt” metadata på alt
- full observability-stack
- mange kvalitetstester “for sikkerhets skyld”
- flere konsumflater samtidig
