The Data Product Canvas: Deep Dive into the Building Blocks

TLDR; The Data Product Canvas provides a structured approach to designing high-value, sustainable data products. This strategic tool brings stakeholders together to align business needs with technical capabilities before committing resources. This deep dive explores each of the nine building blocks, showing you how to complete them effectively to maximize your chances of success.

In Part 1 of the blog, we introduced the Data Product Canvas as a blueprint for success - a simple yet powerful tool that aims to bring stakeholders together to shape data products that deliver real value.

It does this by presenting 9 simple building blocks that will encourage you to think holistically about the data product.

• Audience - the specific groups of people that the data product is aiming to create value for.
• Actionable Insight - the data driven actionable intelligence that will be delivered by the data product to allow the audience to achieve a specific goal.
• Consumption - the means through which the audience will access and use the data product.
• Adoption - the support that will be given to the audience to enable them to successfully discover and use the data product.
• Lifetime Value - the value (tangible and intangible) that the data product is aiming to deliver over its lifetime.
• Data Sources - the data sources which are required to deliver the actionable insight.
• Data Processing - the actions that will need to be taken to transform data sources into the actionable insight.
• Data Skills, Tools and Methods - the key capabilities that will be required to deliver and sustain the data product over its lifetime.
• Total Cost of Ownership - the projected costs to design, build, test, operate, maintain and evolve the data product over its lifetime.

Here is the blank canvas:

If you would like an Adobe Acrobat version of the canvas, please reach out to us.

In this blog, we describe each of the blocks in more detail in the general order that we recommend you should complete the canvas. Providing reference material that we hope will help you to adopt the canvas successfully.

In which order should you complete the canvas?

We recommend starting with the centre of the model to capture the actionable insight. This ensures that you start with "Why?" and adopt a purpose driven approach to designing your data product.

Having captured the actionable insight, we then recommend you then focus on the right-hand-side of the canvas to reinforce the principle that successful products apply user-centred-designed through a deep understanding of a the audience who will use the product.

Once you have validated the fit between actionable insight and audience, you should then complete the left-hand-side of the model to test the feasibility by validating the data, processes and wider capabilities are in place to enable the actionable insight to be delivered.

This approach is illustrated below:

Note - the process of completing the canvas is seldom linear. You will tend to loop back and iterate on all parts of the canvas as you uncover new information and develop your understanding. So don't be constrained to the flow illustrated above!

Actionable Insight

Start with Why? by defining the actionable insight.

An actionable insight is a "quantum" of functionality. It should have a narrow focus based on:

• Goal - what goal is the audience seeking to achieve?
• Question - what question needs to be answered that will enable them to achieve this goal?
• Insight - what information is required to answer that question?
• Action - what action will the insight enable the audience to take that will contribute to the goal?

See some examples below:

Mapping out these elements will ensure the data product will:

• Deliver insights that can be acted upon
• Contribute directly to a goal of the organisation
• Be measurable in terms of value and impact

The clearer this understanding, the more likely the data product will succeed. It will help you to avoid "scope creep" and keep all stakeholders focused on the goal.

You will often need to do some detective work to uncover the goal and actionable insight. Users tend to communicate the "solution" rather than the "requirement", so be prepared to ask "Why?" a few times to get to the raw requirements, for example:

• End user: "We need a new stock dashboard."
• You: "Why do you need this report?"
• End user: "So we can see the level of stock we have for each product at each store."
• You: "Why do you need to understand stock levels at this level of detail?"
• End user: "We use this information to understand where stock levels are running low relative to anticipated demand." (the INSIGHT)
• You: "Why do you need to understand when stock levels are running low?"
• End user: "So we can proactively order stock from suppliers and prevent the shelves from going empty." (the ACTION)
• You: "Why is this important?"
• End user: "It is critical to maximising revenue and to keep our customers happy and returning to shop with us!" (the GOAL)

Other aspects of the actionable insight that you should also consider at this stage:

• Related data products - other data products that this actionable insight could leverage. This is typically an upstream data product which it can consume as an input.
• Service levels - define the service level objectives that need to achieved for the actionable insight to be trustworthy. Typically, this would include considerations such as:
  • Accuracy
  • Completeness
  • Availability
