Join Shane Gibson and Tammy Leahy as they discuss what the Information Product pattern is and why you should use it.

Read along you will

 PODCAST INTRO: Welcome to the “AgileData” podcast where we talk about the merging of Agile and data ways of working in a simply magical way.

Shane Gibson: Welcome to the AgileData podcast. I’m Shane Gibson.

Tammy Leahy: And I’m Tammy Leahy.

Shane Gibson: Hello, Tammy, good to have you back on again, we had an awesome session last time, where we went through all the stuff you’ve been doing at your organization around scaling, and what I say almost data Michigan without data Michigan. So look, I’m glad to have you back on, we’ve decided, we’re going to do a little series, some more around patterns and things that are able to be implemented. So literally, across the top and a little more deep dive into what the buzzcut. So we’ve talked about doing information products, because it’s something we work together on. And both of us have been working on since then. So what I thought we’d do is we break them down into short, 20, 30 minute session, we chunk it down into a series to keep us to that timeframe. And for this one, we’re going to kick it off with information products. What are they? And why do we give a shit? Why would we use this pattern when we’re doing the work? Let me start out with my pitch on, what is an information product and got to do this without deep diving into the moving parts, so well at the core, what it is? And so for me, it’s a way of describing a boundary. It’s a patent we use to describe a boundary, for data, for code, for an outcome, for the analytics, all those moving parts that we need to deliver value to our consumer. And we use it to describe that boundary because we want to reduce the amount of work we have. So we can deliver it as value to that consumer and give feed. So we’re just using it as a way of breaking everything we do, down to a manageable boundary that can be agreed with those stakeholders and then delivered in as few iterations as possible. So for me, that’s what an information product is. It’s a pattern to enable us to reduce the amount of work we’re going to deliver, in an iteration, still have a conversation that has value and get it done. What about you? How do you see an information product?

Tammy Leahy: So I agree with you that it’s a bound of some description, completely agrees that and I think that I would probably focus least on, so that, it can be delivered in as few iterations as possible, because that there’s value in defining an information product or a data product that’s quite big, and then breaking it down. So you’ve got to be better picture of actually, this is the place we’re going to, at a macro level, because your boundary can be quite large. If you’re thinking about a series of things that deliver to a giant data product, which is comprised of multiple tables, multiple moving parts, that can take multiple iterations, several months, years, potentially to develop, that’s useful to understand that big boundary, but then I agree, you want to break it down to something that’s more consumable or deliverable, so that your consum it, can get the value from it as quickly as possible.

Shane Gibson: I think you raise a good point. So the boundary, the iteration, we think about is often based on the time horizon we’re thinking about, so let’s use a real example, time value. So we go okay, we’ve been asked by the organization to deliver a lifetime value, it has some value to the organization. And we know that as a big piece of work, we know there’s lots of moving parts, probably more than one system to capture that, we did get data for all, probably a few metrics. So we need some revenue, we need some profitability, we need some margin, we probably need some segmentation. We need some churn, there’s lots of stuff that we have to do to deliver that lifetime value number. And so we know that’s a lot of work. We have this big information product that says lifetime value, and we look at it and we go two to three years worth of work, but then we want to break it down into smaller information products, we go, okay, we’re saying to our stakeholders, give us a couple of years, and we’ll come back with that lifetime value number, that is bad behavior. We don’t want to do that. But we can decompose it, we can say, Look, if we gave you revenue numbers early, would that have some value? Why we use it to build out this lifetime value? And typically the answer is yes. So then we decompose our big information product down into smaller ones, and we just keep breaking them down into something that’s chunkable, that we can deliver in a small number of iterations, while still keeping that big picture in our head.

