The Information Product Canvas is made up of 12 distinct areas.

Each area holds a set of information that is captured to provide context and that context should drive a future action by the data team.

Business Questions,
The business questions that will be answered by using the information

Actions/Outcomes,
The action that will be taken and the business outcome that will be achieved by using the Information Product

Personas,
The audience (personas) that will use the Information Product

Delivery Types,
The output mechanisms the Information Product will deliver

Data Sync,
When does the data in the Information Product need to be refreshed by

Core Business Events,
The data-driven business processes that create the data required by the Information Product

Feature Stories,
The key features users will require when accessing the Information Product, expressed using the user story pattern

Will / Won’t,
Statement of scope boundary and high level acceptance criteria

Name,
The name of the Information Product

Product Owner,
Who will make the trade off decisions

Vision,
The Elevator pitch for the Information Product

T-Shirt Size,
The guesstimate of effort to deliver the Information Product

You can complete the 12 areas of the canvas in any order that works for you.

For me I start with the Business Questions area first.

#01 – What questions will the Information Product answer

In the Business Questions area, we identify the initial questions the stakeholder wants the Information Product to answer.

These questions form the foundation of the Information Product and will guide the actions the stakeholder takes based on the answers.

Business Questions usually start with ‘how many’, ‘how much’, ‘how long’, ‘how often’, ‘where’ and perhaps the most challenging one ‘why’.

We are seeking the first three to five business questions that come quickly to the forefront of the stakeholder’s mind.

They might have more than five questions, that’s fine. Let them continue adding to the canvas. Once the stakeholder stops to take a breath and starts to think more deeply, we stop and move onto the next area of the canvas.

These questions form the foundation of the Information Product, guiding what data is needed and how it should be transformed, analysed, and presented.

Engaging directly with stakeholders is crucial when identifying business questions. Stakeholders are the ones who will be sponsoring the delivery of the Information Product, and they are best positioned to articulate the questions that need to be answered.

Most stakeholders are able to articulate these questions quickly. If they struggle, it suggests they need to think about their requirements in more detail or they are acting as a proxy for the real stakeholder.

This isn’t about gathering a fixed set of questions or immutable requirements. Stakeholders can add or refine the questions later, as the Data Team progresses through the Information Value Stream.

#02 – What actions and outcomes will the Information Product answer

We move onto the second area, the Actions and Outcomes.

In the Outcomes / Actions area, we identify the organisational value the Information Product will enable. What specific Actions will be taken based on this information, and what specific Outcomes are achieved if this information is delivered?

1. What action will you take once you have the questions answered?
2. What is the outcome once you have taken that action?
3. What value will the Information Product help deliver?

We capture these to help stakeholders prioritise the next most valuable Information Product to deliver or to justify the cost & effort required to deliver it.

Some stakeholders find it challenging to articulate the value of the Information Product they are requesting. But this understanding is crucial, it links the requested information directly to the value it provides for the organisation.

To help them, we start by asking what Action they will take based on the answers to the Business Questions they’ve already identified.

We are seeking answers to the question, “if you had this information at your fingertips, what Action would you take with it?”

The Actions help identify the Outcomes stakeholders expect to achieve by investing in the Information Product.

We are seeking answers to the second question, “if these Actions succeed, what would the Outcomes be?”

Ideally, we want to quantify the dollar value of these outcomes to support prioritisation and investment decisions. But our goal is to elicit good requirements quickly, not boil the ocean.

Defining Actions and Outcomes brings clarity to the Information Product’s purpose and provides a foundation for measuring its success.

By comparing actual outcomes with the intended outcomes, you can evaluate the Information Product’s effectiveness and adjust as needed.

#03 – Personas, who will use the Information Product

I then move onto the third area, the Personas.

In the Personas area, we are identifying who will consume the output of the Information Product.

Who will use the Information Product?

Our aim is to understand the audience so we can tailor both the delivery mechanism and the information output for the identified Personas.

A Persona represents a specific user or group of users who will interact with the Information Product.

When identifying personas, we want to identify who will directly interact with the Information Product, and who will take action based on the information.

