AgileData #32 - Information Products - What and Why

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 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 dare I say almost data meshing it without data remishing it. So look, I'm glad to have you back on. We've decided we're going to do a little series that's more around patterns and things that are able to be implemented. So a little less across the top and a little more deep dive into the buzz cut. So we've talked about doing information products because it's something we worked together on and both of us have been working on since then. So what I thought we'd do is we'd break them down into short 20, 30 minute sessions. We'd 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 pattern 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 get feedback. 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?

So I agree with you that it's a bound of some description. Completely agree with that. And I think that I would probably focus less on the, so that it can be delivered in as few iterations as possible. Because I think 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 a better picture of actually, this is the place we're going to at a macro level. 'Cause I think 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 wanna break it down to something that's more consumable or deliverable so that your consumer can get the value from it as quickly as possible.

I think you raise a good point. So the boundary, the iteration we think about is often based on the time horizon we are thinking about. So let's use a real example, time value. So we go, okay, we've been asked by the organization to deliver lifetime value. It has some value to the organization. And we know that is a big piece of work. We know there's lots of moving parts, probably more than one system to capture that we need to get data from, probably a few metrics. So we need some revenue, we need some profitability, we need some 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, yeah, 2 to 3 years worth of work. Then we want to break it down into smaller information products. We go, okay, saying to the, to our stakeholders, give us a couple of years and we'll come back with that lifetime value number. That is a 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 that 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.

Yep. And, 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 accountant in me here. Lifetime value could 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, but you accept that you're going to give away some quality when it comes to, I don't know, let's say the cost side, because that data is harder to get. So you're going to proxy that in with 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 I think the value in an information product is it's that artifact or it's that that you can use to have a really useful conversation about what do you care about most for us to get onto, for us to help you with, as opposed to like, just give me lifetime value, and there's no conversation. And it encourages that two-way conversation, and it enables the technical teams or the people who have more knowledge about how the intricacies of implementing these things to influence how an end user or a consumer or a product owner might think about that product. Which helps educate them as well. I think 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. It's, 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. Conversation, but a good conversation about actually, is that the right way to achieve that value outcome? Because sometimes an information product, and I know we're still saying about the what, we're not getting into the how. 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.

I think we're going to deep dive into the what 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 is will, won't. 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 define 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 thin 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. Right, in the first cut, because you're going to get it eventually. You're just not going to get it first.

Yeah, 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 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're going to deliver me revenue as an information product, that's a 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.

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 6 months, next year or 2, next 5 years, then the size of the information product, the boundary we're describing for that longer term horizon can be bigger. Right? Because it's saying, okay, there's, here's a whole big area we want to investigate. And is that the priority right now? As we get closer to that information product being ready for a team to start building, it should be more fine-grained. The boundaries should 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 of focus, a change of strategy, a change on what's the next most valuable thing to build. And so that's where we want it. I agree. We sometimes end up with big mega information products because they'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 been 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.

Yeah. So if you were to use an analogy, a mega 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, an 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, oh, that's not an epic or a feature or whatever it is. And that encourages a good conversation about then 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 it can be any fractal, it can be anywhere on that scale, which then makes it slightly harder. You have to, oh, so if we're talking about omega, like this level of omega 1, then you're probably at more like an epic level. If you're talking at like a, something we can deliver in the next sprint, let's say, then you're probably more at a feature level. I don't mind that it's different, different, because I think there's value in the difference. I think it's just helping people understand who don't deal with data all the time, that's actually what you mean. Because where I find that the concept of an information product falls down sometimes is information products, they're always customer-facing, just your customer isn't necessarily the customer of a business in a traditional product management sense. So, I think that's where you get a little bit of confusion potentially about, oh, 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 or get some value from the thing that you've built. And that could be an internal customer, it could be another development team, We should talk about this too, different types of information products, maybe. I don't know what you think about that mega versus minor information products or components of a mega information product versus—

So I have the exact 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 are 6 to 12 months. And some organization, an epic is something that's one iteration. It's tiny. And so same thing, same problem with information products is defining that boundary. Is they 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, oh shit.

Then even that's different. So I think 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 3 months or whatever it is. And that might be different depending on the organization you're in or who you're working with. And I think 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 were to get to that. Like, it's not prescriptive in that way.

But you have to get a shared language in your organization for it. The reason we put that sizing on the canvas is so that somebody can look at it and they can understand the boundary you're thinking at. So if it's extra large and you've said that's a time horizon of 1 to 2 years, is that kind of size, then I can look at it and I can go, it's 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 in an iteration or two, whatever your context is.

Interestingly, 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 kind of like that big, big, big conceptual kind of level. I call it outsize. Outsize.

