Information Product Canvas

Do you prefer the feel and joy of reading a digital book?

Buy the ePUB version

The 12 Areas of the Canvas

Shagility — Sun, 18 Jan 2026 14:42:00 GMT

Do you prefer the feel and joy of reading a physical book?

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

#01 - What questions will the Information Product answer

Shagility — Wed, 31 Dec 2025 14:42:00 GMT

Do you prefer the feel and joy of reading a physical book?

As I outlined in The Order of the Canvas Area post:

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.

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.

Do you prefer learning via virtual in-person courses?

Do you prefer the feel and joy of reading a physical book?

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

Shagility — Tue, 30 Dec 2025 14:42:00 GMT

Do you prefer the feel and joy of reading a physical book?

Once we have captured the business questions as outlined in the previous post:

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?

What action will you take once you have the questions answered?
What is the outcome once you have taken that action?
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.

Do you prefer learning via virtual in-person courses?

Do you prefer the feel and joy of reading a physical book?

#03 - Personas, who will use the Information Product

Shagility — Mon, 29 Dec 2025 10:07:00 GMT

Once I have captured the actions and outcomes as outlined in my previous post:

I 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.

Do you prefer learning via virtual in-person courses?

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

Sun, 28 Dec 2025 19:41:00 GMT

Once I have captured the persona’s as outlined in my previous post:

I 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.

Do you prefer learning via virtual in-person courses?

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

Sat, 27 Dec 2025 01:27:00 GMT

Once I have captured the delivery types as outlined in my previous post:

I 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.

Do you prefer learning via virtual in-person courses?

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

Shagility — Fri, 26 Dec 2025 07:34:00 GMT

Once I have captured the frequency the data has to be refreshed as outlined in my previous post:

I 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.

Do you prefer learning via virtual in-person courses?

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

Shagility — Thu, 25 Dec 2025 17:45:00 GMT

Once I have captured the core business events that create the required data as outlined in my previous post:

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:

For a [persona or audience]

I want [what feature do they want]

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.

Do you prefer learning via virtual in-person courses?

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

Shagility — Wed, 24 Dec 2025 08:23:00 GMT

Once I have captured the feature stories that capture the key features as outlined in my previous post:

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.

Do you prefer learning via virtual in-person courses?

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

Shagility — Tue, 23 Dec 2025 20:44:00 GMT

Once I have captured the wills and the wont’s that capture an early idea for the scope of of this Information Product as outlined in my previous post:

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.

Do you prefer learning via virtual in-person courses?

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

Tue, 23 Dec 2025 18:53:00 GMT

Once I have given the Information Product a unique name as outlined in my previous post:

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.

Do you prefer learning via virtual in-person courses?

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

Shagility — Mon, 22 Dec 2025 19:16:00 GMT

Once I have identified the Product Owner as outlined in my previous post:

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.

Do you prefer learning via virtual in-person courses?

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

Shagility — Sun, 21 Dec 2025 20:18:00 GMT

Once I have crafted the Vision Statement as outlined in my previous post:

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.

Do you prefer learning via virtual in-person courses?

https://agiledataguides.com/information-product-canvas/#kindle

The Kindle version of the book is out and how I ended up setting the $9.99 price for it

Shagility — Tue, 30 Sep 2025 21:11:05 GMT

Kindles are Go!

Finally got the Kindle version of the book out and on the virtual Amazon shelves.

Quick links to the various Amazon store websites can be found here:

The Self Publishing process was harder than I imagined

When I decided to self-publish I did a bunch of research, reading online posts, listening to podcasts and of course chatting with my LLM friends etc.

Self publishing seemed to be a bit in the process, but it didn’t seem that hard.

In hindsight it was a lot more onerous than I expected.

If you are thinking about self publishing feel free to reach out, I am always happy to share the process I ended up using and the experiences I encountered on my journey (both good and bad), remember Sharing is Caring!

The Kindle process was harder than I imagined

