Business canvas and MVDP
Tags: #data products, #data product canvas, #MVDP, #Minimum Viable Data Product
From 'good idea' to something people actually dare to build on.
Business canvas for a data product
Many data product initiatives fail not on technology, but on ambiguity: unclear customers, unclear value, unclear responsibility — and therefore unclear priorities.
A brief business canvas forces out what otherwise gets postponed: why does this exist, who uses it, and what does it cost to keep it running?
When is it worth using a canvas?
Use a canvas when at least one of these is true:
- multiple teams will build on the same definitions
- you spend time on reconciliation (“what does customer/order/revenue actually mean?”)
- changes create disruption or risk
- run cost is real, but the value is unclear
If none of them is true, it is often better to keep the deliverable as a component.
Data Product Business Canvas (example: “Customer 360 – Core”)
| Section | Content |
|---|---|
| Name / short description | Customer 360 – Core: stable definition of “customer” and key attributes for analytics and reporting |
| Problem / opportunity | Different customer definitions and join keys cause discrepancies between CRM, customer service and reporting. Time is spent on lookups and reconciliation. |
| Customers (named) | CRM team, Customer Service, Sales Analytics |
| Use case (one sentence) | “Provide a consistent, decision-ready view of the customer across surfaces.” |
| Value hypothesis | Reduce time spent on customer lookups and reconciliation, and increase trust in customer figures and segmentation. |
| Metrics (1-3) | 1) Median time from lookup to “decision-ready view”. 2) Number of discrepancies between CRM figures and reported customer base. 3) Number of consumer environments (adoption). |
| Product surface (official) | analytics.customer_360_core (current state). History: analytics.customer_360_history (SCD2). |
| Out of scope | Not real-time. Not operational transaction logic. Not “all customer concepts” – only the definition for analytics/reporting. |
| Dependencies | Source for customer identity, consent foundation, reference data, pipelines that produce keys and status. |
| Risk / compliance | PII, access control, logging/audit, changes in sources (ID logic). |
| Cost to serve | Compute/storage + operations/alerting + support/governance. Must be owned, otherwise the promise becomes unrealistic. |
| Lifecycle / next 90 days | Now: definition + keys + baseline quality. Next: history + segmentation rules. Later: enriched attributes + better observability. |
How to use the canvas without it becoming paperwork
- Fill it out together with 1-2 customer representatives (30-60 min).
- Agree on one product surface and one value hypothesis.
- Clarify who owns run cost prioritisation.
- Update it when you change the promise (not when you refactor the engine room).
Minimum Viable Data Product (MVDP)
MVDP is the minimum you need to have in place for a customer to dare to use the product — and for you to be able to sustain it over time.
A common mistake is to give MVDP status to something that is really just a component. MVDP only makes sense when you have actually decided that this shall be a data product (customers + team + ownership).
Start with use, not schema
What you need first is one sentence you can say out loud:
- Who is the customer?
- What are they trying to achieve?
- What must be stable for them to dare to build on it?
Definition of Done: MVDP (minimum that delivers value)
A Defined use and value One customer group and one use case in one sentence, plus a value hypothesis that can be verified.
B One clear product surface One recommended way to consume the product (table/view/API/semantic layer). Join keys and time logic are explained.
C Simple promise about change What you deliver, what you do not deliver, and how major changes are communicated and handled (with a transition).
D Baseline quality that is checked 3-5 validations that matter for the use case. And if quality fails, something happens (stop/degrade/alert).
E Access without friction Documented access pattern and clear approval process.
F Visible ownership Owner team and contact point are visible in the catalogue/README, and the team has decision-making authority over the business logic the product implements.
What you can deliberately postpone
It is perfectly fine to postpone:
- full semantic model for the entire organisation
- “perfect” metadata on everything
- full observability stack
- many quality tests “just in case”
- multiple consumption surfaces simultaneously
