Remove tech debt from your product backlog
Remove tech debt from your product backlog
Tech debt is decision debt. By leaving it in your backlog, you prevent new work from being done. (Be careful what you let in, too.) "Everything Starts Out Looking Like a Toy" #130
Hi, I’m Greg 👋! I write essays on product development. Some key topics for me are system “handshakes”, the expectations for workflow, and the jobs we expect data to do. This all started when I tried to define What is Data Operations?
This week’s toy: a map of Null Island, the representation of the coordinates 0,0 that doesn’t really exist outside of databases. It’s similar to the Linkedin page for Stealth Startup as these are both the equivalent of digital exhaust: things that exist but don’t really mean anything. Christopher Null has had a version of this problem for a while, as his last name is famously something a lot of databases don’t handle. Edition 130 of this newsletter is here - it’s January 30, 2023.
The Big Idea
A short long-form essay about data things
⚙️ Remove tech debt from your product backlog
It’s almost the time of year to pay taxes and the whole process reminds me of the way we accumulate tech debt in a product backlog. Finding all of the documentation to pay taxes can be challenging. When the process is done, you start all over again, and if you haven’t learned to build systems to make it easier you are putting off the inevitable time in the future when you have to deal with your decisions again.
What do we mean when we say “tech debt”?
Tech debt is the work that engineers have Tech debt, as Alex Ewerlof puts in his essay on Tech Debt Day, comes from three main sources:
External change - the technological requirements of the systems require new work, like upgrading a plugin, handling security dependencies, or other similar items.
Internal requests - bugs in the system need to be handled, technical designs need to be updated, and organizational processes point at fixing certain problems first over others
Speed and complexity - user requests and product requirements change faster than the team is able to respond using the current code base.
Because of one of these three factors, we decide to postpone working on a feature or a capability in the product, reasoning we will do it later.
That decision compounds to remove future optionality, as Ewerloft shows in this illustration. The amount of work we need to do to maintain the viability of a codebase erodes over time until the tech debt must be handled.
More importantly, this “kicking the can” behavior to wait on dealing with tech debt results in more of our time being used to deal with tech debt.
What does tech debt look like in a product backlog?
Tech debt looks slightly different in a product backlog than in a pure engineering backlog. Because we don’t know exactly which problems are going to need solving from a tech perspective, product managers (at least this one) think of product tech debt as pure decision debt.
This debt takes two main forms:
Problem 1: “We’ll go back to fix this later” - When you make a decision that you know is a shortcut today and you promise that you will fix it in the future.
Problem 2: “We can’t fix that yet” - When you see an accumulated set of problems, probably tied to a single area of usability or customer requests, and you wait to handle it until some unspecified time in the future.
The core problem here when we add tech debt is not that we bucket things into a “we will fix later” or “we don’t know enough to do this yet”, but that we don’t have a solid process to pick items from the backlog and know that they are now fixed or that we now have enough information to go fix them.
Here’s an example of this kind of workflow visualized by David Allen’s system of “Getting things done”. The goal is to understand quickly whether the item we’re working on is short (can be done almost immediately), requires research, or is the kind of work we won’t do.
Reshaping the backlog into “do”, “do later”, “don’t do”
Taming the backlog (the list of things we think we might do) requires you to do a few things, including sorting work into the following buckets:
Things we will do
Things we might do later
Things we won’t do
The devil is in the details, of course. Things we will do need to be quantified, and things we might do later have to have an expiration date after which they by default become things we won’t do. If you’ve ever read Eliyahu Goldratt and Jeff Cox’s The Goal: A Process of Ongoing Improvement, you will recognize that we want to avoid being the “Herbie” in the situation.
In The Goal – a parable of business optimization – a manager discovers the key to improving the throughput of his manufacturing process is to improve the performance of his slowest performing employees (you’ll guess the employee is named Herbie). The manager determines that there are certain processes that need to jump the line and be completed immediately, and others that require dependencies that prevent other work from being completed until those tasks are done.
What does this mean for the product backlog? It means that certain work should always be done, because it constitutes small changes that when compounded make a meaningful difference for the customer. Examples of this are common UX debt issues like padding, spacing, and formatting. Failing to fix these items over time results in an extremely fragmented experience for the user, but spending a lot of time to fix any one of these issues seems wasteful.
When you see small items repeating themselves and needing to be fixed frequently, it’s often a sign that a system helping the team to resolve these issues needs to be built. In the case of UX debt, a design system is a common method of rolling these small nits into a larger body of work that is defined and eventually expressed as the principles for “how we do things.”
But what about the bigger swings? There are lots of items that get requested by customers and prospects that are “do later” items. We recognize that these are the kind of things we might like to do, but we don’t have enough information, context, or resources to do them yet. (Or perhaps they are on the list of items that are planned, but other things need to be done first as technological precursors.)
The existence of work that should always be done implies that there is work that should never be done. This bucket is very hard to define because there is a strong temptation to think anything is possible with enough time and energy. One way to approach this is to have a mandatory research task when there is a new thing requested (and there is time to research) so that you can do enough time-bound research to state that this item is in or out.
A set of concrete next actions for the backlog
Great, you say. This is an interesting philosophical discussion but what can I do today to solve my product backlog problem?
Create a “fast lane” for small items that are important to fix
Much like the 10% allocation that Alex Ewerloft suggests for tech debt, pick an amount of the product pipeline that is dedicated to small, important items. How do you identify these? If something gets mentioned multiple times and it takes a few hours to solve, it’s a good candidate. If that item also intersects the "things we’d like to do”, it needs to be at the top of this list.
Note: the fast lane should be limited to a certain number of items at any one time (5? 10?)
Raise the bar to enter the backlog
Your backlog is likely segmented into items for which you are building requirements, items that need UX work, items that are under review, and items ready for developers to pick up. If items aren’t ready, researched, and documented, they need to wait to enter the backlog. Make it just a little bit harder for items to enter the backlog and limit how many items are being worked on.
Define the standard research expectation
Building a standard process for writing up backlog items might be the second most important way you improve your backlog (behind limiting how many items can be in there at any one time). When items have a solid description and there is a sense of the use cases, potential screens, and outcomes, there is enough to go build.
What’s the takeaway? The product backlog is a clear statement of your priorities. If the backlog is a through line from your customer request to your current work product to your roadmap, it provides a valuable calibration matching what you want to do with what you’re doing.
Links for Reading and Sharing
These are links that caught my 👀
1/ What makes a great design? - Modeled on Abraham Maslow’s hierarchy of needs, Steven Bradley’s Design Hierarchy of Needs is a classic at describing what you need to do to build a better design. (This is a helpful rubric when you’re determining how to retire that UX tech debt.)
2/ AI rewrites the data stack - Benn Stancil writes that AI designs for data might look … much different than a similar schema built by a human. Because these systems don’t have the benefit or disadvantage of knowing the conventions used in the past, they may build data tables that don’t look like what we’re used to seeing. Does this mean these generative data models will be “better”? It’s hard to know yet.
3/ AI now writes music - Google researchers are experimenting with using systems to create music, and the results are … pretty amazing. If you think using generative AI to create art is horrible, you’ll probably hate this too. There are many places that could benefit from interstitial music or auto-generated music, and I’m pretty sure the rights issues will be ironed out eventually to support this use.
What to do next
Hit reply if you’ve got links to share, data stories, or want to say hello.
Want more essays? Read on Data Operations or other writings at gregmeyer.com.
The next big thing always starts out being dismissed as a “toy.” - Chris Dixon