Business canvas and MVDP
Tags: #data products, #data product canvas, #MVDP, #Minimum Viable Data Product, #data product owner
From 'good idea' to something people 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)
Customer 360 – Core is a Type A product (master and reference data) from the typology in the previous chapter: identity and references that must be consistent across domains, with stable semantics and controlled change as core requirements.
| 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 – or minimum viable data product – 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 decided that this shall be a data product (customers + team + ownership).
Start with use, not schema
Three questions you should have answers to before writing a single line:
- 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)
| Requirement | What must be in place |
|---|---|
| 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. Consider a data contract when dependencies are many or risk is high. |
| D Baseline quality that is checked | 3-5 validations that matter for the use case. 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. The team has decision-making authority over the business logic the product implements. |
What you can deliberately postpone
Postpone these with a clear conscience:
- full semantic model for the entire organisation
- “perfect” metadata on everything
- full observability stack
- many quality tests “just in case”
- multiple consumption surfaces simultaneously
When the MVDP is approved and customers are in place, the next question is who should have access and what cognitive cost they pay to use it: Value: why data products are worth the effort.