Tammy Leahy: Yes and how you choose to break it down could be different. So you could choose to break down lifetime value as an example, man, you’re totally playing to the account number here. Lifetime value can be broken down by revenue, cost, whatever you like, or you could choose to slice it, I’m thinking of it vertically. So you could slice version of lifetime value that’s completely usable for you, except that you’re going to give away some quality, when it comes to, I don’t relate to the cost side, because that data is harder to get. So you’re going to proxy that in was just a flat file or something simple, so that you can deliver that value outcome. Because maybe consumer cares about the holistic picture, even if the quality is not as good as what it might be differently. So the value in an information product is it’s an artifact or thing that you can use to have a really useful conversation about what do you care about most, for us to get on to, for us to help you with, as opposed to like, just give me lifetime value. And actually, there’s no conversation and encourages that two way conversation. And it enables the technical teams or the people, who have more knowledge about the intricacies of implementing these things, to influence how an end user or a consumer or product owner might think about that product, which helps educate them as well. The why behind it’s a bit of that? It helps us align on something, but also it helps us get a mutual understanding and create good tension around actually, is that really what you want, if that’s the outcome you’re trying to achieve? Because for me an information product is not just lifetime value, and why do we want it, so what behind it? There’s got to be a value outcome attached to it. So if we can understand that value outcome, and then we can help the people who are going to then execute it or chunk it down or whatever, understand that value outcome, you’re probably going to get a really good, maybe tense conversation, but a good conversation about actually is that the right way to achieve that value outcome because sometimes an information products, and I know when we’re still saying about the watch, we’re not going into the house, sometimes information products will include things about the specifics of the how it should be done, not purely the what and the value outcome that we’re trying to achieve. Within that bounded frame. Whether it’s a time bound, or whatever you’ve chosen to do.

Shane Gibson: We’re going to deep dive into the makes up an information product. If we’re creating a boundary, what’s important, how do we define those things, and one of those sections as well will have, won’t have and there’s a great example for you. So you’ve found a way to say when we want to break up lifetime value, there’s actually two different ways we can decompose it down, there’s two different ways we can find those boundaries, we can do it as the moving parts of lifetime value, the revenue, the margin, the profitability, the churn, or we could just then slice it all the way through and use a different way of bounding it. But they have two different value propositions, they’re two different trade offs. And so we have to be clear which one of those we’re using to create the boundary, talk to our stakeholders, and you say, here’s what you’re not getting, and the first cut, because you’re going to get it eventually, you’re just not going to get it first.

Tammy Leahy: Yes, but actually, when you break lifetime value down, if you’re doing that, you’re going to break it down into its component parts, like revenue and cost, those are actually different information products, they are not lifetime value. To me, if you’re going to break lifetime value down into a simplified, faster to deliver version of lifetime value, then that’s lifetime value. But if you’re going to deliver me, because this is the trade off I want, I’m really interested in revenue first, if you can deliver me revenue as an information product, that’s an revenue information product that’s not lifetime value. However, that will build with all of those other components to a lifetime value information product over time,

Shane Gibson: That comes back to how we use those information products and where we use them. So when we talk about prioritization, and we’re looking at time horizon of next six months, next year or two, next five years, then the size of the information product, the boundary we’re describing for that longer term horizon can be bigger. Because it’s saying, Okay, there’s a whole big area we want to investigate, and is that the priority right now, as we get closer to that information product, be ready for a team to start building, it should be more fine grained, the boundaries of be more defined, so they know exactly where they start, and where they finish that one, and where the next information product gets picked up. Because it’s the change of the information product for that team that allows everybody else to make a change on focus, change on strategy, change on what’s the next most valuable thing to build. And so that’s where we want to agree, we sometimes are bigger information products, because you’re just a way of getting a really good requirement or idea down on paper, or digitally. But we’re not going to break it down because it’s not being prioritized to right now. And we’ll talk about that when we do the session on prioritization and different ways, that this adds value to it.

