The Hitchhikers guide to the Information Product Canvas

11 Jun 2023 | AgileData Network, AgileData Way of Working, Blog


In mid 2023 I was lucky enough to present at The Knowledge Gap on the Information Product Canvas.

Shane Gibson -


The Information Product Canvas, is an innovative pattern designed to capture data requirements visually and repeatably, making it easier for both stakeholders and data teams to comprehend and work from these requirements.

This approach streamlines the process of defining and delivering information products in small, manageable iterations. Each information product is like a unique app with a specific set of data for a particular persona, to be used for predetermined actions that drive business outcomes.

The Canvas provides a shared language for stakeholders and data teams, helping establish consensus on what needs to be built and delivered, similar to the concept of a “Babelfish” translating languages in The Hitchhiker’s Guide to the Galaxy.

This stakeholder-friendly pattern starts by defining key business questions, followed by the actions and business outcomes linked to these questions. These steps assist in prioritising which information product to build next based on its business value.

The Information Product Canvas is a valuable pattern for gathering and prioritising data requirements, fostering efficient collaboration and targeted business outcomes.

Presentation Transcript

Read along you will

Today what I’m gonna cover is a thing that I call the Information Product Canvas. So this is a canvas that I’ve been working on for a large number of years with quite a number of customers. So we’ve iterated it over a few years. And so I’m gonna go through and explain over the next 25 minutes what it is.

First of all. And second of all, how we fill it out. So one of the things about the Canvas is it’s an iteration on a thing called the Business Model Generation Canvas that was done by the Strategizer team. So I’ve taken the concept of the canvas and applied it to capturing requirements for data delivery.

So what I’m gonna do is explain first of all what the canvas is, and then I’m gonna go through bit by bit on each zone in the canvas, what we put in there, why we put it in there, how we put it in there, and at the end summarize it. So the first thing is, what is the canvas? For me it’s a way of capturing data requirements in a repeatable way.

So by using the Canvas format, we have a visual way of capturing requirements, repeatably using the same process. What we want to do is we want to capture those requirements in a way that stakeholders love them and also so that data teams can build from them. So if we think about the information product Canvas, we probably won’t understand, first of all what an information product is.

And for me, I describe it as a boundary. So it’s basically a square with some stuff in it. And within that boundary is our requirements for data, analytical models or visualization. And while we’re putting these things in a boundary we’re doing it for two reasons. We want to bound something so that our stakeholders can agree what it is.

So they can look at those requirements and go, yep, that’s enough. That’s what I need for now. But we also wanna make them small enough so that our data teams can deliver them in small iterations. So two weeks, four weeks, six weeks, eight weeks, whatever you like to think of as an iteration. So that’s effectively what an information product is for me.

Another way I like to think of it is an information product is really a subset of data that’s targeted at a specific persona in our organization or outside our organization. And that persona is gonna take action. They’re gonna do something with that information. To achieve a business outcome. And so another way I like to think of it when I describe it to people is like an app on your phone.

So if I think about my messaging apps. Effectively, they have a certain amount of data. It’s the messages that I use. I’m the persona that uses them and I use ’em for certain actions. So I’ll send text messages to some people. I’ll read my emails. I’ll use Slack, I’ll use Signal. I’ll use a bunch of different apps to do the that comms.

Whereas I have some other apps that I use to manage my calendar. I have some apps where I might do my financial type of work with something like Xero. I use Google Maps to go and find a place. I use Candy Crush to play games. So each one of those has a boundary of a set of data for a set persona.

And I use it for a certain action, sometimes to do work, sometimes to play games. The other way I like to think of an information product and information product Canvas is I’m a great fan of Hitchhiker’s Guide to the Galaxy, which is where the title for the presentation came from. And in that book, in that movie, there was this idea of a babble fish.

And a babelfish was a mythical beast that you stuck in your ear and it gave us a translation of any language. So regardless of the person that was talking to you, their language was translated into a language you could understand. And if we think about that in terms of data technologies, we’ve seen that a lot in the right hand side of our technology stack.

