Join Shane and Tammy Leahy as they discuss the Information Product Canvas, what each area of the canvas holds and why you would want to collect this information.
Following up on their previous discussion about what information products are, this episode takes a deep dive into the Information Product Canvas.
Inspired by the traditional business model canvas and Lawrence Corr’s BEAM methodology, the Information Product Canvas evolved from lengthy Word documents into a highly visual tool designed to establish boundaries and scope for data projects. Rather than acting as a locked-in requirements document, the canvas serves as a powerful conversation starter that creates a shared language between development teams and stakeholders.
In this episode, Shane and Tammy break down the key components of the canvas, guiding you through exactly how to use it. You will learn about:
Outcomes and Actions: Defining the measurable business value and the specific actions stakeholders will take once they have the data.
Business Questions: Identifying the top 3-5 “how,” “what,” and “who” questions the information product needs to answer.
Personas and Delivery Type: Pinpointing exactly who is consuming the information (e.g., data analysts, chief revenue officers) and how they expect it delivered, whether via a dashboard, API, or report.
Core Business Events: Mapping out key business processes (like a customer placing an order or returning a product) to understand complexity and necessary data entities.
User Stories and Will/Won’t: Setting strict boundaries on what features, functions, and data will—and won’t—be included in the current iteration to prevent scope creep.
Vision Statement: Crafting a short, sharp elevator pitch that communicates the product’s core purpose, target user, and how it improves the current state.
Ultimately, this episode highlights how using the canvas can help organizations prioritize work based on value rather than just cost, while empowering stakeholders to self-service their own data requests.
Listen
Listen on all good podcast hosts or over at:
https://podcast.agiledata.io/e/agiledata-34-information-products-canvas/
Subscribe: Apple Podcast | Spotify | Google Podcast | Amazon Audible | TuneIn | iHeartRadio | PlayerFM | Listen Notes | Podchaser | Deezer | Podcast Addict |
You can get in touch with Tammy via LinkedIn
Tired of vague data requests and endless requirement meetings? The Information Product Canvas helps you get clarity in 30 minutes or less?
Google NotebookLM Mindmap
Google NoteBookLM Briefing
Executive Summary
The Information Product Canvas (IPC) is a strategic, agile framework designed to define the boundaries, value, and requirements of data-driven information products. Inspired by the Business Model Canvas and Lawrence Corr’s BEAM methodology, the IPC shifts the focus from simple data delivery to value-based outcomes.
The primary purpose of the IPC is to facilitate a conversation between stakeholders and development teams. It serves as a tool for prioritization by identifying measurable actions and outcomes, ensuring that resources are not wasted on “interest-only” inquiries. Key takeaways include:
Value-Centricity: The canvas demands clear outcomes (e.g., increased revenue, reduced cost) and specific actions before development begins.
Boundary Definition: Through “Will/Won’t” statements and persona mapping, it creates a rigid but iterative scope for delivery.
Collaborative Design: It is not a static requirements document but a living starting point for ongoing dialogue and self-service exploration.
--------------------------------------------------------------------------------
Strategic Foundation: Value and Intent
The core of the IPC is established in the top-right boxes: Outcomes and Actions, Business Questions, and the Vision Statement. These elements define the “Why” behind the technical effort.
Outcomes and Actions
This section serves as the information product’s value statement. It requires stakeholders to articulate what will happen once the data is delivered.
Focus on Action: If a stakeholder cannot identify an action they will take with the data, the project lacks a value proposition.
Measurability: Effective outcomes should be specific and measurable (e.g., “Reduce abandoned orders”). Assigning dollar values or specific metrics allows teams to test if the product achieved its goal.
Anti-Pattern: The phrase “I’m interested in what this data will tell me” is considered an anti-pattern, as it lacks a defined action or outcome.
Business Questions
These are the specific inquiries the information product must answer, typically starting with “how many,” “what,” “who,” or “how long.”
Maturity Levels: Simple questions (e.g., “How many orders?”) often address latent demand, while “Why” questions suggest a higher level of analytical maturity and may require more complex delivery mechanisms.
Triangulation: These questions are cross-referenced with Business Events to ensure data requirements are fully understood.
The Vision Statement
Using Jeffrey Moore’s “Crossing the Chasm” format, this statement provides an elevator pitch for the product. It identifies the primary user, the need, the name of the product, the delivery mechanism, and the “unlike” (the current state or manual process being replaced).
--------------------------------------------------------------------------------
Technical Mapping and Data Requirements
The IPC bridges the gap between business needs and technical execution through the identification of events and personas.
Core Business Events
Based on the BEAM framework, this section identifies the business processes (e.g., “Customer places order,” “Customer returns product”) that generate the necessary data.
Entity Identification: Events help reveal core concepts such as customers, stores, products, and shipments.
Complexity Assessment: The number of unique business events serves as a proxy for the effort required.
Reuse: Mapping events allows teams to see if data has already been captured in the platform from previous projects, potentially reducing delivery time.
Personas and Delivery Type
Understanding who uses the information influences the “last mile” delivery.
Personas: Common categories include internal consumers, external consumers, data analysts, and senior leaders.
Delivery Type: Defines the mechanism, such as a dashboard, report, file, or API.
Data Sync (SLA): Specifies the frequency of updates (e.g., daily before 7:00 AM) and the required granularity (e.g., hourly data).
--------------------------------------------------------------------------------
Scope Management and Prioritization
The IPC uses specific constraints to prevent scope creep and manage technical effort.
User Stories and Will/Won’t
These sections function as scope statements.
Will/Won’t Statements: These are critical for managing expectations. “Won’t” statements specifically highlight features or data points deferred to future iterations (e.g., “Won’t break down by supplier type”).
User Stories: Focus on persona-specific needs, such as a data analyst needing to export data or a manager needing to drill down into transactions.
Identifying “Fish Hooks”: Statements like “backfill 24 months of data” or “include return products in revenue” serve as red flags for high-effort tasks that require deeper discovery and business rule definition.
Prioritization Logic
The IPC facilitates a two-pass prioritization process:
Pure Value Conversation: Is the outcome valuable to the organization?
Cost/Effort Analysis: Using “T-shirt sizing” (hacked onto the canvas), teams assess whether the cost to deliver justifies the value.
--------------------------------------------------------------------------------
Methodological Insights
Key Quotes on IPC Philosophy
On Value: “The time of the people I work with is more valuable than answering an interest-only question... there’s going to be a value outcome that can be attached to these things.” — Tammy Leahy
On Conversation: “The conversation is the more important bit here and you’re just documenting evidence in that conversation for the next step.” — Shane Gibson
On Scope: “By putting a ‘won’t’ statement in... it forces that really good conversation about ‘do you actually need that?’” — Tammy Leahy
Tired of vague data requests and endless requirement meetings? The Information Product Canvas helps you get clarity in 30 minutes or less?
Transcript
[00:00:00] Shane: Welcome to the Agile Data Podcast. I’m Shane Gibson.
[00:00:03] Tammy: And I’m Tammy Leahy
[00:00:03] Shane: Hey, Tammy. Good there. See you again. so last podcast we went through information products, what they are and why we should care. And for this session we are gonna go and jump in and have a look at the thing, that we call the Information Product Campus.
[00:00:18] so we’re gonna do a bit of, what is it? What’s. Why do we have those things in it? And then after that we’ll do another recording, directly after it, which is, where we take the example we’ve got and. It to shreds and, give it a good old hiding to see,what’s in there from the content point of view and what would we pick up.
[00:00:36] before we riff into that, if anybody wants to look at the canvas, we’ve gone and, done an example. So if you go to Agile data.io/i p c E. it’ll take you to a copy of the canvas that you can look at and, read along as we talk. So the Information Product Canvas, it’s based on the business model canvas that’s been done, many years ago, [00:01:00] and you pretty much see that, you can’t work in the agile world without creating a canvas.
[00:01:05] to get you some street creds. Not the reason we did it. Actually. the genesis of this was, I worked with a number of customers and we created an information product brief. It was actually a Word document. had all the same information, a little bit more detailed, and we used that a lot to, create those boundaries that we could use.
[00:01:19] later on some other customers wanted to get it down to a picture. And so we picked up, The canvas format, and we’ve been iterating on that for many years. that’s the genesis of where it came from. Actually, the other thing I always like to mention is, Lawrence Core and has beam, methodology.
[00:01:33] He picked up and created a beam canvas, and so that was also part of the inspiration of moving to the IP canvas. So pick up that canvas, agile data. Do io slash ipce and, have read long as we pull this one apart and say what’s in there and why do we do it? first one for me, is,we look at the top right and we have a box called Outcomes and Actions.
[00:01:55] what we are looking for there is if we deliver this information, [00:02:00] what action will be taken? And once their action’s taken, what’s the outcome, that’ll be achieved for the organization? So for me, this is our value statement, This is why should we invest in the effort, to create this information for the stakeholder,
[00:02:13] And we use it for prioritization and a whole lot of stuff we’ll talk about later. so when they’re right at the moment, rough, example is we’ve got an information product called Order Revenue Metrics. in the outcomes and actions box, we’ve got our outcomes to increase overall margin and the action our stakeholder expects to take as to use the information to optimize the investment in new channels, optimize the investment in new stores, and reduce the number of abandoned orders.
[00:02:38] Timmy, Gimme a starter for 10, the outcomes in action box. What a unit we put in there and how do you use it?
[00:02:45] Tammy: similar. You wanna be clear on what action people will take. So what’s the outcome that’s gonna be achieved from the data product or the information product? I like to get a bit more specific.
[00:02:54] I like to try and push people a little bit what is the boundary of, in this example we say reduce abandoned orders. what is the [00:03:00] total boundary of abandoned orders? Like how much value is involved in that? Because like we talked about before, I’m keen on figuring out at this stage what is the value?
[00:03:07] So assign a dollar value to it, sign a metric to it. make it measurable. Make that outcome measurable. you never deliver a product without choosing to measure how that product’s performed. So that’s a key one for me in the outcome and actions box of actually make it specific and measurable so that you can test whether or not the information products achieved what you set out to do.
[00:03:25] Shane: And that for me is because you’ve passed the tipping point, You’re at a stage now where you’ve scaled your team and you’ve done this long enough that you now have an, a massive amount of information, products been thrown at you to build and you have to prioritize. And you use this to understand the value of the work, and that helps in the prioritization decision,
[00:03:43] Tammy: Yeah. I think that’s part of it. I think part of it though as well is you wanna start as you intend to continue. . if someone approaches you and says, Build me this thing, and you say, we’re coming onto the next box, actually. what is the question you’re trying to answer?
[00:03:54] What’s the outcome actually you expect to achieve with this? And they say, I’m just interested, that should be a no because The time of the [00:04:00] people I work with is more valuable than answering an interest only question because in every single business, I don’t care what business it is, there’s going to be a value outcome that can be attached to these things.
[00:04:09] If you’re not doing that well, you shouldn’t be doing something else.
[00:04:12] Shane: so an anti patent for that box is the words I’m interested in what this data will tell me, Because there is no action that’s been thought about. There’s no outcome of that. We are just exploring it, which may have value,
[00:04:22] Tammy: But it, it’s a different value proposition Yeah, totally. And I think the other thing to think about in there is an outcome might be risk mitigation as well, which might be slightly harder to attach value to, but it’s still valuable if you think about it. So dollars is not the only metric we care about.
[00:04:35] it’s just that how do you measure it? what is your. measure of success here.
[00:04:40] Shane: Examples I use when I’m teaching people is they’re all bound around increasing revenue or decreasing cost because that third one of reducing risk, those kind of things, that’s a harder one to quantify,
[00:04:50] so let’s go to the second box, which is business questions. So in the, I’ve created ones of, how many orders have been placed, what is the total value of orders placed, what is the percentage of [00:05:00] abandoned orders, what store regions has the most orders, and what channel is driving the largest increase in order value?
[00:05:05] So for me, the business questions always start with how, many. What, how long, who, Those types of things. And what we want is we want the top three to five questions that they have in their head that they think information will be able to answer, and that drives some of the action they want to take.
[00:05:24] what I find is that question is typically the one that gets answered quickly and. Normally people can just rattle off those business questions. one of the things I found is if I ask for outcomes or actions first, I tend to get given business questions. For some reason, People haven’t thought about the action they’re gonna take.
[00:05:41] They’re just fixated on getting an answer to that business question. So I’ll often ask them what the business questions are first they want answered, and then I will say, What actions are you gonna take? Once you have that information, once you know how many orders have been placed, what are you expecting to do to change the way the organization behaves?
[00:05:57] So how about you? How do you use those business [00:06:00] questions in that?
[00:06:00] Tammy: Really similarly actually, I think the way I think about it is I do them at the same time. it’s an open conversation of what questions are you trying to answer and why. and that sort of fills both of those boxes in. And I think for me, some of the business questions help you you understand where they’re at as well.
[00:06:14] where the person asking the question is at, from a, an understanding of what’s possible, How open they might be to you suggesting a different way of doing things. Should it come to that? that’s the one thing about how and what kind of questions is how and what questions are, or how many and what questions are quite, dashboard,
[00:06:28] And this is a dashboard example. they’re show me a report or a visualization when there could be why questions. And the why questions are much trickier. But are equally relevant when it comes to the business questions, because that might suggest that they might think they’re in this for a dashboard, but they’re asking a question that’s not a dashboard question.
[00:06:45] This is a different proposition here. I look out for what kind of questions they’re asking and then how that might influence The type of information product we provide.
[00:06:52] Shane: for me it also becomes around level maturity. So often people have a latent demand where they just can’t get access to simple how many, how much [00:07:00] questions.
[00:07:00] but once you can, that’s just your first question. And then they’ve got a bunch of other ones, which go back to the where or the whys or those kinds of ones.
[00:07:07] Tammy: it’s the classic. You give them the first information product, which answers those questions, and the very next question, it will be, Oh, so why is that number going up or down or trending next?
[00:07:16] I almost wanna take it to that next step to understand if they’d be open to thinking about that next step. At the same time, it all comes to size.
[00:07:22] Shane: and again, one of the reasons we do this is to understand the amount of investment or effort is required to get their value.
[00:07:28] I’m always happy to just produce some simple how and how much and how many questions, Answer those early, get it back to them really quickly. And then, Wait for the next one And then iterate through. So that’s okay. alright, business questions typically get answered really well, because they’re being ruminating on them for a while before they, they come to you.
[00:07:45] the next one I tend to jump over to is this idea of persona. understanding who’s gonna use this information has some value for us. we would ideally have already mapped out personas in our organization. And for me, personas are things like, internal information consumer versus [00:08:00] an external information consumer,
[00:08:01] They’re different personas. The way we produce the information for them, the things we have to do are slightly different. We might have a data analyst, a data engineer, a data scientist, a senior leader, There’s just ways of breaking up. The people who consume information will use. or access it and what they wanna do.
[00:08:15] in this case, we’ve got two information, consumer and data analysts, And then when we talk about user stories in that later, you’ll see how we, see some value in defining those personas. we often wanna see whether those personas have different business questions. Or if they want different content delivery types.
[00:08:30] So if I just jump over for that one, there’s a boxy called type and we put in the last mile information app delivery mechanism, So is it a dashboard? Is it a report? Is it a file? Is it an api? We want a hint of how they’re expecting to get it, we’re looking for disconnects between the persona and the type of delivery sometimes.
[00:08:46] So what about you personas and, delivery type?
[00:08:49] Tammy: I think the, that top right corner is all connected for me. Personas, delivery type and data sync, frequency or health and they want it refreshed. Interesting though, just looking at it now, again, I’m thinking [00:09:00] in personas. I also wanna know more audience, but that’s covered into the vision and user stories a little bit.
[00:09:04] Cause that gives you a little bit more specificity of actually who is the person I’m delivering this for. so agree personas is the personas that you’ve talked about. And I also like to do also exactly which audience. So you could be analysts in a different domain, so in this case you’re talking about orders.
[00:09:20] you probably have revenue optimization or a store kind of analytics group that might be looking at this. Equally, if you’re looking in a finance team, they might have a different flavor Or depth of insight they need. sometimes that’s helpful as well, but I think you probably get that outta that vision and user stories potentially.
[00:09:34] Shane: if it’s important to understand the organization topology, The hierarchy so that, we have different business units and it’s, valuable to say, look, this is for the finance business unit primarily, versus the human resources or the, the revenue or the operations, then.
[00:09:50] Either create a new area into the canvas and wack it in there, or just slip it into that persona one and change it to persona slash audience. So one of the things with the canvas is, it’s open [00:10:00] source, pick it up, hack it, put in the boxes. That makes sense to you because all you’re trying to do is gather information that creates that boundary quickly for you.
[00:10:06] and same, your data sync, I use that in terms of, frequency of refresh. when do they expect that data is it a daily, is it a weekly, is it a monthly, is it before 5:00 AM Is it every hour? Is it every half hour? Is it using air quotes real time? so those kind of things we wanna know,
[00:10:21] and again, often hard for people to give you an answer.
[00:10:23] Tammy: the other thing that people get confused by that one sometimes is they think what you mean by that is the granularity of the information. They want. in their head they’ll have a picture of the dashboard or the report that they want, and they’ll think that data sync means that they’re gonna get every day.
[00:10:36] So daily refresher information in this example before 7:00 AM and it’ll show them the hourly ordered data by day and week compared to same time last year or something. So in their head, they’ve got a picture. What it might look like. And sometimes that’s useful to get out as well because it doesn’t always come out in the business questions.
[00:10:55] and unless you’re gonna do that second page, for example, of a little quick wire frame, you’re not [00:11:00] gonna get it out of them necessarily here that’s almost like delivery sla. Like, when is it gonna be ready for me versus actually what is it gonna show me?
[00:11:07] And so I think they’re just the two different things.
[00:11:10] Shane: when you’re talking about that data sync, that, when, how current should that information be? Then you will break down into those conversations. And I tend to put the results of those into user stories or will wait sections if they’re valuable. one of the things we often get is, I want it by this and I want it by that, and I want it by that.
[00:11:25] there’s a little bit of skill in saying how many of those buy variables are actually important for us to document right now? How many impact the boundary or how many do we just expect to.
[00:11:35] Tammy: But then equally, sometimes they’re like, I wanna buy half hour. And they’re like, actually, given the outcome you’re trying to achieve, is that going to actually make a difference, the decision you’re going to make I think that’s also a useful conversation to have because your scope can get massive if you’re not careful and suddenly it’s not even useful to them to deliver their outcome.
[00:11:51] it is useful to have that conversation.
[00:11:53] Shane: the other thing that’s important around the canvas is it’s the beginning of a conversation, So it’s just starting the conversation quickly. if they go,[00:12:00] I want, half hourly data, then we document that in the canvas.
[00:12:03] Then when, we get closer delivery and the team pick it up and they look at it, they go, right now we’re recording data, at an alley green. so there’s a massive amount of rework to do to bring that down to half. then we have a conversation, with the product owner.
[00:12:15] And we say,doing it on an hourly grain, low cost piece of effort, doing it to half hour means this is massive. what do you wanna do? What’s the trade off? Are you willing to trade off to hourly? Or actually, is this so important that it’s at half hour, that it’s worth the investment?
[00:12:28] And that’s just a conversation to get that boundary.
[00:12:30] Tammy: I’ve actually had examples where someone’s pre-filled this and then we’ve had a conversation about what they’ve pre-filled, I’ve sat down someone in the business. It was actually someone who’s working quite closely with us, and he pre-filled it and he ended up extending the business questions to two pages.
[00:12:43] that was a very interesting conversation when it came to it. Really So agree completely. it’s the conversation is the more important bit here and you’re just documenting evidence in that conversation for the next step.
[00:12:53] Shane: often see that, how many orders been placed by store, by region, by time of day, by whether it [00:13:00] was sunny or not,
[00:13:00] those buy variables often give us a lot more breadth on those questions. But, if we talk about how many orders been placed, Versus, what’s the total order value? both of those questions we probably want by store, by region, by time of day, by whether it was sunny or not.
[00:13:14] which takes us to the next one, which,of stands out on its own and it’s what I call business events. And again, this is following the who does what Beam framework from Lawrence Core, that I use a lot. it’s this idea of understanding the core business processes
[00:13:28] the ones we got in there is customer places, order, customer pays for order, stewardships product, customer returns, product. There’s four core events there. The reason we put these in is this gives us, data requirements, Lets us understand the data that has already need to be produced and captured for us to fulfill this requirement, fulfill this canvas, this information, product delivery.
[00:13:48] what we’re looking for is those types of sentences because that’ll help us in the future map back to the systems that capture actually created tho that information. it’ll help us look at other information, product canvases we’ve [00:14:00] done and delivered already to see whether those core business events have already been recorded and captured in our data platform, which means we get reuse, which is less.
[00:14:07] Ideally. and it also gives us a sense of complexity. counting the number of core business events is a great way of understanding the complexity and if it required to deliver this. So what about you? What do you put in there for the core business events? so very
[00:14:19] Tammy: similar. It is core business events.
[00:14:21] I think it almost like a process flow in a way, cuz for me, if you start with the beginning of a customer, place an order and it ends with the customer pays for the order and returns the product If the outcome here is figuring out which stores to invest in a margin for stores, then I try and map the process to get straight in my head where again, data flows are similar to you.
[00:14:41] whether or not you use Beam, I think is still useful to think of this way. Think of it this way because I honestly could not say that I’ve used Beam, but I still think of it this way because it’s helped me think about The subject areas or the data entities that you’re dealing with. So you’ve got a customer, you’ve got orders, you’ve got stores, you’ve got products, you’ve got returns, and so you’ve got [00:15:00] states and you’ve got transactions, and you’ve got all these different things and it starts to help form that picture for me.
[00:15:04] agree about mapping them in this way, whether or not you use Beam, I think it’s, it doesn’t matter because this helps you start to define the bits of things that you need to pull in. My sentences are probably a bit longer than yours. Like I would say customer places an order on a website or customer places, an order via phone or whatever it might be.
[00:15:22] cuz it’s that next level of context, You can still gather that somewhere else if you need to. these conversations for me are typically about an hour long, an hour and a half long when I talk to people. and that includes writing up the whole canvas basically while we’re there.
[00:15:33] and so you do get quite a lot of information out quite quickly, I find. So if I get a snippet of information, even if it doesn’t seem to fit anywhere in the right box, I make sure it’s there because that’s context you don’t wanna lose.
[00:15:45] Shane: for me that idea of core business concepts,
[00:15:47] That’s really important. again, if I look at those four customer places, order customer pays for order stewardships product and customer returns product, I can see that we’ve got a core concept of customer, We’ve got a core concept of order. We’ve got a concept of. In [00:16:00] place in the order.
[00:16:00] So there’s, an ordering process in there that we need a word for. we can see a payment in there, we can see a shipment, we can see a store, and we can see a return and we can see the product, So it’s quite a few concepts in there. And if we’ve already defined some of those, Previously, if we’ve already done some information, product delivery that says we’ve already got customer, we’ve already got order, then we know it’s left effort.
[00:16:20] But if we haven’t done any of these, we know that’s a big piece of work. what we can do is we can also map that back to our business questions to try and reduce the scope of the initial delivery, The initial iteration. So we could go back and say, if we look at those business questions, there’s probably only one of them that’s driving the need for shipment and.
[00:16:39] And payment actually. And that is what’s the percentage of abandoned orders depending on what the definition abandoned orders is. so actually if we removethat question then how many orders been placed? what’s the total value of orders? Which region, are they being ordered from and where’s the growth and channel happening?
[00:16:55] then we could probably remove three of those events for now. But then the next question I’ve got is [00:17:00] we talk about a question of answering what channel is driving growth. Now, if we have more channels in stores, then potentially we are missing some core business events, So again, I use it to triangulate the business questions to the events and just see if we are missing anything really important.
[00:17:14] Tammy: that’s the interesting thing. While there’s boxes, you don’t necessarily work through them in any predefined sequence, except I think you do always start with outcomes and questions.
[00:17:23] I always start there. Then I work my way through and sometimes, depending on the way the conversation flows, you’ll be jumping all over the place andforming a picture of how it all hangs together. You do come back to the business questions and cross reference and validate them that
[00:17:35] Shane: way.
[00:17:36] and it’s not linear. You’re right. When you’re gathering this information, you are answering around. But I start with business questions first. unless somebody’s done it before. And we’ll talk about what happens about self-service filling outta the canvas and what happens when you work with somebody that’s seeing you do this process before.
[00:17:49] Cause I find that really intriguing. the last two boxes I’m gonna talk about, user stories and information product world. One of the key things about this when people look at them, is you can often put something [00:18:00] in either box, And that is okay. we just want some assumptions, some constraints,
[00:18:05] some of those other words that we use to understand the scope. for use the stories box, at the moment I’ve got, as a consumer, I wanna be able to drill down from the summary numbers to see the transactions that make up the numbers so I can scan for out low. Uh, as an analyst, I wanna be able to export the data so I can use it in another tool.
[00:18:20] And as a consumer, I want a single view of orders, regardless of the system the orders are captured in. So for all the agile practitioners out there, I am really bad at writing user stories, so don’t. Beat me up for the quality of those stories, . I’m just gonna jump across to Will Won’t, So that’s the last box.
[00:18:37] the information product will won’t, it won’t break down by customer or supplier type. It will include return products in the order value calculation. It will collect data from the website, the point of sale, the order management, the shipping management, and the financial management systems. And it will backfill data from the previous 24 months.
[00:18:56] those boxes we are using as scope statements. if I look and [00:19:00] user stories, there’s some data scope statements in there and there’s some feature functions of the data platform scope statement in there. and the world won’t, There’s some feature function scope statements in there and there’s some data scope statements in there again,
[00:19:12] I don’t really care which box they go in, it’s just the one that feels the most natural for. and we’re just trying to document some assumptions, some things we know that we’re gonna agree we won’t do, because if we tried to do them, this delivery gets too big we probably do in another iteration.
[00:19:27] But just not this one. So what about you? What do you put in those two boxes?
[00:19:30] Tammy: in the user stories,I tend to try and enforce the size of the information product down. I suppose if I think about my process and focus solely on the vision as in the, who is the primary user here, for who.
[00:19:43] and so I will look at the will won’t is what will or won’t do for that primary user. I and this is where this one is interesting cuz you’ve got your personas and information consumer who looks like for the chief revenue officer and the other personas interested of the data analysts.
[00:19:56] the user stories is where, who else is gonna consume this information [00:20:00] product and find some use from it that if I can help them get it, great, but if I can’t, that’s not my primary focus. My primary focus is on. That core userthe world won’t almost more important to me than the user stories.
[00:20:11] they’re almost like the good, nice to have. That helps me contextualize and it helps me understand who else might use it, which I think is slightly different to how you use it. Cuz what you’re saying is these are your personas who you’re delivering it to, or will be using the data product.
[00:20:24] Shane: user stories start off as a right. So I tend to use the persona terms and I use it as a way understanding the features or the things that are unique to each of those personas that we wouldn’t naturally do or have a cost. so in that example, I’d cross reference and says, Hey, if we remove the persona of data analyst, Then what happens? Will we remove the need to be able to export the data? if we haven’t built that capability in our data platform, we may be able to reduce the effort of delivering this one and get it out early. And here’s the blast radius, Here’s the impact. The analyst can still go into the dashboard,
[00:20:55] They just can’t get the data. So really the dashboards are a little value for them, but that’s the [00:21:00] trade off decision with the product. Is that valuable? Whereas if we go into the world won’t, and we’re saying we’re getting data from five different systems, if we haven’t collected that data, we know every data collection process is a nightmare and expensive and hard and lots of effort.
[00:21:13] so we are looking that we go, Oh, there’s five of them. does that really matter to the analyst? maybe not. Does it matter to the business questions we’re answering? Hell yes. which of those can we remove? we’re not forcing to remove it. We’re just saying each one of these we know is a big piece of effort.
[00:21:26] we’re happy to invest in it because you call the value conversation, You tell us what’s most valuable for the organization and then we’ll just tell you how long, which equals how much. And so it’s just a conversation,
[00:21:36] Tammy: yeah, cuz interest in the user stories, I almost never start them with a persona name.
[00:21:40] I almost always start them with, as a accounting manager, I want to be able to drill down, Cause I’m being very specific. I don’t know if it’s just a specificity thing. I like that. But it is more that specific audience because I know that person’s a consumer.
[00:21:55] it’s a little bit slightly different in the approach, but the intent I think is the same.
[00:21:58] Shane: You’re just doing it at a fine [00:22:00] agreeing, You’re saying you understand your audience and it’s not at a persona level, It’s at a more detailed level. So there’s a difference between,a finance analyst and a HR analyst.
[00:22:08] Tammy: In some ways it might influence how they consume the data, cuz they’re all consumers, but they might consume them through different applications potentially. Or they’ll have a different UI or whatever it might be. it really does depend on how much you get out of that first conversation.
[00:22:22] How much detail you put in. how much you wanna go into the detail here. Sometimes I think about those almost as exceptions criteria, they’re not exceptions criteria,
[00:22:29] This whole thing starts to form up what is almost the definition of done.
[00:22:33] Shane: I tend to focus on the won’ts in that section more than will, because in my experience, everybody expects everything to be done.
[00:22:39] and so it’s highlighting the things that won’t be done,won’t include breakdown by supplier or customer
[00:22:44] Tammy: type. So as you say those words, there’s a business question in, and it says, I wanna know orders placed by, and you’re like, Whoa. But hang on. We’ve just said no, we’re not gonna do that down here.
[00:22:53] like you said, it’s a conversation starter. it’s a useful thing to have the conversation around. And by putting a won’t statement in, more [00:23:00] often than not, because everybody expects everything to be done, the won’t statement actually forces that really good conversation about do you actually need that?
[00:23:06] we’re saying that’s a won’t, do you actually need it to achieve your outcome?
[00:23:10] Shane: and it’s a won’t in this iteration. Doesn’t mean we won’t never do it, it’s just we won’t do it in this one. and the same as the wills. The wills is the ones where I write them down in here where I know there’s a high amount of effort or uncertainty for the team.
[00:23:22] So we’ll include return products in the order value calculation, That’s a big red flag to say actually. What’s the business rule for that? How do we describe a return product? How does it infect the order value? there’s a whole lot of work that needs to be done on that business definition,
[00:23:37] The rule for that one. So again, we’re saying it has to be there. So we’re saying to the team, You’ve got some work to go and discover that rule and make sure you, we get it right and we test it and it’s for purpose.the won’t tend to go back to our stakeholder. Our product owners say we’ve agreed this is outta scope for.
[00:23:51] the wills tend to be the hint for the team of, here’s some big Nelly pieces of effort we’ve picked up, Let’s start worrying about it, like back full of data for the previous [00:24:00] 24 months. Woo. Bit of effort there to get that going. and that brings us onto our last box, which is the vision statement.
[00:24:05] this is grabbing, the for who statement that came out of Jeffrey Moore’s book, Crossing the Chasm. I tend to use it here as a way of creating a really short, sharp. sentence we could say in the lift that anybody could scan in 10 seconds and understand the core crux of this, this information product.
[00:24:22] the one I’ve gotten here is for the chief revenue officer who needs to optimize the investment in new stores and new channels. The Order Revenue Metric is a dashboard that can automates the collection and consumption of order revenue data to understand the total order revenue and where it’s driven from, unlike the current manual Excel process.
[00:24:40] four is typically quite. Quite focused. who’s the key person that would get upset if this wasn’t done. the who, What do they need to do effectively, And that is, it should be back to that outcome action, not the task at hand. the, we just put in basically the information product name and the delivery mechanism.
[00:24:59] That’s the [00:25:00] more businessy question stuff that we’re answering, what are we getting out of this? And the unlike is what’s currently happening? If we don’t deliver this, what is the current state that will survive? So what is the bad thing? so it’s typically things like currently manual process orinformation isn’t available or it’s too late.
[00:25:16] what about you? What are you put into that vision box and when do you.
[00:25:19] Tammy: same things, put exactly the same things. I do it at the same time as the outcomes and business questions. It’s really early on cause I wanna have a really focused conversation. About it.
[00:25:28] this is a really good example of that. Often what you’ll find is the person you’re talking to, so in this case, I’m assuming I’m talking to add on top, Who’s I’m assuming is like the information product owner. and they’re saying the chief revenue officer. I’m like, Really?
[00:25:39] Is the chief revenue officer really gonna be looking at this dashboard? yes, they’re the one who maybe owns that outcome. sometimes what I find is you’ll get the CEO who wants to, I’m like, really ? Is it really that person or is it someone slightly different that needs to own that outcome or cares that this thing exists?
[00:25:55] that’s an interesting one. Cause sometimes they get people trying to almost not pull rank, But I need this because so and so [00:26:00] needs it kind of thing.
[00:26:00] Shane: And for me, the four is almost the customer paying
[00:26:03] if we had one that was for the CEO and we had one for the chief revenue officer. And the chief revenue officer took both canvases to the CEO and said, Look, I really wanna do my one. Your one seems to have been prioritized before me and the CEO’s never seen that canvas before and doesn’t understand why this thing’s been prioritized.
[00:26:22] It’s gonna go badly, we shouldn’t pretend that somebody wants it unless we’ve had a conversation with them. I still tend to do these at the end because I find it easier, I find it easier once I’ve got all the other stuff to draft the vision statement and then use it as a. I give them just that at the end of it and say, Right here’s the vision statement.
[00:26:39] Did we nail it? I find that valuable and I use it in the prioritization process. I tend to write those out on cards and use that as a way of prioritizing the information product to be delivered next, backed by a canvas. But that is the one thing, It’s like the summary.
[00:26:54] We should be able to stand on a lift, say it in three seconds and people. Oh, okay. I know what you’re [00:27:00] talking about. Lots of questions. But I get it compared to another one.
[00:27:03] Tammy: while I do it first, it doesn’t stay the same . it’s like I said before, I bounce around a lot in this Once I’ve got through those first two boxes of business questions and outcomes actions.
[00:27:11] if there are three boxes that are must-haves in the first pass conversation with someone in here, it’s those three outcomes, actions, business questions, and vision for me. The other things I could. Harvest or do in a follow on conversation. But those are the three critical things for me.
[00:27:25] and that’s why I tend to go through them first, get a first pass and then go through the rest of it, and then come back and sniff it again. Say, does this still stand up given everything else we’ve talked about?
[00:27:35] Shane: And that’s because those three are the value conversation, Why are we doing this?
[00:27:38] What’s the value of doing this effort where the other boxes are helping us understand how big it is, where the boundary is, make tradeoff decisions, trying to get the cost down, the time down or the delivery early. that’s a good way of thinking of it.
[00:27:49] Tammy: the way I tend to prioritize perhaps is more around just the information product. Name. because when we’re thinking about the information product, we’re thinking about all three of those boxes at the same time. From a prioritization perspective. Plus the T-shirt [00:28:00] size, which I know this canvas doesn’t show, but I’ve hacked the canvas for myself and added a t-shirt size in it as well.
[00:28:05] I think that’s valuable, I think we should add that in. one thing I’d always encourage though is the T-shirt size never is disclosed at prioritization. I don’t believe we should be prioritizing products based on how long or how much it costs to deliver. we should do it around the value of the outcome,
[00:28:20] Shane: Is this valuable information for the organization?
[00:28:23] Tammy: I think I disagree with you, but I think this is a different conversation actually, cuz I think there’s a double pass prioritization process. There’s a pure value conversation and then there’s a, how much is it gonna cost me to deliver that value?
[00:28:33] And then there’s a, Is it actually worth me spending that money to deliver that value? It’s like that payback conversation.
[00:28:38] Shane: so we won’t do it on this one because then we’re gonna get into the whole, your estimate for how long is just s anyways, so don’t use it.
[00:28:45] I wanna close this one out with this idea of still service, one of the things, I’ve seen that gives a lot of value to the canvas is this, first of all, this idea of a quick. I can walk into an organization, I can pick up a canvas that’s been well done, and I can [00:29:00] understand the boundary of that canvas,
[00:29:01] what it isn’t, what the intent of it is by just reading it, that shared language is highly valuable across both your development team and your stakeholder teams, but the second one is this idea of self-service. So what I’ve seen in lots of organizations is once You’ve gone through and done this canvas with somebody for a while talking them through it to get the input that you need to fill it out. if they need to do them in the future, they will tend to just pick them up and have a go themselves and then bring that to the conversation, which shortcuts the time,
[00:29:28] It means they’re starting to Think about, what information you need to get this thing filled out to continue the process. And that’s because it’s actually not that hard, we all we’re doing is eliciting the information outta their head anyway. And so after a while they just get it and they will just pick it up and they will just fill it out.
[00:29:43] they do a good job. Sometimes they don’t, but it’s, it’s a good starter for team. that idea that, people can self-service their information early and help them with their thinking, I think has a lot of value as. What about you? Yeah,
[00:29:54] Tammy: yeah, totally. We’ve had, we’ve, we’ve done that before and we’ve actually had examples where I’ve come across the [00:30:00] IP canvas somewhere in the organization I’ve never even been near before, and somehow it’s magically morphed its way across because it’s a useful way to describe an information product, and it’s something that people pick up and will use to help elicit information and share information with.
[00:30:16] What’s interesting sometimes is people turn up with a completed information product canvas and be like, Sweet, so I’m in, now my thing’s gonna be built . And so it’s almost that conversation where actually this is the beginning of the conversation. Not,I’ve unlocked.
[00:30:27] The next level and I can get my thing built. that’s an interesting behavior that you see. I’ve seen it a couple of times, not often, but a couple of times.
[00:30:34] Shane: and also it’s not a requirements document and it’s not locked, It’s just the beginning of the conversation.
[00:30:38] We need more detail for the team to be successful when we will need to make changes as we learn more. information. Product Canvas are kind of 1 0 1, Going through each of the boxes. and the next one, I think what we’ll do is we’ll pick this one up again, and then both you and I can be brutal.
[00:30:51] I wrote it,it’s probably gonna be more you than me, but let’s. Pick it up, give it a bash. let’s figure out the things that we would normally scan for that make us worried about [00:31:00] this information product, Things we go, Oh, that makes me suck my teeth. Let’s have a look at that one. And why,
[00:31:05] when I wrote it, I left some little fish hooks in there that I’ve seen before, in some of the campuses that, that always make me go. we’ll rip into that one next. another great session. hope everybody has a simply magical day.
«oo»
Stakeholder - “Thats not what I wanted!”
Data Team - “But thats what you asked for!”
Struggling to gather data requirements and constantly hearing the conversation above?
Want to learn how to capture data and information requirements in a repeatable way so stakeholders love them and data teams can build from them, by using the Information Product Canvas.
Have I got the book for you!
Start your journey to a new Agile Data Way of Working.