Tammy Leahy: Yes, so if you were to use an analogy, a meager information product could also be described potentially as an epic, if you’re thinking about more traditional terminology, and then a component of that mega information product, which the way we like in theory, and information product is a beautiful concept, because it can scale to any size you want it to scale to. And yes, that’s a beautiful thing, because then you’re not constrained by that’s not an epic or a feature or whatever it is. And that encourages a good conversation about that, actually, what are the trade offs you want to do to get to it? So actually, I like that. What I don’t like about it is that sometimes you have to explain to people, actually can be any fractal. It can be anywhere on that scale, which then makes it slightly harder. Yes. So if we’re talking about Amiga, like this level of Amiga One, then you’re probably at more like an epic level, if you’re talking about something we can deliver in the next sprint, let’s say that you’re probably more at the feature level, I don’t mind that it’s different because I think there’s value in the difference. It’s just helping people understand who don’t deal with data all the time. That’s actually what you mean. Because we’re I find that the concept of an information product falls down sometimes, is information products, they’re always customer facing your customer, isn’t necessarily the customer of a business in a traditional product management sense. So that’s where you get a little bit of confusion potentially about, but why do you have an information product? And why would you have a product owner for that thing, if it’s not delivering to the customer, which I disagree with, i think that a customer is anybody who’s going to create value from the thing, will get some value from the thing that you’ve built. And that could be an internal customer, or it could be another development team, we should talk about this two different types of information products, maybe I didn’t really think about that mega versus minor information products or components of a mega refresher product.

Shane Gibson: So either exactly, same problem with epics, if you go into different organizations, the size of the epics are different. Some of them are very large, they’re large pieces of work that six to 12 months. And some organization and Epic is something that’s one iteration, it’s tiny. And so same thing, same problem with information products, as defining that boundary, is that can be big boundaries. And they can be small boundaries, but they have to be the right size boundary for what you’re going to use it for. So for me, it’s just about getting that sizing, right, what we do, in the information product Canvas is, we put t shirt sizing on it small, medium, large, extra large, extra extra large shirt.

Tammy Leahy: Then even that’s different. So the key thing is whatever your context is, you’ve got to be clear about the language you’re speaking. So when I say this is an extra large information product, it’s going to take me three months, or whatever it is. And that might be different depending on the organization you’re in or who you’re working with. And that’s where, actually, that’s okay. I don’t think there should be a prescribed way of saying a single information product must be able to be delivered within a single iteration. I think that’s unhelpful. If we working to that, it’s not prescriptive in that way.

Shane Gibson: But you have to get a shared language in your organization, for the reason we put their sizing on the canvas so that somebody can look at it, and they can understand the boundary, you’re thinking it. So if it’s extra large, and you’ve said that a time horizon of one to two years, is that kind of size, then I can look at it and I can go extra-large. That’s a long term time horizon information product. If I look at one and it says it’s small, I’m going to expect that could be delivered on iteration or two, whatever your context is.

Tammy Leahy: Interestingly, how have you dropped that concept of an OS like an outsize, which basically is do not even ask me to put a time horizon on it, because it’s so massive. That’s like their big conceptual level. I call it outsize.

Shane Gibson: Out size, that’s probably below that, but thank you, we’ve captured that as an idea, and it’s an information product, but we’re not going to fill a lot of the detail out, we’re not going to start breaking deep boundary down. Because it’s so large, that actually, you need to tell us that it’s now a focus for the organization. And then we’ll start decomposing it down into smaller boundary, smaller information products and make it up. But we’re not going to do that work until that one gets identified as the next very large priority for the organization.

Tammy Leahy: I would argue that you shouldn’t even be defining an information product, if that is not a priority for your organization. Because by doing that work, you’re potentially wasting time, if you know that you’ve got an organizational priority that requires that you deliver some version of lifetime value that says keep with the same example. You’re going to spend time even if it’s massive, even if it’s always you can think about what that means, and how you then might start to break it down. So you choose to do even use the most important, but that’s still always potentially depending on your context, it’s still outside, you’re then going to focus on not write down lifetime value. I am going to break down revenue. And I’m going to break it down into three different subcomponents. And I start with component one, let’s say. But if you start thinking about I now want to work on, I don’t know, what’s another good example.