The whole semantic layer metrics layer. I’ve been around old enough to long enough to remember the days of business objects universes. So we’ve had technologies that helped us translate this data and complex technical descriptions into business terminology. So for me, a information product canvas gives us that same capability, that ability to get a shared language, but at the beginning of our process.

So it’s a way of getting requirements that both our stakeholders can understand and our technical d data teams can understand, and they’re using that same shared language to agree what’s gonna get built and get delivered. So that’s how I see it and how I’ve used it over the last few years.

So what I’m gonna do now is I’m gonna go through the canvas and the easiest way to do it is we go through step by step into each of the areas. So I’ll go through and give you an examples of what go in there and why. And then at the end we’ll see the canvas and it’s full completion. And talk about how we look at a canvas from the beginning and get an idea of what it’s telling us.

So I’m gonna start on the left hand side there And so in this box what we do is we look for the business questions that our stakeholders want to ask or get answered. So what we find is if we start off with this one, this is the one that they typically the most ready to answer. If we say, okay, so if we deliver this information product, what questions do you want to answer?

And typically we would say to them, the questions start with how many, how long how much. Why. And so we’ll hear things like how many orders have been placed, what’s the total value of the orders that have been placed, what’s the percentage of abandoned orders? What store region has the most orders?

What channel is driving the largest increase in the order value? And we normally will find that a stakeholder will give you between three and eight of those off the top of their head. And then they’ll start to think of other ones and we stop them there and say good start. This is just an early set of requirements.

We’ll iterate it in the future. No need to boil the ocean. But effectively that’s good enough to get us going. So once we’ve got the business questions we move up to the top left. We say to them, okay, so if we answered the, those questions with some information, what action are you gonna take?

And when you take that action, what business outcome do we achieve? And so they might say something along the lines of, once I understand where the orders are coming in from and what our best stores are. Then I can identify where there’s gaps in the market and we might actually go and open some new stores.

And the reason we wanna open new stores is to increase our overall margin. And so what we’re looking for is that business outcome. And the reason we look for that is this is how we get our stakeholders to prioritize which information product we want to build next. So we have lots of work we can do, and we typically wanna work on one thing at one time and get it out the door.

And so we use this as a way of deriving the business value of this work we’re gonna complete. So once we’ve got that, the outcome and actions, and sometimes that takes a little while we then jump over to the persona box. And we say, okay, if we deliver this information product, who’s gonna use it?

Who’s gonna access that information? All that data. And we’ll typically look for personas. So we would’ve mapped personas for our organization by now, and we may hear things like consumers, information frontline staff maybe. And data analysts or senior leaders data scientists write a whole bunch of personas.

And over time we’ll break those personas down to be quite specific. So we might say a finance consumer, an HR consumer. But at the beginning, you typically start off at quite large grain personas. So we’re looking at who’s gonna use it, and then the next question we ask is, top how do they want to consume it?

So when we talk about information products, we talk about multiple delivery channels. Might be a dashboard, might be a report, might be a data service, might be an api, might be an analytical model. Might be an exporter into a flat file. There’s different ways we can actually surface this information.

So we ask them how they’d like to see it, so something like a dashboard, and then we jump down into data sync. So we say, okay, if this information was available, how often would you want it to be refreshed? And so we’ll hear things like once a month, once a week, once a day every week by Monday at 8:00 AM before anybody comes in, an hour, 15 minutes, or that famous one.

We all love real time. So again, we’re just saying how often do you want this to be refreshed? From there, we jump down to the core business events, and this is where we’ll use something like beam or Im to understand the core concepts of the business and where that data comes from. We’re typically looking at things like customer places, order, customer pays for order, store ships, product.

And funny enough, when we compare them back to the business questions, we’ll see those core concepts come through in those questions. How many orders do we have? What’s the total order value? And what we’re looking for here is again high grain business events. We’re trying to understand the boundary of the data that we need to go and get.

Often we’ll be able to look at this and very quickly say, we’ve already bought in the customer and the orders from Shopify, but actually we haven’t bought in the shipment stuff from sap. So as data professionals we can look at it and go ah, we’ve got a bit of work coming up, or no data’s coming into the platform already.

