Decisions, Debt, and other Dilemmas
Our world, as product managers, is filled with making decisions. And, making decisions means making trade-offs. Trade-offs so often means taking on tech debt, design debt and other types of debt. This can be a dilemma for companies, especially if it stacks up too much. This presentation explores how to address the uncomfortable topic of working debt, and how to use it to your advantage when making trade-offs.
Check out the slides from my presentation
I used to be a product manager. I used to ask all the usual questions, like, “What problem are you trying to solve?”, and “How might we learn more about this?”, and the infamous “Have you tried turning it off and back on again?” one.
I’m a CEO now, having stepped up to build my own thing which turned into ProdPad. These different roles have given me different lenses on the world. Being a CEO gives me a particular lens that I obsess about… debt.
You can’t build a product without incurring some debt. You can imagine trying to make everything perfect before it got out the door, but your product and company would likely be obsolete before your big launch day. In this way, debt enables you to make trade-offs. We rarely have spare budget to play with, so the main elements that are usually traded about are time – in exchange for scope and quality.
You know the saying: Good, fast, cheap; pick two. If you continuously optimise for speed and short term cost savings, you’ll never actually have a stable and usable product. Making these trade-offs and taking on debt is okay, and perfectly healthy, if it’s understood and managed. It can also get out of hand, as many people well know.
Tech Debt
Let’s talk about the type of debt that must be at the top of everyone’s minds: Tech debt. No one likes tech debt, but it’s a reality of your product’s life.
Tech debt is the bugs or limitations built into your product’s code. It is the cost of reworking existing parts of your product that were built in a hasty or subpar way – instead of the full and ideal solution.
Like financial debt, you might find that some tech debt is intentional. After all, your team can’t be expected to build the most perfect, most scalable version of the product from day one. You might agree to take on tech debt as a trade-off, so you can learn fast from an experiment. This is fine, if the team knows what’s at stake, and how the tech debt will be measured and managed.
Unintentional tech debt
Other tech debt is unintentional. It comes about when you don’t have these conversations with your team. There’s not a shared understanding of how the product is meant to be built or how the whole company wants to deal with tech debt. Because, while intentional tech debt might come from smart trade-offs that enable a team to run a mix of experiments and more robust product enhancements; unintentional tech debt usually comes from beyond the tech team’s control.
I blame the timeline roadmap. Your bosses and your customers love this format of a roadmap, right? It gives them so much certainty of what’s going to be done and when. But it’s setting your team up for failure and it’s basically a tech debt collection pot.
Give your developers buy-in to the company’s goals. Give them the time and space to deliver code they’d actually be proud to support. Our rubric here at ProdPad is build this as if you’re the one who’s going to be training up a junior developer on how to use your code and docs in a couple years time.
Tech debt is also something that needs to be explicitly managed. Too often, the business end of the company will shield their eyes from it. They will simply set company level goals like Increase revenue and Grow user base but not spend an iota of energy understanding strategical plays, like: having a stable codebase, a faster and easier release cadence, and better tech tooling. These aren’t just fanciful technical dreams, they play an important part in a company’s ability to deliver in an agile way and to enable a lean mindset.
Design Debt
It’s not just tech debt that a product manager needs to worry about. Design debt is made up from the product’s limitations. These aren’t down to a bug or it not working, but rather the design not matching the actual user requirements down the line.
Companies are more likely to have a plan for paying down tech debt, like having bug crush weeks or allotting a certain amount of time to refactoring technical work, but we don’t seem to have a collective vocabulary around the concept of design debt. Like tech debt, design debt can stack up.
You can’t improve what you can’t measure, so a good starting point is having a way to measure and understand the design debt in your product. With tech debt, we’ve already got good vocabulary for this – we generally all separate out our functional bugs from our new user stories… but where do things like usability ‘bugs’ sit?
Measuring
Our Product Designer, Kav, came up with a way of measuring design debt that I found really helpful. He sets up a usability test that’s focused on the core jobs we expect users to want to do. Users are marked on their ability to complete the job bright green if they completed the task without help, light green or yellow if they struggled, and a red if they couldn’t get the job done.
The changes over time gives guidance on where to focus to pay down design debt and increase usability across the product. Visualise your improvements with each iteration.
As product people, we want to be able to iterate and release quickly, to experiment freely and learn as much as possible in as short a time as possible. An MVP experiment is really nothing more than reducing scope in order to get something in front of the market faster and cheaper. Ideally, experiments are digested for their lessons, and then put to bed.
But good experiments are still costly and time consuming to run, let alone the cost of building stable new features, and the cutting of corners. We often end up with a product that’s patched together out of past MVPs and experiments, and is hardly a delight to anyone.
A design system provides a baseline so that experiments and new features can be spun up with less of a trade-off on time, and with less chance of incurring design debt.
Process Debt
Your company’s processes should help support the offline parts of your product’s experience. Humans will make up the shortfall, where you’ve got lots of tech and design debt accrued.
For example, if a section of your app is particularly unusable, your support team will be picking up the slack and spending more time on inbound tickets. They might need to write better help docs to compensate for usability issues that should have just been intuitive in the app itself. You might find yourself with a bunch of shaky automations and manual processes, instead of solid tech holding your services together.
Again, it’s important to measure. We don’t often measure the Cost to Serve figures. How much is it costing a person to do a function, rather than provide a more suitable tech solution? Product decisions should be made looking at these sorts of things holistically. Look at costly business pains that might be hidden behind the scenes in bloated processes. And, sometimes debt goes entirely unchecked at companies, and this comes at a real cost.
Culture Debt
Sometimes debt goes entirely unchecked at companies, and this comes at a cost. Companies, particularly large and public ones, want to increase shareholder value. CEOs are incentivised to show quarter-on-quarter, predictable growth. If they don’t, they are turfed.
Management wants to show predictable growth, for fear of spooking investors. And the best route to predictability is to break things down into smaller pieces. It might seem intuitive, but this is what leads to silos in companies.
You end up with the head of one division competing against the head of another division. Each optimising for their own metrics but not working for organization goals as a whole. This leads to teams making counterintuitive business decisions. For example: letting one team stack up design debt even though it’s jamming the support team full of queries. Or, withholding budget from investment that would prevent tech or design debt.
It results in storming as well
Remember I talked about trust and incentives earlier? One of the biggest causes of tension in a team looks exactly like this: You’ve got someone on the tech side, and someone on the business side, and they end up in a fight over a deadline or a project. They’re not fighting because of personal tensions. They’re disagreeing over the outcome of the project, because it’s asking them both to work counter to what they’ve been incentivised to do.
The developer is usually the one advocating for quality.The business person wants it done on time.They’re both being pressured to give a little, or sometimes a lot, depending on whether it’s an engineering-led organisation or a sales-led one. Oh, and the product manager is always stuck in the middle arbitrating the whole thing. What’s missing is a shared vocabulary and trust where they can talk about their incentives honestly, and talk about the trade-offs they are and aren’t willing to make, and how they impact the business.
Over the course of these conversations, each gives a little, and common ground is found, and a compromise is delivered that works for both people and the business. Like agreement on a time-limited experiment with permission to go back and refactor afterwards. Or perhaps an agreement to get the developer involved earlier so that misunderstandings are avoided next time.
Some organisations are structured to handle this well, others are not. Cross-team collaboration, transparency, psychological safety come in to save the day. So someone can spot and say something if they see debt being incurred.
Admin debt
Let’s take this back to our day-to-day work.
As product people, we’re knowledge workers. We work with our minds and our sticky notes and our meetings. Pretty much everyone we work with in our tech circles are knowledge workers too. For example: coders are coding, marketers are writing marketing copy, sales people are selling. We do what it says in our job description, and yet there’s so much more to our work than that.
Admin debt is the cost of all of those little non-work tasks that pile up. For example: sorting through emails, organizing files, keeping apps and OS’s up to date, transcribing notes into actionable tasks, or whatever else keeps you busy.
We’ve set it as a two-hour block of time at the end of each week for everyone to participates in. We use the time to tidy up desks, get to inbox zero and set filters so that we can stay there, set up automations to smooth out our workflows for the next week, or consolidate to-do lists. We can then have a relaxing weekend and come back on Monday with fresh, creative minds.
To conclude
Debt is a reality of our lives. You won’t be able to build the best products by avoiding debt altogether. You won’t be able to build a healthy business or mindset by letting it stack up. Often at times, something becomes a little less scary when you talk about it. You can measure it and take action on it. I hope I’ve given you a few new ways to think about the work you do. Take advantage of the decisions and the debt you play with. Step back and look at the bigger picture.
Get in touch if you’d like more information or to discuss your own product strategy.
These are just a few types of debt that product teams need to contend with. What other types of debt can you think of, and what other tactics can you share for dealing with working debt of all kinds? Share your thoughts in the comments! 👇