Shane Gibson: I will give you an example. So let’s take lifetime value is one example. And then the other one is we’re about to acquire another company. And we’ve got a merger and acquisition problems, we have a whole lot of work, migrating all that data to give us a single view across those two organizations.

Tammy Leahy: I suppose its different data products, where I was going with was lit, you haven’t even got a priority in your organization to even understand toothbrushes. So don’t even bother touching that outsize data product. There’s someone straight up about what if we sold toothbrushes, don’t even touch it. So to me, that thing of it’s going to be a priority. And in this case, you’ve agreed to immediately say that’s a priority as much as lifetime values of priority. You’ve just got to prioritize them against each other. Useful to have that.

Shane Gibson: So I would argue that we still create the information product, we just do, work on it. When somebody comes up with an idea. We give it an information product name. And then if it’s not a priority for the organization, we pack it in the backlog and don’t touch it. And the reason I do that, is because when the idea comes upgain in three weeks time from that person or somebody else, we point and say that information product that boundary has been captured, but it hasn’t been prioritized in the organization, we can’t align it with the strategy as the top priority, we can’t align it to an OKR, we can’t align it to some funding for a program, there’s no incentive or priority in the organization that says we should work on even breaking that one down next. But that word been there, we can point to it and go, there’s a thing, and it’s got a massive boundary. But there is no point in us, working on breaking.

Tammy Leahy: Yes, it is a sign, is even just thinking about the thing means you’ve expended some effort, you may as well document the effort, you’ve expended in some form, save it for later, at the bottom of the backlog because it’s not a priority. I’ve actually got examples of this, where we did something, we had to think about it, we spent probably about 25 minutes thinking about it. We wrote it down in a Word doc, not in the IP Canvas template, because it was literally just thoughts on the page, because we were asked to, it was a priority at the time, what was supposed to be a priority at the time, actually, something more important turned up, we didn’t work on that thing. And get this after a half months later, we are going to work on that thing. So we’ve gone back and dug up that thing we worked on leaving a half months ago. And that gave us a starting point that was useful, that we didn’t have to start from scratch or reinvent the wheels, actually, it was helpful. So I agree with you in that sense.

Shane Gibson: Coming back to the other point, the idea of an information product may produce a dashboard, a report, a data feed, a data API, data sharing of some data with an internal or external organization, some visualization and analytical machine learning model, an analytical notebook, there’s a whole lot of different outputs. Often when we describe what something is, describing what it isn’t, is helpful as well. And so what I’m doing now, when I’m coaching people was I talk about information products and information apps. And for me the information app, the information application is the actual thing that a consumer users to get access to data or information. That’s the thing we build and we give them and the information product is just the boundary we use to describe all the work we have to do to get that app out the door. I’m using that now to differentiate and an information product may produce a dashboard app or a report app or an API app. But the apps the thing, information product is the way we start describing the boundary that produces that thing, because we have that Agile problem. And we’ll discuss this in another session, around an information app can often use the data from that we’ve done before that was created by a different information product, the different boundary, and we just reuse it. So now where does it set?

Tammy Leahy: That’s exactly what I was going to raise. Because for me, I get what you’re saying. And that’s if it’s the language issues cool. I actually don’t use the word information product anymore, I use data products, you could use information product, I’m indifferent to the language as long as it’s shared and understood.

Shane Gibson: And I’m not. So I think the market has data Products, data as a product. And the other thing I’ll argue is the definition of a data product is something that a data literate person will use to get access to data and do something else with it, it is not something that is delivered to an end consumer and does not provide information.

Tammy Leahy: Something that an information consumer will use?

Shane Gibson: A data consumer.