We are good to go. So once we’ve got the core business events we rip through and as we know, whenever we talk to a stakeholder, they have a core bunches of features or functions. At the top of their mind. And so the user story box is where we let them put those in. So what we’re looking for is features, functions, things that are important to them that we care about, things that we know will take us some effort, or that they just wanna make sure it’s been documented as something they need.

So often we’ll see, I wanna be able to drill down from a dashboard down to the detail. We might be able to see something going like this one, which was, we had a persona of analyst. What do they wanna do? Oh, they wanna be able to export the data out into another tool. Okay. So we need to go and find out what tool they’re gonna use and how we’re gonna integrate to that.

Or the last one there is always the tricky one, actually. We’re gonna go and I want data from multiple systems of capture and to gimme a single view. So again, we’re looking for their user stories of the features that we know are important. And then on the right hand side of it, we have the will wons.

And this is one that we tend to iterate over time with our stakeholders. And the way we do it is we know that if we don’t write anything in here, everybody expects everything they’ve ever wanted will be built. So this is where we help them to make trade-off decisions. So we might go for something along the lines of, look we’ve talked about this.

You had a bunch of business questions. One of the questions around abandon carts, there’s a core business process there of customer ex abandoning their cart. But actually we don’t have that information being brought in yet, and it’s gonna take us a week or a month to bring it in. All the other information’s available.

So would it be okay if we delivered that quickly and answered all your other business questions and then did a second iteration for the abandoned cards? We’re using it as a way of doing trade off decisions with the stakeholders. Or when we go backfill, okay, we’ve gotta backfill some data in how long do we need to backfill it in for?

We’re saying we’re gonna estimate that we’re only bringing in 24 months of data because the data before that was in another system and that’s been archived and therefore is an important we bring it in or not. So we focus on the won’t in this box. Which is the things we’re agreeing with our stakeholders that we won’t deliver for this information product and this inter iteration.

Once we’ve got that, then what we can do is we can jump to the top and we can give this thing a name. Sometimes my customers that I’ve worked with have standard names like order revenue metrics depending on the organization and their culture. Sometimes we, he some funky names in there. But what we’re looking for is a name for that product and for that canvas.

So when we are talking about this piece of work we’re all using the same term, we’re talking about the order revenue metrics canvas. Not the lifetime value canvas. Yep, that’s right. That’s the one we’re focusing on. Now. Once we’ve got a name, what we want to do is jump over and pick up our product owner.

So this is the person that’s gonna work with the data team to make the trade off decisions on behalf of the stakeholders. So when we get stuck and we go, we could do this, we could do that. Both have a constant cons cost and a consequence. The product owner is the person that works with us to actually work with the stakeholders and decide which of those two alternatives we’re gonna go with.

Once we’ve done that, We can go back to the middle, which is the vision statement. And typically we do this last sometimes I like to do it at the beginning, but typically last and all we are doing is we’re actually using a pattern from a guy called Jeffrey Moore that wrote a book called Crossing the Chasm.

And this is a very common vision statement pattern or elevated pitch that we see in the agile world. So we’re taking all the details from this canvas that we’ve just captured and we’re saying for the chief revenue officer, that’s the key stakeholder who wants this information. What do they need? This is the business value, the outcome.

So they need to optimize their investment by opening new stores and new channels. The, so this is where we bring the name of the product in that we define the order revenue metrics. And isa, what kind of product is it? It’s a dashboard. It’s a report. It’s a data service. And then the, that, what’s it doing?

And so we distill the canvas down for this one. So we’re talking about automating the collection of this data. And unlike if we didn’t deliver this information product to the organization, what would happen? What would they do? And in this case, they’re gonna carry on with the current manual Excel reporting process.

And once got that vision. The last one is we asked the lucky data team to t-shirt size. It. So typically an organization will create a bunch of boundaries for those t-shirt sizes. So they might go small’s about an iteration or two. Mediums, three or four iterations. Large is five to six iterations.

Extra large is 12 iterations, and then we typically have os which can be oversized or Oh shit. And so all we’re looking for is again a broad range of an estimate for that size of information product. So if we see an information product that’s say, lifetime value, we know that’s a large number of moving parts.

