The Information Product Canvas with Tammy Leahy

Welcome to the Agile Data Podcast, where we talk about the merging of agile and data ways of working in a simply magical way. Welcome to the Agile Data Podcast. I'm Shane Gibson.

And I'm Tammy Leahy.

Hey, Tammy, good to see you again. So last podcast, we went through information product, what they are and why we should care. And for this session, we're going to go and jump in and have a look at the thing that we call the Information Product Canvas. So we're gonna do a bit of what is it, what's in it, why do we have those things in it? And then after that, we'll do another recording directly after it, which is where we get the example we've got and we rip 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. Before we rip into that, if anybody wants to look at the canvas, we've gone and done an example. So if you go to agiledata.io/ipce, it'll take you to a copy 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, and you'll pretty much see that you can't work in the agile world without creating a canvas to get you some street cred. 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. I had all the same information, a little bit more detailed, and we use that a lot to create those boundaries that we could use. So 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 Kore and his BEAM methodology. 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, agiledata.io/ipce, and have a read along as we pull this one apart and say what's in there. 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. What we are looking for there is if we deliver this information, what action will be taken from it? And once that 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, and we use it for prioritization and a whole lot of stuff we'll talk about later. So in there right at the moment, rough example is we've got an information product called Order Revenue new metrics. In the outcomes and actions box, we've got our outcomes to increase overall margin, and the action our stakeholder expects to take is to use the information to optimize the investment in new channels, optimize the investment in new stores, and reduce the number of abandoned orders. Tammy, give me a starter for 10. The outcomes and action box, what do you normally put in there and how do you use it?

Similar, you want to be clear on what action people will take. So, what's the outcome that's going to be achieved from the data product or the information product? I like to get a bit more specific. 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 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. So assign a dollar value to it, assign 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 that outcome and actions box of actually make it specific and measurable so that you can test whether or not the information product's achieved what you set out to do.

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 a massive amount of information products being 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.

Yeah, I think that's part of it. I think part of it though, as well as you want to start as you intend to continue. If someone approaches you and says, build me this thing and you say, we're coming on to the next box, actually, what is the question you're trying to answer? 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 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. If you're not doing that, you shouldn't be doing something else.

So, an anti-pattern 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're just exploring it, which may have value, but 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. It's just that how do you measure it? What is your measure of success here?

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 kind of things. That's a harder one to quantify. So let's go to the second box, which is business questions. So in there, I've created ones of how many orders have been placed, what is the total value of orders placed, what is the percentage of abandoned orders, what store regions has the most orders, and what channel is driving the largest increase in order value. 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 3 to 5 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. What I find is that question is typically the one that gets answered quickly and well. 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 going to take. 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'll say, What actions are you going to 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? So how about you? How do you use those business questions? And that's it.

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 to understand where they're at as well, where the person asking the question is at from an understanding of what's possible, how open they might be to 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 or how many and what questions are quite dashboard. And this is a dashboard example. They've shown 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. This is a different proposition here. Look out for what kind of questions they're asking and then how that might influence the type of information product we provide.

For me, it also becomes comes around level maturity. So often people have a latent demand where they just can't get access to simple how many, how much questions. But once you can, that's just their 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.

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? I almost want to 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.

And again, one of the reasons we do this is to understand the amount of investment or effort is required to get that value. 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. All right. Business questions typically get answered really well because they've been ruminating on them for a while before they, they come to you. The next one I tend to jump over to is this idea of persona. Understanding who's going to 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 an external information consumer. 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 or use or access it and what they want to do. In this case, we've got two information consumer and data analyst. And then when we talk about user stories and that later, you'll see how we see some value in defining those personas. We often want to see whether those personas have different business questions or if they want different content delivery types. So if I just jump over to that one, there's a box here 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. So what about you? Personas and delivery types?

I think that top right corner is all connected for me. Personas, delivery type, and data sync frequency, or how often they want it refreshed. Interestingly though, just looking at it now again, I'm thinking in personas, I also want to know more audience, but that's covered under the vision and user stories a little bit, because 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. You probably have revenue optimization or a store kind of analytics group that might be looking at this. But 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 out of that vision and user stories potentially.

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 or the revenue or the operations, then yeah, either create a new area into the canvas and whack 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 source, pick it up, hack it, put in the boxes that make sense to you because all you're trying to do is gather information that creates that boundary quickly for you. And same with 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 want to know. And again, often hard for people to give you an answer.

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 that 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 going to get every day, so daily refresh of information in this example before 7 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 of 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. And unless you're going to do that second page, for example, of a little quick wireframe, you're not going to get it out of them necessarily here. That's almost like a delivery SLA, like when is it going to be ready for me versus actually what is it going to show me? And so, I think they're just the two different things.

