Build What’s Next: Digital Product Perspectives

Technical Debt During Planning and Prioritization

• Method

Share episode

In this podcast episode host Jason Rome and guest David Brown discuss a practical approach to planning, moving beyond "process theater." It advocates for transparently managing technical debt as product work, leveraging habits over rigid processes, and clearly framing trade-offs. We'll explore clustering work by component to reduce friction, integrating testers early, and dedicating consistent time for modernization. Culture is built on micro-behaviors, emphasizing hiring people who "clean what they touch" and embedding new habits into existing rituals. Recognizing that teams differ, we'll use Team Topologies to align diverse teams with varied cadences, staggering planning and acknowledging the need for dedicated capacity for discovery. If you're ready to embrace practical clarity—visible debt, respectful sequencing, and useful planning—this conversation provides concrete steps to start tomorrow.

Episode Resources:

Jason Rome on LinkedIn: /jason-rom-275b2014

David Brown on LinkedIn: /in/david-allen-brown/

Method Website: method.com



SPEAKER_00:

You are listening to Method to Build What's Next: Digital Product Perspectives, presented by Global Logic. At Method, we aim to bridge the gap between technology and humanity for a more seamless digital future. Join us as we uncover insights, best practices, and cutting-edge technologies with top industry leaders that can help you and your organization craft better digital products and experiences.

SPEAKER_01:

That brings me to another topic that uh, you know, you've given me a lot of thoughts about and kind of taught me about, which is tech debt, right? And your example of a pilot there, right? There's pilots you build to pilot and you're going to throw away X. And there's, hey, we're doing a pilot right before we go to prod, but it's production ready. Um talk to me about tech debt and how that comes into planning and what you've done with teams and like what you've seen with teams to have an efficient conversation because you know, I've I've stolen your thoughts and recommendations and shared them uh in the world. So uh I'm glad to hear that.

SPEAKER_02:

So just the simple way of saying it is it needs to be talked about in you know, whatever's team's cadences that make sense for them. It shouldn't be the hidden thing that someone, you know, is maybe is responsible for, or what I can't stand are these implied expectations. Oh, I hired you and you're the tech lead. So I, you know, it was implied that you would take care of the technical debt. But it really is a a a function of good product management. So I shift it back to the product person and say, all right, how are you looking at technical debt? Even though you may not understand it all, how are you working with a team to make it as visible as possible? One of the practices where we've seen a great return is it just attaches to all your other events. So if you're in, let's say you're using sprint planning, if you make these trade-off conversations kind of to what you had talked about earlier, where your technical group is giving you options, we can do this the quick and dirty way, you know, duct tape it, or this is you know something pretty good, or this is you know, gonna take all the spread to do it. Which one do you want? If the product person is prioritizing, let's do it quick and dirty, because we're gonna it's a hypothesis, so let's test it first and get it in a form of an environment that makes sense to get feedback. Great. Well go ahead and create that next bucket of work, if that's a story or anything else, to then clean that up. Now you may depriorize prioritize that in the future because your test came back and you're not gonna do it, and you throw them both away. But that action of plotting the debt that comes with making decisions is very important. But one way we've done these is put it kind of on a two by two. One of it's like how much or what area of the software which is commonly used by the consumer, and then one area, the other, the let's say the X is how complicated or how much debt is there, if you will. Or you can use the size of the item on the two by two. How we've seen it several different ways, but ultimately you have a graph that you're using. And anytime you go create technical debt, let's say it's at the end of a sprint and you're doing your review with your team, your team says, Hey, you know what, I did this thing, I we rushed it, I didn't get to do the documentation, or you know what, I didn't button everything up, or or this was still in the code, I saw it and I didn't correct it from last time. Map it. Just map it. Yeah, no, no reason to point a finger. And then in the next planning, after you've done and you've pulled in your priorities, you can go look at that map and say, based off of all the things we selected for this sprint or this iteration, is there anything on that map that makes sense to attach to it? Because you're already going to be in there, kind of Boy Scout, Girl Scout rule, leave it better than you found it. And those are just decent practices that come up with if you make it visible and you shift the ownership back to the priority layer, you'll probably have a better result.

SPEAKER_01:

Yeah. I um, you know, I think that that's one of the key things. Uh what you said there last, you know, and the the the three things I recommend to teams, because you know, once you have your priority, once you have your high-level roadmap, right, you can you have to give the team room to choose how they deliver, especially because yes, some teams are deploying multiple times a day and every day. You know, a lot of these larger initiatives, they are still being rolled out after X number of sprints or in a quarter. And so the order in which you build those things doesn't have to match the business priority because it's all going to reach the finish line at the same time. And so you touched on one thing, which is you know, having a board and opportunistically looking at where can we leave something better than we found it? You know, I always say, like, hey, we're in surgery, like the body's on the table. Is there anything we can fix? You know, while while the while the patient's under. And so the three behaviors I recommend for teams there are um one, which is clustering over prioritizing. So after, you know, prioritizing work and then clustering it, like which of these things touch similar features where it makes sense to group the work together because we're gonna have to test it all. We're gonna have to release it all. You know, let let's let's cluster it so that we go through that last mile together. Let's let's still, you know, deploy in small batches, but someone's gonna be in there, they're gonna be understanding the code, they're gonna be taking on that cognitive load, they're gonna be deep in it. And and if and if they have to do that, you know, five sprints apart, they have to relearn a little of it. They're not gonna memorize it, right? But if they if they can do it all at once, it makes a lot of sense. The second thing for me is is being really respectful um of the testers and bringing their voice in. And so um, you know, talked about this before, but it's you know, you finished a big increment, it's a big push to the finish. You're tired, you're in PI planning now. It's three days long, maybe you're a little grumpy. And so what do you take in sprint one? You take the easy stuff, right? You take one the one-pointers, the two-pointers, some of the carryover work, which makes sense. Um and what is the product team requirements for? The easy stuff, you know, and there's that big looming undiscovered thing that's that we put in sprint five of this increment, right? Uh, which is usually gonna be the hardest thing to test. And then the testing team gets squeezed, hardening is tough, uh, end-to-end testing, so testing, all that's tough. So really looking at what's all the things we have to accomplish and like which of these things is gonna be the hardest to test and is likely going to create the greatest number of defects or the most difficult test cases because we need certain data created that we have to flow through our databases, we need new environments configured, we need, you know, a client-specific configuration that we have to test this with and trying to pull that stuff forward so that we're not backloading all of our risk on the testing team is one of the patterns. Um, and then the third one is which you mentioned is is opportunistic. Um, is there something that's tech debt that we had or design debt? So I talk about this when teams are trying to move to a new design system. Of, you know, you can make migrating to the new design system a set of features. Or you can say, as we work on each feature or on a set of pages, we'll also just always add 20% time to modernize that and update that. And you know, 20% might be less or more depending on where it is. But saying, hey, we're gonna we're gonna give the team time to work on that a little bit and being opportunistic, I think is a key thing. Teams can work into planning to be a little bit more intelligent on the delivery plan versus just this is the priority order, let's put them in sprints versus the team feeling like they have that ability to change that.

SPEAKER_02:

So I don't know if you guys have done other stuff like that before, but yeah, I there's a few things that called out in those in the opportunistic aspect of it. I think it's important that you don't have to wait until you everybody's on board and you're just thinking about that. There's there's behaviors that start to show or that you can build into a team or individuals so that they start to think that way. And it could be really at like at the hiring or or or at the interview process is are you creating an environment to where when they're going in and maybe they're coding with you in a in a scenario and they see something, do they fix it? That's a window into like what's their behavior going to be when they get into the real code base. And are they gonna clean up after themselves or after someone else, or are they gonna say that's someone else's problem and shift it? So I think you can start to plan for that. Same thing at leadership levels. It's very common to take someone out to eat, to get to know them a little bit more, if you're hiring for a big role, and how do they treat the staff? Are they nice to people? You know, are they thankful for the meal? I I think these are tells that we need to look at to say, like, are we bringing in the right people? And if in let's say them they're not mature to that, we need to build that as a subculture. The other thing that calls out to me is habit stacking, just like we would do in our personal lives. But if you want to introduce a new behavior, maybe that's bringing transparency to technical debt, attach it to a behavior that's already working really well within your team so that they're now coupled and you don't think about one or the other, you think about them together.

SPEAKER_01:

Yeah. I love that. Um, one of the key things for me, you know, because obviously avoiding as much paperwork as possible in the process. But, you know, I always say, you know, any template we create or any process we create, you know, it shouldn't just be, you know, creating an artifact. It should be helping teams structure how they think. And it should be teaching teams the mental models what we want them to have. Um, because I think at the end of the day, like a really mature organization needs a lot less templates. They need a lot less process, they need a lot less paperwork because their teams have just internalized this is how we align, this is how we make prioritization decisions, this is how we do road mapping and sequencing, like this is how we manage pivots, like this is how we do action planning and like take ownership of stuff. Like those can all be internalized as value and culture. Now it's important when you're getting an organization started to centralize those things and drive those and have it be consistent and have the paper trail. And knowledge management is more important than ever, especially with you know AI able to kind of extract and pull that information. But I think that's a really key thing with habit stacking is like how are we not only getting people to follow the process? Because I think the danger of you know, you can put a process in place where people start conf confusing activity with progress. Right. Um and you know, they feel like by completing the process they've moved something forward, um, even if they haven't, you know. So some organizations, you know, really robust PRDs sometimes will do this where it creates the illusion of alignment, but it hasn't happened yet between teams. But you know, we feel like we we move something forward, but like really it hasn't moved forward on our Kanban board. It's still blocked by something. We don't see that. Versus if you can structure the document so it helps teams structure how they think, it it's even more valuable because they're creating those mental models and habits and you're actually moving them forward in the progress, so or in the process. So I I I love what you said about habit stacking there. Um any other parting thoughts on on planning? I mean, we can go for a couple more hours if you want. I feel like we could. I um you know, yeah, we didn't we didn't touch on financing, but that's probably a whole nother thing. Um Yeah, I'm trying to think if there was anything else on planning. Oh, um getting ahead. We we we touched on this earlier, but you know, how do you how do you make planning, what are the mature behaviors of teams so that planning doesn't feel like a scramble to get ready for the next increment and or the next big room planning? And again, where people are coming in excited, it doesn't feel like a burden. Like what's what's happened between one planning event and the next one, between a mature team and a not mature team that's going to lead to that excitement?

SPEAKER_02:

I think the organization has thought about the experience that comes with planning and they've worked to make it valuable for everyone involved. And so they didn't show, they didn't build it only for leadership to it to be valuable, to say, all right, we have a plan. They didn't work towards the nouns, they focused on the verbs and they focused on how people's experiences and how they contribute into the planning process mattered. And so you almost take an inside UX approach to how do we, if we truly believe that planning is important and it helps us as an organization to do these things, whether it's alignment or anything else, how do we create it to be an enjoyable experience and reach the destination?

SPEAKER_01:

Yeah. I I think for me too is the the teams that come out of planning with knowing what needs to be done in the next 12 weeks for the stuff that they couldn't take on. And they have going back to that confidence like, what are the things we need to do between now and our next planning event to be confident in the next set of work and and making space for that? Um, you know, you've always said discovery isn't free. You know, we we measure, we measure engineering velocity and burn down, but we don't really track what the product team's working on and what the design team's working on. And and one of the questions I love to ask people is I love to ask leaders, how do you want your product and design team spending their time? And then I love to ask product and designer people, like, how do you want to be spending your time? But then I ask them, how do you actually spend your time? Um, and I think having the right balancing act of how much are they out there with users, how much are they clarifying things for developers, how far are they getting ahead? And do we have the right mix of people focusing on the right aspects of that based on the part of our technology they're working on? Like some people are gonna be on very technical platform level capabilities where they're gonna be focused a lot on delivery and intake versus others are gonna be more kind of innovative, growing, high uncertainty areas where they need to be out among customers. But coming out really clearly with hey, here's the discovery work we need to do, here's the tech spikes we need to do, here's the spikes we need to do with the business on like operational changes that we need to make. Um, but one of the things that, you know, I see is you know, you come out of planning and then there's a massive backlog of tech spikes for the architecture group. And I've never worked with an organization that said, you know what, we have too much solution architecture time on our hands. You know, there's a bunch of folks that just sit around with absolutely nothing to do. Right. Um, and so, you know, that architecture groups are not teams that are like ready to take a massive dynamic spike of work every 12 weeks because people decided on a bunch of new stuff to do. So being really crisp on like, hey, here's the really technically complex things we're gonna take on. Same thing with the UX research team. Here's the stuff that we need to get in front of users because it's gonna take time to line those up if that's on a mature system. You know, this kind of goes back to where we started why planning is so interesting because you see, you know, how well is the architecture and engineering team aligned with the product team, how well is the discovery and CX and UXR team function aligned. You can kind of see all these things that should really it should be events that kind of launch a thousand ships and then kind of come back together and teams can kind of work independently and collaborate along the way. So I think that's the other thing is like whether it's annual planning or if it's quarterly planning, whatever it is, like figuring out like what are the big rocks, what are the big unknowns, where are we uncertain, and and can we figure that out so that we can adjust the plan along the way and having those parameters?