Each Persona may have distinct needs and preferences. By identifying target personas, we ensure the Information Product meets their needs and proves valuable and usable for its intended audience.

Personas can be based on skills, job roles, organisational units, or any other relevant categorisation within your organisation’s context.

For example, you might have personas based on skills such as ‘Information Consumer’, ‘Information Explorer’, ‘Data Analyst’, or ‘Data Engineer’.

Or you might have personas based on job titles such as ‘Sales Manager’, ‘Marketing Analyst’, ‘Customer Service Representative’, or ‘Executive Leader’.

The personas may represent more than just a group of individuals.

They may also identify systems of capture that the data will interface with, for example a Finance or Customer Relationship Management system.

#04 – Delivery Type, how do you want to consume the Information?

I then move onto the fourth area, the Delivery Type.

In the Delivery Types area, we identify the various types of output the
Information Product should deliver.

How do you want to consume the Information?

Our aim is to understand how the audience prefers to consume the delivered information so we can present it in a usable and valuable way.

The Delivery Type is the medium through which the information is accessed by the users. Mediums are varied, each with its own strengths and suitability for different types of information and user needs.

It could be one of these common delivery types or other types specific to your organisation.

• Dashboard;

• Reports;

• Datasets;

• Data APIs;

• Data sharing;

• Data extracts;

• Visualisations;

• Data stories;

• Analytical models.

There could be one or multiple delivery types for a specific Information Product.

For instance, a dashboard might be ideal for a Contact Centre Leader monitoring near real-time call volumes. Conversely, a Data Analyst may prefer a data extract or API, enabling access to the data and allowing them to perform their own analysis.

When defining the Delivery Types, consider the Personas’ needs and preferences, the nature of the data, and the Actions that need to be taken based on the information. Your organisation’s technical capabilities and resources should also be taken into account.

The goal is to present the data in a way that is easy for the users to access, understand and use.

By identifying the right Delivery Types, you can ensure the Information Product is informative, valuable and usable.

#05 – DataSync, When do you want the Information refreshed?

I then move onto the fifth area, the DataSync.

In the Data Sync area, we determine how often the information should be refreshed, indicating when new information should appear in the Information Product for consumption.

When do you want the Information refreshed?

We are interested in how often we have to synchronise new data from the System of Capture through to the final consumable Information Product.

Data Sync is the frequency at which data is collected from a System of Record to update or refresh the data within the Information Product.

The frequency of data updates is a critical facet of your Information Product, significantly impacting its usefulness and value.

Stakeholders often consider when they want to access the information, not when the Information Product needs to be refreshed with new data.

Data Sync involves synchronising new data from the Systems of Capture all the way through to the final Information Product.

The ideal Data Sync frequency is dependent on several factors, including the data’s nature, the Personas’ needs, and your organisation’s technical capabilities. Some Information Products may only need monthly or weekly updates, whereas others might demand daily, hourly, or even near real-time updates.

A Contact Centre Leader’s Call Volume dashboard might need near real-time updates to reflect the latest call volumes. Conversely, an Executive Leader’s monthly financial report might only require updating once a month.

Data Sync expectations help the data team in estimating the complexity and effort required to refresh the Information Product at this frequency.

There’s a considerable difference in the data engineering required for data updates once a day compared to every 15 minutes or near real-time.

#06 – Core Business Events, What data is required?

I then move onto the sixth area, the Core Business Events.

In the Core Business Events area, we identify what data is required to deliver the Information Product.

• What data is required?

• Where is that data first captured?

We want to understand the essential data we need and help discover whether we have already collected it, or identify which System of Capture it needs to be collected from.

Core Business Events represent key business processes, activities or transactions within your organisation that capture the necessary data to answer the stakeholders’ Business Questions.

These Core Business Events generate the data that will be used in the Information Product.

When identifying Core Business Events, consider all activities that produce relevant data. This includes events related to the business questions, as well as related events that may provide further context or insights.

I recommend you use the Agile Data ‘Who Does What’ pattern to quickly understand the related
Core Business Concepts and processes.