If we saw one that was revenue contribution, that might be smaller. So again, we’re giving them a sensor size. We’re not story pointing it, we’re not doing it in days or any kind of level of accuracy. And we find that the canvas is enough at the beginning for a team to have a quick guess around that t-shirt size.

So that’s the last box we do. And then we end up with a canvas. So what will normally happen is with a stakeholder who actually knows what they want to a degree, and we elicit that out of them. We can fill this canvas out in about 15 to 20, 25 minutes. When you’re starting off on your own, give yourself a bit of practice.

Normally it take you half an hour to get through the first one until you get the flow. The order I’ve gone through and done them is the order that I typically do it with a stakeholder, but other people I’ve seen who’ve used it, they, start in different places.

So it’s up to you. You don’t have to fill in all the boxes, but what we find is if you don’t fill in an area, then there’s a gap in your requirements that you’ll probably need to go back and fill. And so it’s amazing what will happen when you can do one of these and the data team can come. They either sit through the process with you or they don’t have to.

They can then pick it up and read it and pick up the core of the information to start that process of understanding what they need to deliver. It’s not the an the final answer. Obviously, there’s a lot more work to be done when they get into the delivery cycle, but the other thing is we can start using it to qa the requirements.

So we could say something along the lines of okay. We’ve said that the persona’s a data analyst and we wanna be able to export the data. But actually we worked with another analyst team where we integrated their Jupiter notebook straight into our data repository. So rather than actually do the export and import process, which seems a bit manual, why don’t we let those analysts actually hook their team tools up via secure connection into the database and in the right layer.

And get that information, would that be valuable? Or we could look at it and go, Okay. The data sync is every 15 minutes. But our persona is the chief executive and the type is a data feed. Okay? And we’re not a two person startup. We’re actually a large organization, so we really need to be bringing in data at that frequency and refreshing it cause that’s a high cost for the chief executive.

So we can start actually looking across and comparing the boxes to see whether we have a nice, robust set of requirements to build from. The other thing we can often do is we’ll use it as a prioritization process. So we will take the canvases and we will take five or 10 of them and we’ll take it to a prioritization group or a set of stakeholders, and we’ll say to them, look, here’s all the things that are up next on our backlog.

Which one would you like us to do first? And we let those stakeholders do a trade-off decision amongst themselves. And we asked them to do a thing called Stack Ranking. We asked them to put the canvases in an order and, various ways we can do it. But the idea being the one that’s number one is the one we work on first.

Once we’ve finished it, we work on number two. And if we’ve got two squads or two teams, then maybe we can do two canvases at the same time. So again, it’s a great way for a stakeholder to look at it and go if we did order revenue metrics, this is the business outcome. But if we did a churn model, this is the business outcome.

Which of those two outcomes for us right now are more important, are more valuable to the organization, and they help us with that prioritization. So that’s the canvas. It’s really simple to do. And there is a bunch of templates. So if you go to that to my Wow website there’s a bunch of downloadable templates.

I’ve got PDF version I’ve got some examples. I’ve got some hints. There’s also an article that I wrote that talks you step-by-step what I’ve pretty much presented now, where you can go through and actually see each box, which area what I normally put in there, how I fill it out. And if you want some examples for ones I’ve done with other customers that I can anonymize then get in touch with me either via email or LinkedIn or Twitter and I can take you through some of those examples.

So the last thing from me is I’m actually writing a book about this at the moment, and what I’m looking for is if you do pick it up, And you do use it in your organization I’d love to get an anonymized version of that. So I can use it as a pattern within the book so I can provide people with examples.

And if you do that, then I’ll get you in the book as a contributor because hey, you’re contributing. So that is the information product canvas done in 20 minutes cuz it’s a pretty fast process.

AgileData reduces the complexity of managing data in a simply magical way.

We do this by combining a SaaS platform and proven agile data ways of working.

We love to share both of these, the AgileData Product cost a little coin, but information on our AgileData WoW is free.  After all sharing is caring.

Keep making data simply magical