• Risks - the risks that you have identified that could manifest to prevent the actionable insight from being delivered in a sustainable and reliable way.

Audience

In this building block you identify the audience that is responsible for putting the data product into use to generate value.

Each action in the examples provided in the table above should be something the audience has the authority and capability to execute. For instance:

• Customer service managers can authorize overtime
• Procurement teams can order stock
• Account managers can intervene with at-risk clients

If the insight suggests actions that the audience can't take, it's not truly "actionable" for them. This connects back to understanding the audience's "key activities" - what they're actually empowered to do in their role.

A good product is founded on a deep understanding of end users and designing it with their needs in mind. The most successful products are loved by end users because they generate value for them by allowing them to overcome a specific "pain" or achieve some kind of "gain".

This building block encourages us to understand the end users, existing methods, how they will prefer to consume the data product to achieve a specific goal. Here we identify the "personas" who will consume the data product. By persona we mean a specific person (e.g. the Chief Financial Officer), role (e.g. Customer Service Agents) or demographic group (e.g. University Students).

For each persona we should explore:

• Responsibilities - what business outcomes are they responsible for and how is their success measured?
• Key Activities - what actions are they authorised to take in order to fulfil their responsibilities? What resources do they have control over in terms of budget, team etc.?
• Inhibitors - what gets in the way of them achieving their responsibilities? This could be information gaps, decision-making bottlenecks, compliance challenges and quality issues.

We should also consider factors that will have a direct impact on the design of the data product such as:

• Level of data literacy and technical skills when it comes to embracing the data product
• Existing tools that they use
• Time constraints
• Existing work patterns

By understanding your audience, you will ensure that the data product will:

• Deliver an insight the audience can actually act on
• Fit naturally with existing skills and workflow
• Overcome barriers to adoption

The clearer the understanding you build, the more likely the data product will achieve adoption and generate value.

Consumption

Define how the audience will access and consume the actionable insight:

• Nature of the actionable insight - in other words, the delivery mechanism or means through which the actionable insight is consumed: report, dashboard, alert, document, tabular data, data API, interactive model, knowledge graph etc.
• Device - the type of device they will access the actionable insight on. This can have significant implications for the data product. This could be a personal device, or some kind of downstream platform which is seeking to consume the data product.
• When? - how often will they actually need to consume the data product - hourly, daily, weekly, monthly? How up to date will the actionable insight need to be to be useful? How will they be notified when new insights are available or have been refreshed?
• Security & permissions - is concerned with authentication and authorization controls. How will users (or machines) authenticate? What information should they see / permissions should they have depending on their role?

Adoption

In this area of the canvas we consider how end users will find, gain access to and successfully adopt the data product:

• Discovery - explains how users find, learn about and access the data product. You should also consider established users will be notified when new features (versions) have been developed.
• Design - a topic that is often overlooked and can have a significant impact on the successful adoption of a data product. This is specific to the nature of the data product. Reports will be subject to design considerations such as visual impairments and branding, whilst APIs will be subject to design considerations such as design of API (GraphQL versus OpenAPI), availability of "try it out" web site and code samples.
• Documentation, Support & Training - describe the documentation, training and support will be available. You should also consider who should they turn to when they have a question or encounter an issue. Documentation should include information about data quality (data contract) and lineage.
• Feedback loop - describe how end users will provide feedback about their experience using the data product. Also consider how usage and adoption be measured over time.

Lifetime Value

Quantifies the business value that the data product will generate over its lifetime. The lifetime of a data product typically being at least 5 years.

Examples include tangible value such as:

• Revenue growth
• Cost savings
• Productivity

But also more intangible sources of value to the organisation such as:

• Risk reduction
• Strategic advantages
• Protecting brand / reputation
• Enhancing customer experience
• Employee satisfaction and retention

Tailoring the value drivers in this section to the goals of the organisation is a useful way of ensuring that data product ideas are tested against and aligned to the business strategy.

Data Sources

Identifies the specific data sources required to deliver the actionable insights. Here, you should consider:

• Nature of the data source - which will typically be:
  • Business application in the operational plane - an application that is used to run the business such as an ERP platform?
  • Service - is it an external service that the organisation has access to such as Bloomberg?
  • Master and reference data - is it some form of master / reference data that is typically required to augment and integrate operational data?
  • Another data product?
• Trust - what level of trust do you place in each data source? Data sources with a low level of trust should immediately be a red flag for any data product idea!
• Classification - how is the data classified? Is it information that is considered low value / low risk? Or is it high value and / or high risk in nature such as proprietary information about individuals that only your organisation has access to?
• Compliance - are there specific policies, regulations and laws that need to be applied? For example GDPR?
• Ownership of the data - does the organisation own the data or is it owned by an external party? If internal, which department owns it? Are they prepared to grant access?
• Data Characteristics - consider the general nature of the information for each (here we use the "5Vs" framework):
  • Volume - the amount of data and how it will grow over time.
  • Velocity - the speed at which data changes and needs to be processed.
  • Variety: the range of data types that need to be consumed - structured, unstructured and semi-structured.
  • Veracity: the quality and accuracy of the data.
  • Value: licenses required to use the data.

In all of the above, you are not looking for precise or detailed answers. It's a case of using your expertise to highlight the characteristics that will have a significant influence on the technical complexity, feasibility and overall TCO of the data product. The single page canvas, with limited space, will force you to keep it focused on the most important characteristics.

Data Processing

Defines the key activities that need to performed to transform the data sources into an actionable insight. This includes the following activities and considerations:

• Ingestion - how will data be ingested from source?
• Quality Assurance - does data need to be validated before it can be used? What "data contract" needs to be fulfilled to enable the data product to be viable?
• Processing - what processing is required? Cleaning, standardisation, integration, transformation, filtering?
• Projection - in what form should the data be presented for downstream consumption? For example, does it need to transformed into a single flat table, a star schema or a knowledge graph?
• Modelling - what form of analytics or modelling processes need to be applied to source data? For example, is data inference being applied to address gaps in data? Is a machine learning model being applied to cluster data or enable predictive analytics?
• Automation - what level of automation is required?
• Triggers - when / how often should the process run?

As above, the purpose here is not define the solution in detail but to highlight the major processes that need to be applied to deliver the data product. In future phases, if the data product is taken forward into implementation, more detailed analysis and design may decompose this data product idea down into a number of inter-linked data products (a data mesh). But for now, the key is to identify the major activities. Focus on highlighting activities that will require specific skills, methods and technology platforms to deliver.

Data Skills, Tools and Methods

Outlines the people, technologies and processes that to enable the data processing (defined above) and to sustain the data product. This will include:

• Expertise - knowledge, technical skills and other domain related skills required to build, own and operate the data product.
• Tools - the specific platforms, technologies, packages and libraries that will be required to support data processing.
• DataOps - platforms, tools and practices related to addressing the non-functionality requirements associated with the data product such as testing, observability and source control.
• Governance - which policies and principles are relevant to this data product? This is a significant topic in its own right, but it is important to highlight anything that is critical or unique in some way to this data product. Examples include:
  • Specific regulations that apply.
  • The classification of the data - for example is it highly sensitive personal information? This will fundamentally shape the design of the solution and inflate the TCO!
  • Considerations around data retention.
  • Business continuity and disaster recovery requirements.
• Standards - identify the specific standards that should be adopted by the data product, specifically to enable it to support key features of a data product:
  • Re-use by making it addressable and accessible
  • Inter-operability with other data products
  • Versioning
  • Publishing for discovery

As your organisational maturity develops, you should increasingly find that the skills, tools and methods identified will be well established and available as "re-usable IP" that is a native part of the data platform(s) on which you build and operate data products. Where a new skill, tool or method is required, this is likely to present additional cost and risk to the data product.

Total Cost of Ownership (TCO)

Captures all anticipated costs associated with the data product over its entire lifetime. In our experience, data products are likely to have a lifetime of at least 5 years and will incur a significant costs over this time. Some of this cost will be direct and tangible, other costs will be less tangible, but just as important to capture.

For a deeper dive into TCO, we recommend our series What is total cost of ownership and why is it important?