That's probably polite, but it is. It's, thank you. We've captured that as an idea and it's 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 that boundary down because it's so large that actually you need to tell us that's now a focus for the organization and then we'll start decomposing it down into smaller boundaries, smaller information products that 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.

I would argue that you shouldn't even be defining an information product if that is not a priority for your organization. Because just 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, let's say, to keep with the same example, you're going to spend time, even if it's massive, even if it's OS, you're going to think about what that means and how you then might start to break it down. Let's say you choose to then say revenue is the most important bit, that's still OS potentially depending on your context, it's still outsized. You're then going to focus on, I'm not going to break down lifetime value. I am going to break down revenue and I'm going to break it down into 3 different subcomponents. I'm going to start with component 1, let's say. But if you start thinking about, I now want to work on, I don't know, what's another good example?

I'll give you another 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 problem. So we have a whole lot of work migrating all that data together to give us a single view across those 2 organizations.

Yeah, I suppose that's different data products. Where I was going with was, you haven't even got a priority in your organization to even understand toothbrushes. So don't even bother touching that outsized data product that someone's dreamed up about what if we sold toothbrushes. Don't even touch it. So I think to me, it's that thing of it's got to be a priority. And in this case, you've agreed to a merger, let's say that's a priority as much as lifetime value is a priority. You've just got to prioritize them against each other. Useful to have that.

So I would argue that we still create the information product, we just do bugger all 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 park it in the backlog and don't touch it. And the reason I do that is because when that idea comes up again in 3 weeks' time from that person or somebody else, we point and say, that information product, that boundary's 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 being there, we can point to it and go, there's a thing, it's got a massive boundary, but there is no point in us working and breaking it down right now.

Yeah, so what you're saying 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 a page because we were asked to, it was a priority at the time, or it was thought to be a priority at the time. Actually, something more important turned up, we didn't work on that thing and get this, 11 and a half months later, oh yes, we are going to work on that thing. So we've gone back and dug up that thing we worked on 11 and 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 wheel. So actually it was helpful. So I agree with you in that sense.

Coming back to your 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, an 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 is I talk about information products and information apps. And for me, the information app, the information application, is the actual thing that a consumer uses to get access to data or information. It'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 app's the thing. The information product is the way we start describing the boundary that produces that thing. Because we have that age-old 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, a different boundary, and we just reuse it. So now where does it sit, right?

No, but that's exactly what I was going to raise because for me, I get what you're saying and that's if that's the language you choose to use, cool. I actually don't use the word information product anymore. I use the word data product. You could use information product. I'm indifferent to the language as long as it's shared and understood.

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.

Something that an information consumer will use?

A data consumer.

So what's a data consumer?

A data literate person. So an analyst, an engineer, a data scientist. Data products have been boxed into something that produces data that somebody else will use to serve a consumer. And for me, that is a good definition of it.

Okay. So I actually encapsulate those within the, in the superset of information products. And that's where I think we're different. So I say that an information product or a data product, and I use the names interchangeably and I get where you're like, maybe you shouldn't. I use them interchangeably. I know you don't like that. It's what is understood Cool. If I have to change how I think about or speak about it when I talk with other people, cool. That's fine. It's like when I go to the UK and I wanna talk about chips, I'm gonna get hot chips, not crisps. And when I'm in New Zealand, I'm gonna talk about chips and I'm gonna get crisps, not hot chips. I'll adjust my language depending on my context. Anyway, that aside, we can argue about context semantics for 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're gonna have outcomes they wish to deliver to, and I know that by providing them with an information product that they're gonna run a query off of, do some ad hoc analysis on, that in itself is gonna 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, and this is the XYZ value from it. We don't value, those data products or information products that a data literate person will consume to then provide to another person. Good example, an analyst 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 XYZ about XYZ region for revenue. That might inform a decision that someone else is gonna make, a different consumer's gonna make based on a report that they prepare or a dashboard that they do to visualize that information, or that 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. 'Cause for me, a table that an analyst is gonna use to do some analysis on to make recommendations that will drive action and create value. Is a, is an information product.

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 app or a data product, which is served to a data analyst who then does something with it to then serve a consumer. We are gonna build a bunch of tables and we're gonna make them accessible via Python notebooks. And then the analyst is gonna go in and use the Python notebooks on top of that data to do some more work. To serve somebody else who's gonna 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 are gonna 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 gonna say that the boundary to the information product is all the way to the end consumer, and therefore the analyst work is part of the boundary that we have to deliver?

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 that an analyst is going to consume. Yes, that information product in itself has value because the analyst is going to consume and create value with it. and about 50 other analysts are gonna do the same thing, let's say. Then whatever that analyst has generated, that report, that insight, that thing, that is an information product that someone else is gonna consume to generate, that in itself will generate value. The way I see it is, and it comes back to that point of you can have mega information products, you can have micro information products. Information products are not restricted to the green teams or analytics squads or whatever you wanna call them that deliver it. It's a model, it's a data service, it's a whatever. That can be used to deliver value of some description. And so for me, that whole, and it's delivered by a, is irrelevant. I only care that it's something, it's an entity or it's 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'm like, because it's delivering that value. Because when it starts to come to those conversations of you've got all these zombie pipelines running, you shouldn't have zombie pipelines running because you know exactly what information product 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?