Tammy Leahy: So what’s the data consumer?

Shane Gibson: Data literate person, so an analyst an engineer, a data scientist, data products have been boxed into somebody who produces data, that somebody else will use, to serve a consumer? And for me, that is a good definition.

Tammy Leahy: Okay, so I actually encapsulate those within the the superset of information products. And that’s going to think we’re different. So I say that an information product or a data product, and I use the names interchangeably, and I get really like, maybe you shouldn’t, I use them interchangeably. I know you don’t like that. So what is understood where you work and the people you work with, and if that’s understood, cool, if I have to change how I think about what speak about it, when I talk with other people, cool, that’s fine. It’s like when I got to the UK, and I want to talk about chips, I’m going to get hot chips, not crisps. And when I’m in New Zealand, I’m going to talk about chips. And I’m going to get crisps, not hot chips, I’ll adjust my language depend on my context. Anyway, that aside, we can argue about content semantics with days, the way I think about data products, information products, is actually a consumer is a data literate person, who is using that information to deliver value of some description, because for me, they are going to have outcomes they wish to deliver to and I know that by providing them with an information product, that they’re going to run a query off of do some manual or ad hoc analysis on, that in itsef is going to lead to a decision that has value and this is I think, where we have a big fall down. We only value those data products that we provide to an end consumer, not where we can actually say in this is that X, Y, Z, add value from it. We don’t value those data products or information products that are data literate person will consume to then provide to another person. Good example, analysts will use a table that’s got revenue in it, to make some decisions about whether or not we should start offering a product in a different region, let’s say, because they have some market data that says X, Y, Z, at about X, Y, Z, region for revenue, that might inform a decision that someone else is going to make, a different consumer is going to make, based on a report that they prepare or a dashboard that they do, to visualize that information with a recommendation that has value. And this is where I think we fail, we don’t value that decision that’s been made, leveraging that data product using your terminology, because it’s not an information product. So for me, I think everything’s an information product that is used to deliver value. And it’s just how you choose to contextualize it. Because for me, a table that an analyst is going to use, to do some analysis on to make recommendations that will drive action and create value, is an information product.

Shane Gibson: Let’s go back to the definition of information product being a boundary, a way of describing a boundary. So a subset of an information product, something we produce, using the information product boundary could be a data set, or a data product, which is served to a data analyst, who then does something with it, to then serve a consumer, we’re going to build a bunch of tables. And we’re going to make them accessible via Python notebooks. And then the analyst is going to go in and use the Python notebooks on top of that data, to do some more work to see if somebody else is going to take some action that gives us an outcome. And I have no problem with that. But the key thing is that definition of the information product then is, that boundary that we’re going to stop the work at the production of those tables and making those tables accessible to that analyst persona. And then we’re finished or are we actually going to say that the boundary to the information product is all the way to the end consumer. And therefore the analysts work as part of the boundary that we have to deliver.

Tammy Leahy:  I think it depends on your purpose for defining an information product, if your purpose for defining information product is as coming back to the beginning, so that I can understand what I can deliver within a particular time horizon cool, then I care about who delivers the information product. However, if your concern for defining information product is, so that you can measure the value you deliver with whatever the information product is, arguably, you don’t care who delivers it, you don’t care if it’s your team that’s delivering that information product, then the analyst is going to consume it, yes, that information product in itself has value because the analyst is going to consume and create value, and about 50 Other analysts are going to do the same thing, let’s say, then whatever the analyst has generated that report, that insight, that thing, that is an information product that someone else is going to consume, to generate that in itself will generate value, the way I see it is and it comes back to that point of view can then make an information products, you can micro information products, information products are not restricted to the (inaudible 22:48) teams or analytic squads, whatever you want to call them that deliver it. It’s a model, it’s a data services or whatever, that can be used to deliver value of some description. And so for me that whole and it’s delivered via is irrelevant. I only care that it’s something, it’s an entity or a component, that I can say that thing equals that value. Because then when someone says to me, why do we bother with that information product, i am like because it’s delivering that value. Because when it comes to those conversations, I’ve you’ve got all these zombie, binders, running app, you shouldn’t have so many pipelines running because you know exactly what information products are delivering what value and why you care to keep them or have them. Because for me, there’s the build part of it, which I think is what you’re talking about. But I also care about the so what after that.