My good friend Kat Greenbrook had already self published the digital version of her excellent book “The Data Storyteller’s Handbook” (you should grab a copy of it from here https://www.roguepenguin.co.nz/book)

Kat was kind enough to share with me the pitfalls of converting the paper book to the Kindle format, and while forewarned it was still a lot more effort and trial and error than I expected.

But today i’m not going to write about the drossy process of creating Kindle formats, I am going to talk about how I decided the price for the Kindle version would be $9.99.

The book was all about scratching an itch (and a little bit of vanity)

As part of the research into writing a book I talked to a few people who had done it.

The overarching feedback was that the writing process was onerous and you will make bugger all money.

Yes there are books that are constantly in the best seller ranks for many years, the Fundamentals of Data Engineering by Joe Reis and Matt Housley is an example of one of those books, it has been a best seller on Amazon in both print and Kindle versions for many years. To be constantly at that best seller level a large number of copies must have been sold.

While I have no idea how much of the sales price for an O’Reilly book goes to Amazon, (i’m guessing O’Reilly gets a discounted deal from Amazon given the volume they sell through it) and how much O’Reilly as the publisher gets vs Joe and Matt as the authors, i’m going to guess that they have done financially ok from that book. And good on them, great book at the right time.

But for most authors I talked to, who didn’t create a consistent best seller the royalties from their books were always a nice surprise, but they weren’t buying new cars with them (a shout out to those who were kind enough to share their numbers).

When I was lucky enough to chat with Joe Reis on his podcast about my experience with the book writing process (you can listen to it here : https://creators.spotify.com/pod/profile/joereis/episodes/Shane-Gibson---The-Power-of-the-Information-Product-Canvas-e36huq6 ) he asked me why I decided to write the book.

And my answer was it was something I had always wanted to do, it was an itch I wanted to scratch and I finally decided to spend a couple of years part time, scratching that itch.

While this is true what I didn’t say (or maybe I did) is there was also a large amount of vanity behind it. I have always wanted to be a published author, see my name on the cover of a book etc, and although its much more accessible to do this via self publishing these day’s and slightly less prestigious as a result, the vanity card was always on my table.

So now onto the dirty subject of money

When you publish a physical book via Amazon KDP there are a few decisions you have to make, that effect the cost of the book and how much you make from each sale.

The first is the size of the book, the physical dimensions and the number of pages.

The second is if it is black and while or colour.

The third is the type of cover, paper back, hardback etc.

Each of these are inputs into the final number Amazon KDP charges you each time they print the book for a customer.

After those choices you pick the retail price for the book.

Amazon KDP then charge you a percentage of that retail price as a royalty for them and the cost of printing and you get what is left.

So the calc is:

(Authors Royalty rate x list price) – printing costs = Authors Royalty Amount

(There is also a hidden little cost if you are not a US tax resident, where Amazon KDP also hold a % of the Authors Royalty Amount as IRS with holding tax that I cant see a way to get back).

So lets have look at an example for the paper back version of my book.

So you can see with a retail price of USD $40.42 on Amazon.com, Amazon KDP take:

40% of the retail price as royalties = USD $16.16
USD $16.44 for the printing costs

And I as the author get USD $7.81 from each sale.

A few things to note:

The dimensions of my book are custom and I went for the highest quality colour paper I could, and a gloss cover so that is at the higher level of print cost per page
You pay per page printed, my book is 193 pages so a fairly small page count compared to some of the other text heavy data books which would cost more to print
The US IRS withholding tax comes off my $7.81 before they send me the money
Amazon KDP hold the money for a couple of months before they send it to the author, I received my payment for July sales at the end of September.

The other trick for young players is you think (well I did) that the 60% of the retail prices is all yours, but actually the printing costs come out of your side of the equation.

So Amazon KDP get 40% of the retail price as their royalty, you get 60% minus the printing costs.

Now to be clear, the ability to self publish via Amazon KDP with their print on demand service seems to be a much better option compared to paying for a large run of books yourself and then also paying for them to be stored and shipped, not to mention dealing with the ordering and shipping logistics, payment processing and fees etc.

The other thing is a lot of authors make their money not from the books themselves but from the paid courses, consulting and speaking engagements that happen as a result of publishing a book.

So now onto the Kindle pricing

The way Amazon KDP manages the pricing of the Kindle version is of course different to the paper version as there are no physical printing costs.

The first thing is you need to decide if you want to take an Authors Royalty Rate of 35% or 70% for your Kindle version.

Easy you would always take the 70% right?

Well here is the rub, for the 70% rate you cannot charge more than $9.99 for the Kindle version and you have to pay a digital delivery fee based on the the size of the digital file for your book.

For the 35% option you can charge what you want for the Kindle version (well there is a bottom and top cap) and you don’t pay for the digital delivery fee.

You can read about the rules here:

https://kdp.amazon.com/en_US/help/topic/G200644210

Buts lets look at a couple of examples for my book.

My Kindle version with the price set at $9.99

Then at $19.99

Then at the same price as the paper version $40.42

So a spread between $5.19 and $14.15 per Kindle sale.

And as you can see you can also change the price per region.

The devil is in the data

As you can imagine these options meant I jumped into data analyst mode trying to work out the optimal cost vs royalty return, with some parameters for likely uptake of sales based on the cost compared to the historic physical book sales.

Would $8.99 vs $9.99 make a difference to how much I earnt.

What was the ratio other authors and publishers used for print vs Kindle.

Why did O’Reilly always seem to price their Kindle version just below the print version.

And of course as my book is very image heavy I could also reduce the digital cost for the 70% option by reducing the quality of the images in the book.

In the famous words of one of our personal go-to Xmas movies

Enough, enough now!

Why did I write this book, it was to scratch an itch, not to get rich.

Yes its has decades of experience imbedded in it, but the majority of the book is available on this substack site entirely free.

Yes at $9.99 it might be seen as I am “undervaluing” it and people wont buy it because it seems to be too “cheap”

After training a myriad of Data and Analytics teams over the years on how to use the Information Product Canvas to improve the way they gather data requirements, I still get a buzz helping people change the way they work for the better.

With an Author Royalty Amount spread between $5.19 and $14.15 per Kindle sale, would an extra $9 per sale change my life? NO!

The final thought was would I spend $40 for a Kindle version of a book I wasn’t sure would be any value to me. NO!

Would I spend $9.99 to take a punt it might be useful. YES!

So with that the death by a thousand data decisions was gone and a quick decision made, $9.99 it was.

Grab a copy of the book for the price of two cups of coffee.

Grab the Kindle version if you want an digital version of the book.

Quick links to the various Amazon store websites can be found here:

https://agiledataguides.com/information-product-canvas/#kindle

A warning:

Because of its visual design, this is a FIXED LAYOUT Kindle eBook, it is only readable on some devices.

Or as I put in the Kindle version …..

As I say the book really has been designed to be read as a physical book.

So while you can read it on a Kindle, and I get that for some of you Physical books are not your jam, the layout has been designed for this double page physical spread and I have made minimal compromises on that layout in the single page Kindle version.

What about those non Kindle users out there?

I still have creating an ePub and/or PDF version on my backlog list, which I will publish via my Shopify store.

Who knew creating eBook versions of a book would be such a faff !

So if you would prefer that over the Kindle version, flick me a reply email and Ill let you know when its Done Done.

Webinar :: Information Product Canvas Areas

Shagility — Tue, 19 Aug 2025 20:00:07 GMT

Do you prefer the feel and joy of reading a physical book?

In August 2025 I presented a quick run through of the Information Product Canvas areas to the DAMA SA community, you can watch the recording on youtube:

Got Questions?

It was interesting the different type of questions I got from a group of Data Professionals that were Data Governance focussed compared to the questions I typically get asked.

If you have a question thats been bugging you about the Information Product Canvas just ask, Ill always do my best to answer them.

Do you prefer learning via virtual in-person courses?

Do you prefer the feel and joy of reading a physical book?

The order of the canvas areas

Shagility — Thu, 31 Jul 2025 20:40:00 GMT

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.

Each of these areas have been added and iterated over the last decade working with multiple teams across multiple organisations.

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

I have a typical order I use when Pattern Storming the canvas with stakeholders, one that I have experimented with, iterated on, and refined over the last decade.

I start with Business Questions first, as I find this is the easiest area to elicit initial answers from stakeholders. Next, I move to Actions and Outcomes, asking “if I provide you the information to answer those questions, what action would you take, and what outcome would that action deliver”

If the stakeholder cannot describe the Actions and Outcomes, I may stop capturing requirements. Without a clear statement of value, the Information Product is unlikely to be prioritised for delivery, making further effort in capturing requirements wasted effort.

The second-to-last area I complete is the Vision area, as I need content from the other areas to complete the Vision Statement.

I typically add the T-Shirt Sizing after the workshop, collaborating with the data team to create a guesstimate. This also provides an opportunity to socialise the canvas with the team.

I have worked with people who fill out the Information Product Canvas in two iterations.

First they fill out the Action/Outcome, Persona, Information Product Name and Vision Statement areas.

This version of the Canvas then gets put into the backlog for prioritisation.

Once it is prioritised to be worked on they then patternstorm with the Stakeholders to complete the rest of the Canvas areas.

Fill out the Canvas in any order that works for you.

Iterate the process it as often as you want/need to.

After all the Information Product Canvas is a pattern template that can help your data teams way of working.

It is NOT a “Framework”, it is NOT a “Methodology” it is NOT a dogmatic doctrine.

So use it the way it suits you and your data team best.

Do you prefer learning via virtual in-person courses?

From Canvas to Data Design

Shagility — Wed, 16 Jul 2025 03:56:59 GMT

Do you prefer the feel and joy of reading a physical book?

Discovering requirements is just the start of the Information Value Stream journey, Data Design is another of the many important steps on the journey to delivering value.

More than a one use template

In the Green Book I outline the different stages in the Information Value Stream where I use the Information Product Canvas, you can read about that here:

One of the things I have been doing lately is working on how the Information Product Canvas adds value to the stages after Discovery.

How does it reduce the work required to do those stages?
How does it reduce waste?
How does it reduce the time taken?
How does it streamline collaboration and conversations?
How does it reduce uncertainty?
How does it reduce the cost of chnage, allowing us to experiment more often?
How does it make the complexity in those stages simpler?

As part of this I have been thinking about the Data Design step in the Design stage.

Defining Data Design

Three of the Agile Data Guides I have in the backlog are the:

Business Concept Maps (Blue Book)
Layered Data Architectures (Grey Book)
Information Factory (Steel Book)

The first of those I start to write will force me to create a clear definition for Data Design.

For now lets use a placeholder high level definition of:

Data Design is the pattern of discovering, organising and representing data so it aligns with real-world concepts and makes complex information understandable, accessible, and actionable.

And a placeholder detailed description of:

Data Design is like planning a city.

At the highest level, we start by listing the important places that exist, this is our concept map. It’s not yet a formal plan, just a shared understanding of what exists and what might connect.

Concept map → the town map

Just names and rough groupings of places: houses, shopping centers, library, schools, parks, hospitals, sewerage plants, airports. No formal layout yet, just “what exists.” and a rough indication of “where it should exists together or apart”.

From there, we move through layers of increasing detail:

Conceptual model → the street plan

Shows how the places are connected, roads, districts, neighbourhoods. We start to structure the map.

Logical model → the house plan

Each building’s layout: rooms, walls, how things flow inside a structure.

Physical model → the room layout

Where the walls, doors, and power outlets go, ready for builders.

Schema → the furniture in the room

The exact shape, placement, and format of each object that fills the space.

This layered view shows how data design starts well before technical modelling—it begins by agreeing on what matters, what exists, and how people talk about it.

Still needs a bit of work, but you can see where I am going to go with it, when I start working on it in anger.

Credit to Christopher Alexander and his original books “A Patterns Language” and “The Timeless Way of Buildings”. And to John Giles and his book “The Data Elephant in the Board Room”.

The Canvas as an Input into Data Design

Here are some early thoughts on the Patterns and Pattern Templates that the Information Product Canvas can help with in the Data Design step.

These thoughts are “Hand Waves” as described here:

https://agiledatawow.substack.com/about

I have used these in training material, and in coaching Data and Analytics teams, and in the delivery of our Fractional Data Services, but these Patterns and Pattern Templates still need a lot more refinement and iteration to be repeatable.

Pattern 1 :
Mapping expanded Business Questions to the 7W’s

I have used this pattern before where I have taken an expanded Business Question, effectively a data example pattern, and created a list of all the Core Business Concepts based on the 7w’s in Lawrence Corrs BEAM patterns, Who’s, Whats, Where’s, When’s etc.

Time (quarters, years)
Sales
Products (custom t-shirts)
Products
Promotions
Customers
Regions (north)
Channel (store)

Pattern 2 :
Mapping Business Questions and Core Business Events to the Concept Template

I can take the Business Questions and the Core Business Events from the Information Product Canvas and populate the Concept Template I have used in the past.

From this:

to this:

In this Pattern I am identifying the Core Business Concepts in the Information Product Canvas and then putting them into the Concept Groups based on a subset of the 7w’s

I am also expanding the Core Business Events to have all the Concepts that are involved to provide the next level of detail in the Data Design process.

Pattern 3:
Mapping Business Questions and Core Business Events to the ELM Templates

I can take those same Business Questions and the Core Business Events and populate the ELM Templates created by Remco Broekmans.

For example the Core Business Concept (CBC) Canvas.

Pattern 4 :
Mapping Business Questions and Core Business Events to a Conceptual Map

I can take those same Business Questions and the Core Business Events and create a Conceptual Map of the Core Business Concepts and and their potential Relationships.

Document my data design questions

I can also use the Conceptual Map to document some questions I have about the Data Design.

Questions such as:

Do we capture and store the Location of the Customer when they place the Order in Store?
Does an Order placed on the Website differ to the Order placed in a Store?
Do we have the concept of an Abandoned Order in a Store or is that only possible on the Website?
What the organisation ever use a term to combine Store and Website, for example Channel?
How do we know a Delivery and Return happened, is this data captured and if so in which system?

A few small steps, still a long a way to go to get to the final Pattern and Pattern Template destination

Hopefully seeing the way I currently do that journey has been useful.

Do you prefer learning via virtual in-person courses?

Do you prefer the feel and joy of reading a physical book?