When we talk about, later on, we'll talk about the Information Product Canvas and when you should use it and when you should update it. One of the areas I see great value is 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. We can tell when something in there 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 is that organization getting from that data and information work that was done a while ago, right? Because it should keep adding value or we should decommission it.

Thinking about it, it is, it does have value as an as-built, but I think depending on who's consuming it as an 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 a, oh, so that's what that thing means. Versus like for us, our as-builts are a little bit more detailed than that, obviously. I think your audience for the as-built is different because past an 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.

Yes, definitely. But it's still that 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 talk 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 a machine learning model. And I know the boundary of that information product by just reading that persona section. Right? I can see how big or small it is.

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

That's a good question. I have a framework of novice, apprentice, practitioner, and coach as a way of measuring skill level.

This is not this is not analytics skill level, this is business domain knowledge. So for example, if you ever have to encounter certain systems that are using weird languages in them that call customer some random 4-letter combination of consonant, if I'm an analyst and 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, they might be like, what the hell is this 4-letter arrangement of consonants? I might need to do more work to convert that into something more useful for them. So that helps me understand as an audience, there's a slightly different requirement here than, you know, at a high level, because I don't want to then go as part of my IP canvas stating that for this field, call it XYZ. Like, I don't want to be doing that in the IP canvas. 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 it a model? Is it a dashboard? Is it a report?

It's one area we don't cover. We don't bring in any form of complexity into the canvas.

Not true, because do you not cover it in your t-shirt sizing?

We do to a degree, 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 grab the source system, or the domain understanding is low, or we know that source system 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 the there's something in there that's inferring it's more work than a small, but we don't really ever put the lens on the complexity. But we do that pre-work. We often think about where the gnarly things are as we start bringing it closer.

This is where we thought about this IP canvas, actually. We're thinking about iterating on it slightly, and we've already done it to an extent. It's got the, so what is this? What is the business value outcome? What's the kind of vision statement? So who is your primary user and why do they care about it? And that then gives you the kind of almost semi-acceptance criteria in the, this will or will not deliver X, Y, Z. Then there's the section around the additional additional users or user stories where this is useful, because that helps with the context of, oh, so if I'm thinking about building this, I need to consider these user stories because they might need to use it at some future point down the line. The bounded context of audience, user persona, frequency, type, and there's also the kind of the business events. Sometimes that helps with complexity. Do you still put that in there?

I do. And then I bought SLO, the service level or the expectation of when this data would be available.

I call that frequency. Similar thing, actually similar but different. Then the thing 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 attach to that second page because it's just whatever's 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 high-level conceptual diagram of the data flow. So, I think it's gonna be these systems. And actually, I've done this. I've done exactly this. I've had 3 pages where the first one is the canvas, the second one is like a very rough hand-sketched on a whiteboard wireframe that I've taken a photo of and put on. And then the third page has been, again, hand-sketched on a whiteboard, taken a photo of, and chucked in high-level data flow, which shows me the systems involved, big question marks in places. And it's not gospel, but it's, it's, if you've had that conversation, and typically when I talk to someone about an IP canvas, 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.

That's good. That's an area we can talk about is, okay, 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, whack it in the back, it has value, don't overbake it. And then you've captured some context that support some of the things, some of the areas on the canvas that the context makes sense. So it's a quick half hour.

It felt really fast. I feel like we could go for, like, always, we can go far too long.

And you've segued 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? It's a way of 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 it. 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 with our audiences. There's a whole lot of things that allow us to create boundaries that get that value out to that stakeholder early. And we get feedback before we do some more work.

And have to add the and, 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.

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 okay as long as we, we all agree the change and we wear the consequences of that change. So yes, you're right. It's a way of at the end of it closing out and saying, here's what we thought we were going to build. And we agreed that, and here's what we built and we nailed it.

Yeah. And it's that value over time. Are we still tracking that value over time? It's a way to bound your value descriptors for data.

Excellent. That was a good starter. I look forward to the next one in the series.

Stick to the 35 minutes or 30 minutes. We'll give it a go.

It is, but yep, we just chunk it down. We create a boundary, a timebox, a forcing function, and then we make sure we reduce the content to fit that. So on that, I hope everybody has a simply magical day.