Shane Gibson: Later on, we’ll talk about the information product canvas and when you should use them, when you should update it. One of the areas, I see great value as an as built document, where we’ve actually finished doing all the work. And we’ve now defined what was built within that information product boundary, we can treat it as a thing that needs to be maintained. So we can tell when something can that needs to be changed by an outside force, that boundary of the information product doesn’t stop once we’ve delivered it, because we can use that boundary for more value going forward. I hadn’t thought about using it as a way of proving the value to the organization of the work that was done, what value was our organization getting from that data and information work that was done a while ago? Because it should keep adding value or we should decommission it.

Tammy Leahy: Thinking about it does have value as an as built but I think depending on who’s consuming it, as well as built, because for me, it’s almost more like a product box. It’s at that level that a consumer is going to use it, as also that’s what that thing means. Versus like for us, (inaudible 24:30) are a little bit more details on that obviously. I think your audience for the as built is different because personal information product, you’re probably into a bit more of a detailed design than you would be working on as part of the work that you do to deliver it.

Shane Gibson: Yes, definitely. But still there detailed design still tagged or flagged back to the information product. That was the boundary that started their work. For me the boundary is key. And so again, one of the sections we talked about in the canvas is persona, who is the persona that’s going to get the value out of this information product, who are we targeting, and that’s where we see very clearly, if I pick up an information product canvas, I can see it and see that the target is an analyst. So I know where the boundary is logically, or the target is a senior leader or machine leaning model. And I know the boundary of that information product by just reading that persona section. I can see how big or small it is.

Tammy Leahy: It’s not just persona, though, it’s also helpful sometimes this persona, you’re an audience, because sometimes you might have a persona that’s an analyst, but they know the domain really well. You’re going to deliver them something slightly different than you might have persona, who’s an analyst, who doesn’t necessarily know the domain very well, that might influence slightly how you choose to deliver it.

Shane Gibson: That’s a good question, what type of framework of novice apprentice practitioner and coach as a way of measuring skill level.

Tammy Leahy: This is not analytics skill level, this is business domain knowledge. So for example, if you have to encounter certain systems that are using weird languages in them that call Customer some random four letter combination of consonant, if I’m an analyst, I understand that domain, I don’t care. I know that’s what that means. I don’t have to convert that into a language that an analyst who doesn’t know that domain coming from, say, domain, there might be like, What the hell is this four letter arrangement of consonant, I might need to do more work to convince them something more useful for them. So that helps me understand as an audience, there’s a slightly different requirement here, at a high level, because I don’t want to think I was part of my IP canvas, stating that for this field, call it X, Y, Z, I don’t want to be doing that in the IP canvas. So that’s why I think about that audience is helpful, but then also the frequency. I don’t know if you still use it, but the data product type, what exactly is, this is a model? Is it a dashboard? Is it a report?

Shane Gibson: This one error we don’t cover, we don’t bring in any form of complexity into the canvas.

Tammy Leahy: Not true, because you do not cover and your T-shirt sizing.

Shane Gibson: We already agree but not anything that’s useful. We don’t know that the size is large, because it’s the first time we’re going to read the source system, or the domain understanding is low. Or we know that sources system or capture is so horrible. Like the one you mentioned that it’s always hard to use that data, we just know that it’s not small, we know there’s something in there, that’s interfering, it’s more work than a small, but we don’t really ever put the lens on the complexity. But we do their pre work, we often think about where the gnarly things are, as we start bringing it closer.