There are many data teams out there, weighed down by the effort required to sustain legacy data products that are not delivering sufficient value or displacing the bandwidth that could be used to build, own and operate high impact / impact data products. If they had used a tools such as the data product canvas, or retrospectively applied it to identify data products that should now be retired, they could be maximising their contribution to the organisation.

Total cost of ownership is a broad topic but should consider:

• Infrastructure and storage costs
• Build costs whether the costs are internal resources or outsourced
• Support, maintenance and operations, with a view to staying on top of technical debt
• Ongoing evolution to add new features
• License fees
• Data costs - such as paying for external data services
• Training and documentation, including bandwidth necessary to keep up with the ever evolving cloud data platform landscape

Strategic Principles for Success

Now that we've covered the nine building blocks in detail, let's examine some key strategic principles that will help you get the most value from using the canvas in practice.

Keep scope as narrow as possible

By design, the Data Product Canvas presents you with a small surface area to force you to focus the data product on a specific goal, audience and actionable insight.

By keeping the scope of the data product as targeted and as narrow in scope as possible, you are more likely to deliver it. It helps you to avoid the trap of monolithic solutions, "analysis paralysis" and multi-year waterfall projects that promise the earth, are often late to deliver and fail to meet their promise.

Establishing clarity of purpose is fundamental in product design as it:

• Promotes alignment and effectively decision-making within the team responsible for building the product, helping you to avoid scope creep and un-wanted features
• Clear communication helps with "marketing" the product by allowing users to grasp what the product is for
• Protect the longevity of the product by simplifying the strategy and road map

If you can't fit your idea on the canvas it's too big. Use the canvas to simplify your initial idea down to the quantum of functionality that will have maximum impact with the least amount of complexity and risk.

Tackle Data Products as a socio-technical endeavour

To succeed, you need to master the cultural, organisational and human aspects as well as the technology in order to be successful in extracting value from data. We often talk about about people, process and technology. As data professionals, we often pay too much attention to the technology part. The data product canvas will help give you early sight of the people, process and technology barriers that may act against the goal(s) you are trying to achieve.

The key to winning hearts and minds is to involve all relevant stakeholders early in the lifecycle, to collaboratively build shared situational awareness, to be transparent about the people and process aspects that are key to success; and to get commitment from all to the transformation. The Data Model Canvas is a tool which supports this approach.

The latest wave of Generative AI is particularly susceptible to this. We have seen examples in the work we have been doing with clients to embrace the latest wave of Generative AI products and services: only the teams that are willing to develop new skills and embrace new ways of working are able to generate value from this exciting new technology.

We find the level of the resistance is often in proportion to that of the scale of transformation required to successfully adopt the new technology. This resistance is often driven by mis-aligned incentives. To quote Upton Sinclair:

"It is difficult to get a person to understand something, when their salary depends upon them not understanding it."

Elevator pitch

The Data Product Canvas provides all of the information you need for your elevator pitch. It covers all of the fundamentals: the purpose (what problem is it solving?), who it's target users are and the value it is seeking to generate.

It is extremely useful when you are required to "sell" the idea to senior stakeholders who may need to be convinced to committing budget and / or resources to it. It is the mental model you can use to describe the data product. If you do choose to share with the stakeholder, we wouldn't recommend walking through it line by line. Describe the principle of the canvas and allow the stakeholder to then explore it and ask questions. You may be surprised to find that they have already come across the Business Model Canvas or simply "grok it".

Conclusion

The Data Product Canvas transforms how organizations approach data products by shifting focus from technology-first to purpose-driven design. By working through these nine building blocks in a collaborative, iterative process, teams can identify winning opportunities, eliminate costly missteps, and ensure alignment between business value and technical implementation. This upfront investment of time saves organizations substantial resources by validating ideas before committing to development. Start using the canvas today to dramatically improve how you conceptualize, communicate, and deliver data products.

Stay tuned as we dive deeper into the Data Product Canvas:

• Part 3: The Canvas in Action - we share a worked example of the case study based on a real-world scenario, demonstrating how it guides decision-making and shapes successful outcomes.
• Part 4: The Theory Behind The Canvas - we will explore the frameworks that form the foundations of the canvas.