Yeah, when you're talking about that data sync or that when they're at, 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. There's a little bit of skill in saying, how many of those by variables are actually important for us to document right now? How many impact the boundary or how many do we just expect to be?

But equally, sometimes that they're like, I want it by half hour. And you're like, well, actually, given the outcome you're trying to achieve, you Is that going to actually make a difference to 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. It is useful to have that conversation.

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, I want half-hourly data, then we document that in the canvas. Then when we get closer to delivery and the team pick it up and they look at it, they go, right now we're recording data at an hourly grain. So, there's a massive amount of rework to do to bring that down to half-hourly. Then we have a conversation with the product owner 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 want to 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? And that's just a conversation to get that boundary.

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 with 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 2 pages. 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 or evidencing that conversation for the next step.

I often see that how many orders have been placed by store, by region, by time of day, by whether it was sunny or not. Those by variables often give us a lot more breadth on those questions. But if we talk about how many orders have 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. Which takes us to the next one, which stands out on its own and it's what I call business events. And again, this is following the who does what, BIM framework from Lawrence Kore that I use a lot. It's this idea of understanding the core business processes. The ones we've got in there is customer places order, customer pays for order, store ships product, customer returns product. There's 4 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. What we are looking for is those types of sentences because that'll help us in the future map back to the systems that capture, actually created that information. It'll help us look at other information product canvases we've 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 effort. It 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 effort required to deliver this. So what about you? What do you put in there for the core business events?

So very similar. It is core business events. I think it was like a process flow in a way. Because for me, if you start with the beginning of a customer places 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 and margin for stores, then I try and map the process to get straight in my head. Where again, data flows are similar to you, whether or not you use Beam, I think it's 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 to 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 states and you've got transactions and you've got all these different things. And it starts to help to form that picture for me. Agree about mapping them in this way, whether or not you use Beam, I think 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, because 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. 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 it's context you don't want to lose.

For me, that idea of core business concepts, that's really important. Again, if I look at those 4 customer places order, customer pays for order, store ships 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 them placing the order. 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 low effort. 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 return. And payment actually, and that is what's the percentage of abandoned orders depending on what the definition of abandoned orders is, right? So actually if we remove that question, then how many orders have been placed? What's the total value of orders? Which region are they being ordered from? And where's the growth in channel happening? Then we could probably remove 3 of those events for now. But then the next question I've got is we talk about a question of answering what channel is driving growth. Now, if we have more channels than stores, then potentially we are missing some core business events. So again, I use it to triangulate the business question to the events and just see if we're missing anything really important.

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. I always start there and then I work my way through. And sometimes, depending on the way the conversation flows, you'll be jumping all over the place and forming a picture of how it all hangs together. You do come back to the business questions and cross-reference and validate them that way.

And it's not linear. You're right, when you're gathering this information, you are bouncing around. But I start with business questions assumptions first, unless somebody's done it before. And then we'll talk about what happens about self-service filling out of the canvas and what happens when you work with somebody that's seen you do this process before, because I find that really intriguing. The last two boxes I want to talk about are user stories and information product world wide. Now, one of the key things about this when people look at them is you can often put something in either box, and that is okay. We just want some assumptions, some constraints, some of those other words that we use to understand the scope. Go. For user stories box at the moment, I've got as a consumer, I want to be able to drill down from the summary numbers to see the transactions that make up the numbers so I can scan for outliers. As an analyst, I want to be able to export the data so I can use it in another tool. 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 going to jump across to will/won't. So that's the last box. The information product will/won't, it will won't break down by customer or supplier type. It will include returned 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. Those boxes we are using as scope statements. If I look in 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 will won't, there's some feature function scope statements in there, and there's some data scope statements in there. Again, I don't really care which box they go in, it's just the one that feels the most natural for them. And we are 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 it in another iteration, but just not this one. So what about you? What do you put in those two boxes?

In the user stories, I tend to try and force 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, and so I will look at the will/won't as what will or won't this do for that primary user. And this is where this one is interesting because you've got your personas and information consumer who looks like for the Chief Revenue Officer and the other persona's interested in the data analyst. The user stories is where who else is going to consume this information 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 user. The will/won't is almost more important to me than the user stories. They were almost like the good, nice to have, that helps me contextualize and it helps me helps me understand who else might use it, which I think is slightly different to how you use it, because what you're saying is these are your personas who you're delivering it to or will be using this data product.

User stories start off as a, right? So, I tend to use the persona terms and I use it as a way of 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 it says, hey, if we remove the persona of data analysts, then what happens? Well, 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, they just can't get the data. So really the dashboards are little value for them, but that's a trade-off decision with the product though. Is that valuable? Whereas if we go into the will-won't and we're saying we're getting data from 5 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. We look in there and we go, oh, there's 5 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? And we're not forcing to remove it. We're just saying each one of these we know is a big piece of effort. 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.