Tammy Leahy: This is where we thought about this IP Canvas actually, we’re thinking about iterated on it slightly. And we’ve already done it to an extent, it’s got that, so what is this? What is the business value outcome? What’s the vision statement? So who is your primary user? And why do they care about it, and that then gives you the almost semi acceptance criteria, and then this will or will not deliver XYZ and there’s a section around the additional users or user stories where this is useful, because it helps with the context of, so if I’m thinking about building this, I need to consider these user stories because they might need us at some future point down the line, the boundary context of audience user persona, frequency type. And there’s also the business event sometimes that helps with complexity still in that.

Shane Gibson: I do. And then I bought SLA with the service level, or the expectation of when this data would be available.

Tammy Leahy: I call that frequency, similar thing, well, actually similar, but different, then the same that we thought about doing now is you potentially have one or two more pages attached to it. One, which is, if it’s like a dashboard or something, you’ve got a wireframe, and in some cases, get this, we’ve done wireframes with post it notes, so you can move them around and taking a photograph of it. And that is what we attached to that second page, because it’s just what it was good enough to convey the message of, this is what we’ve talked to the user about, or the consumer about. And then the second thing that we’ve been thinking about is actually, maybe you need to do a very high level conceptual diagram of the data flow. So I think it’s going to be these systems. And actually, I’ve done this. I’ve done exactly this, I’ve had three pages where the first one is the canvas. The second one is like a very rough hand sketched on a whiteboard wireframe. They’ve taken the photo and put on. And then the third page has been again, hands sketchen whiteboard, taking a photo of and chucked in high level data flow. It shows me the systems involved, big question marks and places and it’s not gospel, but it’s, if you’ve had that conversation, and typically when I talk to someone about an IP canvas, I’ll go through some of those things, you’ll start to get a feel for some of that stuff. So just put it in, so you don’t lose it, is how I think about it.

Shane Gibson: That’s good. That’s an area we can talk about, because you are having lots of conversations, you are bouncing all over the place as you define these things, to find those boundaries. So the idea of supporting pages as well, you’ve already got some context, sketch it out quickly, working on that has value, don’t over bake it. And then you’ve captured some context that support some of the things, some of the errors on the canvas that is the context make sense. So that’s a quick half hour. And you’ll seek quite nicely into the next one we need to do which is, what are the sections on the canvas? Why do we fill them out? What value do they have? And then no doubt, we’ll jump into the how do you populate each of those and what’s the techniques? So if we come back to, what is it, why is it defining a boundary? And there’s a whole lot of complexity in there, depending on your organization and the way you want to break things down. Why do we do it? Because it’s a way of defining a boundary. And we can use it to figure out what’s next we can use it, to agree with our stakeholders, what the boundaries are, what we will and won’t do, in the first go at, we can understand the complexity of those boundaries, to help us understand how much work needs to be done, we can understand the personas, that are going to be using it or not using it. So we can agree, we’ve understood that through our audiences, there’s a whole lot of things allow us to create boundaries, that get that value out to that stakeholder early, and we get feedback before we do some more work.

Tammy Leahy: And have to at the end, it allows us to come back to it and assess whether or not we’ve actually delivered that value in the way we thought we would.

Shane Gibson: Now that’s the one I always forget, have we delivered our promise or our commitment or has something changed? And we agreed that change, which is fine. Change is as long as we all agreed to change, and we were the consequences of that change. So yes, you’re right. It’s a way of it, at the end of it, closing out and saying, here’s what we thought we were going to build. And we had agreed that and here’s what we built. And we nailed it.

Tammy Leahy: And is that value over time? Are we still tracking that value over time? It’s a way to bind your value descriptors for data.

Shane Gibson: Excellent. That was a good starter. I look forward to the next one in the series. We just chunk it down and we create a boundary, time box and a forcing function and then we make sure we have reduced the content to fit there. So on there, I hope everybody has simply magical day.