SPEAKER_02:

Yeah, it's something you called out. And we we again we talk about different methods, but team topologies, not every team is the same type and their incentives are going to be aligned differently and their functions are gonna be different. So I think being very clear, is this a value-aligned team? Because we measure or they measure value delivery very differently. Is this an enabling team? If this is an enabler team, how are they working with these other teams and how they move across their backlog roadmap might look a little bit different? So that's one of the attributes that we need to take in consideration is not all teams are just delivery teams, the same type of delivery team. So if we're going to bring them all into a room because they're all aligned to the same customer base or value stream, then let's be aware of team type. The other one is not all teams or their products are in the same area of life cycle. And so a product that's existed for maybe a couple of years, it's in some form of scaling. It quarterly planning is probably a lot easier for it. It's had signals and signals and signals from its customer base of what they want next, and they're probably big changes. And they can say pretty easily what we want to try and do and uh what we want to test or hypothesize over the next three months. But when you have a proof of concept pilot, you know, maybe a new entry into a market, it might be very hard for them to say what's three months look like because their feedback loops are so small. And so is it okay for them to come into this quarterly plan and say, we only know what the next two weeks looks like for us because we're really running these kind of free search or discovery spreads along the way. That should be built in. There's there should be flexibility for that.

SPEAKER_01:

Yeah, I think that's a key thing is is, you know, giving yourself permission not to let the calendar dictate the rhythm of your business and your teams. Uh one of the things that, you know, I think one of the anti-patterns in safe a lot of times is that it encourages teams to manage dependencies versus remove dependencies over time. And team topologies teaches you if you have teams that are dependent on each other over time, what can you do to kind of create the right, uh, a very clear relationship between those teams and set expectations so that it can be managed a little bit easier. Um, one of the things that I I've talked to clients about and that I've seen some clients start to implement is not everybody has to plan the same week. You know, not everyone has to be there the whole time. You know, your infrastructure and cloud team, they can meet the week after all the value stream teams do, and then make sure they have capacity to support what all of those other teams are doing or a platform team like that, right? They don't they can join the end of all those meetings, make sure like what they're planned working on kind of aligns. You know, they should be getting pre-read into that. They shouldn't be getting surprised if you're doing it right. And they they don't have to have their event at the same time. It doesn't have to be as long. You know, I think a lot of these plannings it gets mixed up between a planning event, a town hall, and a backlog grooming. Um, and it, you know, it ends up all in one um and like a massive thing. So I think you can be really intentional with people's time. And I think uh, yeah, I've had this conversation with some folks, like uh sometimes a sign of maturity is not getting planning. Now, now there there are there is value to it in getting everyone together and re-emphasizing the vision and the message, but you can get down to pretty simple having teams present if if they're having those conversations and you're keeping your initiative board up to date and you're you're staying aligned. Or like, hey, you have a team running Kanban, they're mostly taking tickets, you know, they they just keep running that way. You know, they don't they don't have to plan that far ahead because you know they have an efficient process for managing work in progress. So I I think there's been a little bit over adoption of this like one size fits all planning, and we have a ton of these people. And it's it's really onerous on a lot of teams uh and it's stressful for a lot of people. And you know, you want to make sure you're you're balancing it, um, whether it's annual planning or quarterly planning. There's a book I read called um, I think it was like the 12-week strategy. It talks about, you know, we're too attached to the idea of a an annual calendar and an annual strategy, and forcing ourselves to think in 12-week strategic blocks is is a different way and like setting goals that way. So uh it was a quick one, it's a good one. I I think we're reaching our limit for the number of books that we can reference in a podcast. But but glad to see that class got in there. Any other parting thoughts before we we close out here? Oh, I think we're good. Awesome. All right. Well, thank you for coming in. This is fun. Thanks, Chase. Awesome.

SPEAKER_00:

Thank you for joining us on Build What's Next Digital Product Perspectives. If you would like to know more about how Method can partner with you and your organization, you can find more information at method.com. Also, don't forget to follow us on social and be sure to check out our monthly tech talks. You can find those on our website, and finally, make sure to subscribe to the podcast so you don't miss out on any future episodes. We'll see you next time.