This pattern helps establish a shared language between the subject matter experts and data team.

It prevents premature delving into detailed data requirements. Understanding the detail can occur once the Information Product is prioritised for delivery.

We want to identify whether the required data has already been collected, or designed and whether transformation rules have been applied. If not, the data team will need to initiate that work.

This information aids the data team in estimating the complexity and effort needed to deliver the Information Product. It is also useful for guiding future discussions about trade-off decisions with stakeholders.

#07 – Feature Stories, What special features do you need?

I move onto the seventh area, the Feature Stories.

In the Feature Stories area, we capture the key features that need to be incorporated into the Information Product.

What special features do you need?

We want to understand any new or unique features that are required. This helps us identify whether these features have already been built or if we need to build them as part of delivering this particular Information Product.

For the Feature Stories I use an iteration of the agile user story format:

Feature Stories are a useful pattern for capturing stakeholders’ needs in an understandable and actionable way. They ensure that the Information Product is designed and built to meet its users’ actual needs, making it both usable and valuable.

We are seeking the first three to five features that spring to mind for the stakeholders.

They might have more, that’s fine. They can keep adding to the canvas. Once the stakeholder pauses to think more deeply, we move to the next area in the canvas.

When writing feature stories, we focus on users’ needs, not the technical implementation. We aim to capture what the user wants to do, not the how. The technical implementation is determined later, during the delivery process.

If you are using an off-the-shelf last-mile tool like Looker Studio, and the requested features are available in that tool, there is no need to add them here.

Our goal is to identify a few key features we know the data team will need to build, particularly those we recognise as high risk or high effort to deliver.

#08 – Will / Won’t, What is in scope and what is out of scope?

I move onto the eighth area, the Information Product Will / Won’t.

In the Will / Won’t area, we describe what will and won’t be incorporated into the Information Product.

What is in scope and what is out of scope?

These statements set the scope boundary and high-level acceptance criteria for the delivery of the Information Product.

The Will / Won’t statements outline the scope and acceptance criteria for the Information Product, balancing stakeholder requirements with realistic delivery constraints.

In any delivery of an Information Product, there will inevitably be desired features that can’t be included due to constraints like time, resources, or technical limitations.

By explicitly identifying and agreeing these items with stakeholders, we can prevent future misunderstandings and dissatisfaction.

We often find it more valuable to identify what won’t be included, as stakeholders generally assume their requirements will be automatically met.

This area may need multiple iterations, potentially requiring the data team to undertake research to identify high-effort or high-risk features.

Involving stakeholders when deciding on exclusions ensures they understand and agree with the reasons for these decisions or the postponement of certain features to subsequent iterations.

These Will / Won’t statements help manage stakeholder expectations and concentrate the data team’s efforts to deliver value quickly.

Our goal is to ensure that building the Information Product is feasible.

#09 – Information Product Name, What shall we call it?

I move onto the ninth area, the Information Product Name.

In this area, we capture a unique name for the Information Product.

What shall we call it?

This name will commonly be used when referring to the Information Product in discussions with stakeholders and the data team.

The name should, at a glance, reflect the Information Product’s purpose and content.

The name could be based on the main Business Question the Information Product aims to answer, the Core Business Event it supports, the key data it encapsulates, or the main Action or Outcome it supports.

The name serves as a shorthand reference for the Information Product, enhancing understanding and recall among everyone involved in its delivery and ongoing use.

Try to keep the name short but descriptive. When managing a backlog with hundreds of Information Products, a concise but descriptive name proves incredibly helpful.

Naming should consider your organisation’s culture and conventions. Some data teams have found a prefixed numbering system (i.e., 001, 002, etc.) useful for identification, while others prefer more unique names.

After agreeing on a name, ensure it is consistently used in all communications about the Information Product. This helps ensure that everyone is clear about what you’re referring to and reduces the risk of confusion.

#10 – Product Owner, Who will make the trade off decisions as we build it?

I move onto the tenth area, the Product Owner.

In this area, we note the name of the individual who will be assigned as the Product Owner for the Information Product.

Who will make the trade off decisions as we build it?