Yeah, because actually in the user stories, I almost never start them with a persona name. I almost always start them with, as an accounting manager, I want to be able to drill down because I'm being very specific. I don't know if it's just a specificity thing. I like that, but it's more that specific audience because I know that person's a consumer. It's a little bit slightly different in the approach, but the intent I think is the same.

You're just doing it at a finer grain. 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 an HR analyst.

Minimalist. In some ways that might influence how they consume the data because 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, how much detail you put in, how much you want to go into the detail here. Sometimes I think about those almost as acceptance criteria. They're not acceptance criteria. This whole thing starts to form up what is almost the definition of done.

I tend to focus on the won'ts in that section more than a will because in my experience, everybody expects everything to be done. And so it's highlighting the things that won't be done. Won't include breakdown by supplier or customer type.

As soon as you say those words, there's a business question in there that says, I want to know orders placed by, and you're like, whoa, but hang on, we've just said no, we're not going to do that down here. 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 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? We're saying that it's a won't. Wonts, do you actually need it to achieve your outcome?

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. So, will include returned 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 returned product, right? How does it affect the order value? There's a whole lot of work that needs to be done on that business definition. 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 fit for purpose. The won'ts tend to go back to our stakeholder, our product owners say, we've agreed this is out of scope for now. The wills tend to be the hint for the team of here's some big gnarly pieces of effort we've picked up. Let's start worrying about it. Like backfill of data for the previous 24 months.

Woo-hoo!

Bit of effort there to get that going. And that brings us onto our last box, which is the vision statement. This is grabbing the for who statement that came out of Geoffrey 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. 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 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. For 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. That's the 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 or information isn't available or it's too late. What about you? What do you put into that vision box and when do you do it?

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 because I want to have a really focused conversation about it. 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 Addie, who's, I'm assuming is like the information product owner. And they're saying the chief revenue officer. I'm like, really? Is the chief revenue officer really going to be looking at this dashboard? Yes, they are 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? That's an interesting one because sometimes I get people trying to almost not pull rank, but I need this because so-and-so needs it kind of thing.

And for me, the 4 is almost the customer paying. 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 want to do my one, but 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, it's going to 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 test. I give them just that at the end of it and say, right, here's the vision statement. 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. We should be able to stand in a lift, say it in 3 seconds and people go, go, oh, okay, I know what you're talking about. Lots of questions, but I get it, compared to another one.

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— if there are three boxes that are must-haves in a first-pass conversation with someone in here, it's those three: outcomes, actions, business questions, and vision. For me, the other things I could then harvest or do in a follow-on conversation, but those are the three critical things for me. And that's why tend to go through them first, get a first pass, and then go through the rest of it and then come back and sniff at it again, say, does this still stand up given everything else we've talked about?

And that's because those three are the value conversation. Why are we doing this? 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 trade-off decisions, trying to get the cost down, the time down, or the delivery early. That's a good way of thinking of it.

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

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 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 or the outcome. Is this valuable information for the organization?

I think I disagree with you, but I think this is a different conversation actually, because I think there's a double-pass prioritization process. There's a pure value conversation. And then there's a, how much is it going to cost me to deliver that value? And then there's a, is it actually worth me spending that money to deliver that value? It's like that payback conversation.

So we won't do it on this one because then we're going to get into the whole, your estimate for how long is just bollocks anyway, so don't use it. I want to close this one out with this idea of self-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 review. I can walk into an organization, I can pick up a canvas that's been well done, and I can understand the boundary of that canvas, 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. 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. All we're doing is eliciting the information out of 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. They do a good job. Sometimes they don't, but it's a good starter for 10. That idea that people can self-serve with their information early and help them with their thinking, I think has a lot of value as well. What about you?

Yeah, yeah, totally. We've had, we've done that before and we've actually had examples where I've come across the IP cam 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. What's interesting sometimes is people turn up with a completed, like, Information Product Canvas and be like, sweet, so I'm in now, my thing's going to be built. And so it's almost that conversation where actually this is the beginning of the conversation, not I've I've unlocked the next level and I can get my thing built. It's an interesting behavior that you see. I've seen it a couple of times, not often, but a couple of times.

And also it's not a requirements document and it's not locked. It's just the beginning of the conversation. We need more detail for the team to be successful. We will need to make changes as we learn more. Information Product Canvas, a kind of 101 going through each of the boxes. In 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. I wrote it. It's probably going to 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 this information product. Things we go, ooh, that makes me suck my teeth. Let's have a look at that one and why. When I wrote it, I left some little fishhooks in there that I've seen before in some of the canvases that always make me go, pfft. We'll rip into that one next. Another great session. So on that, I hope everybody has a simply magical day.