Business canvas og MVDP
Emneknagger: #dataprodukter, #data product canvas, #MVDP, #Minimum Viable Data Product, #dataprodukteier
Fra 'bra idé' til noe folk 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)
Kunde 360 – Core er et type A-produkt (master- og referansedata) fra typologien i forrige kapittel: identitet og referanser som må være konsistente på tvers av domener, med stabil semantikk og kontrollert endring som kjernekrav.
| 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 – eller minimum levedyktig dataprodukt – 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 har bestemt at dette skal være et dataprodukt (kunder + team + eierskap).
Start med bruk, ikke skjema
Tre spørsmål dere bør ha svar på før dere skriver en eneste linje:
- 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)
| Krav | Hva som må være på plass |
|---|---|
| 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. Vurder datakontrakt når avhengighetene er mange eller risikoen høy. |
| D Grunnkvalitet som sjekkes | 3–5 valideringer som betyr noe for bruken. 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. Teamet har beslutningsrett på forretningslogikken produktet implementerer. |
Hva dere bevisst kan utsette
Utsett dette med god samvittighet:
- full semantisk modell for hele virksomheten
- “perfekt” metadata på alt
- full observability-stack
- mange kvalitetstester “for sikkerhets skyld”
- flere konsumflater samtidig
Når MVDP er godkjent og kunder er på plass, er neste spørsmål hvem som skal ha tilgang og hva de skal betale i kognitiv kostnad for å bruke det: Verdi: hvorfor dette er verdt bryet.