We want to identify a single individual who can quickly make trade-off decisions as the data team delivers the Information Product.

The Product Owner is the single individual who bridges the gap between stakeholders and the data team. They make the required trade-off decisions during Information Product delivery.

They decide priorities and tackle conflicts to align the Information Product with both value and practicality.

This role requires somebody with the attributes, skills, and characteristics that align with the responsibilities of the role. They should deeply understand the product and market, communicate effectively with stakeholders, make decisive choices about priorities, exhibit clear leadership, and be readily available for conversations and collaboration.

They should be empowered to make trade-off decisions, without having to ask a committee.

Often, a Product Owner might be an executive stakeholder, or they might hail from an organisational unit and have deep subject matter expertise. Alternatively, they might be deeply rooted in the data domain, having extensive technical knowledge.

It’s not unusual to delay the identification of the Product Owner until the Information Product is prioritised for delivery in the next iterations. If not identified initially, the canvas can list the primary stakeholder advocating for the Information Product’s delivery as the Product Owner.

Once you’ve identified a Product Owner, it’s important to clearly communicate their role and responsibilities to other stakeholders and the data team. This helps ensure that everyone knows who to go to with questions or issues, and that the Product Owner has the authority they need to make decisions.

#11 – Vision Statement, What is the elevator pitch?

I move onto the 11th area, the Vision Statement.

The Vision Statement provides a brief and clear description for the entire Information Product Canvas.

What is the elevator pitch?

Think of it as a succinct elevator pitch for the entire Information Product. It’s a powerful narrative you’d deliver to an executive leader during a brief 2-minute elevator ride, or a quick Google Meet call, seeking funding or approval for the data team to bring the Information Product to life.

The Vision Statement should encapsulate the essence, value, and potential of the Information Product in a clear and persuasive manner.

It should clearly articulate who the Information Product is for, what it will do, and why it’s valuable.

For: Identify the primary user, Persona, or sponsor of the Information Product

Who: What outcome do they need to deliver? What value will be achieved if it is delivered? Grab this from the Action/Outcome area.

The: Meld the Information Product’s name with its primary Delivery Type, reinforcing its unique identity.

That: The crux of what the Information Product delivers. Use questions from the Business Questions area, or items from the Feature Stories & Will / Won’t areas.

Unlike: What is the alternative of not having this Information Product available? Highlight the shortcomings the Information Product will address.

The Vision Statement is typically formulated after the rest of the canvas has been populated.

#12 – T-shirt Size, How long will it take to deliver?

I move onto the 12th and last area, the T-Shirt Sizing.

The T-Shirt Size area is where the data team provides a preliminary guesstimate of the time and effort required to deliver the Information Product.

How long will it take to deliver?

T-Shirt sizes (Small, Medium, Large, etc.) provide a way of conveying relative sizing for the delivery time-frame and effort across multiple Information Products.

When deciding the order in which Information Products should be delivered, value should be the primary driver of prioritisation, rather than the effort required to design, build, and deploy them.

Stakeholders should focus on the Vision and Action/Outcome areas of the canvas to determine the next most valuable Information Product to deliver.

However, experience shows that stakeholders often want a sense of how long something will take before making a decision on priority.

To balance these behaviours, we use T-Shirt Sizing as a quick, low-effort way to estimate the relative complexity of delivering an Information Product.

T-Shirt Sizing follows a simple pattern, assigning Small (S), Medium (M), Large (L) labels to reflect the anticipated level of effort and complexity. This broad classification provides a directional sense of effort and time without spending excessive time on detailed estimation.

Experience shows that humans are notoriously bad at effort estimation. If left unchecked, data teams can spend excessive time debating estimates rather than delivering value. That’s why T-Shirt Sizing is deliberately quick, approximate, and designed to prevent over-analysis.

The goal is not to produce a precise estimation of effort but to offer a practical comparison of the time to deliver across multiple Information Products.

Stakeholders can use these relative estimates as an input into prioritisation, ensuring that the most valuable Information Product is delivered next, rather than simply selecting the one that appears the quickest to deliver.