Managing Product Debt for Fun and Profit
Well, OK, may be less fun -- but product debt is crucial for turning a profit.
When we talk about ‘debt’ in the context of software product, we most often talk about ‘tech debt’ and the after-effects it has on software quality. But not only is debt essential, tech debt isn’t the only type! It all comes down to understanding the trade-offs you are making, what this debt buys you, how to repay it, and what’s the best way to utilise it.
I’m covering these in no particular order, just what’s on my mind and what I had to deal with over the years. The aim is to turn the discussion around, so you are conscious of the downstream effects of the choices you make now, and that you have the right tools to make better decisions.
EDIT: I also gave a talk on the subject, which you can watch here.
First, what is Product Debt?
Think of debt as a tool, a loan against the future. You can take a mortgage to buy a house, and by the time you repay it the equity has grown. That is a good debt, you have utilised it to get ahead. Taking a loan on a car that depreciates or borrowing from Luigi the Shark is bad debt.
There’s an old saying that while out in the cold peeing in your pants may feel nice and warm at the start, but soon turns stinky and uncomfortable. It’s wonderfully graphic about the dangers of short-term thinking. Like many things in product, there is often a big time distance between cause and effect. Taking on debt and only much later feeling the cost of paying it is a prime example.
So let’s learn together how not to pee in our pants.
Tech Debt
This refers to any decision made in the tech stack of your product. It comes in many different variants, but they all focus of getting stuff done quickly, shipping value to customers earlier. Moving fast is imperative in this modern world, especially — but not limited to — startup. That does come at a cost later, because all those hacks and cut corners making any additions take longer. The application becomes brittle, quality degrades, and it’s becoming harder and harder to make any change without breaking something.
Tech debt comes in a lot of variants: Architecture debt (eg using a non-standard architecture or using outdated technologies); Build pipeline debt: shortcuts are taken in the build process and it’s taking longer to produce new versions; Code debt: code is unclear, contains many copy-pastes, and is generally a nightmare of cognitive load; Bug debt: all those roaches lurking around, popping out whenever a user tries to do anything; Infrastructure debt: similar to architecture, but specifically around hosting the application.
Of particular note — because it’s exceedingly common in Enterprise software and the bane of my existence — is Design debt: when non-designers design the interaction, it shows. Too many clicks, too many much mouse movement, broken info, cognitive load, unclear pathways to get the job done. No amount of lipstick (UI design and eye-candy) will make that pig desirable.
Side note: I still remember that first time I walked the executive leadership team through what Tech Debt is. All the sage nods and agreement, and absolute zilch in pausing feature delivery for noisy customers. I also remember the unimpressed looks my “I told you so” got me two years after accruing design debt. Rule number of soapboxes: get off it.
When to take tech debt on
You should never aim to build perfect, bug-free software. It simply does not exist, and is an utter waste of time — time you could be learning. Rather, get a better understanding of where your product sits on the maturity curve, what your users expect, and your ability to deliver it.
The classic example is Crossing the Chasm — early adopters will forgive the rough corners, but the early majority expects more stability and polish. By understanding your customers and users (what really matters to them) and by closely monitoring your ability to deliver value (ie the ascending crescendo of developer grumblings), you can ascertain whether taking more debt is good to deliver something fast, or whether you need to slow down and fix things.
Also apply some common sense, in that architectural and infrastructure debt may stay with you longer and be harder to fix, than an obscure bug. Same goes for design, unfortunately.
When to pay it off
You will never, ever, get that “just a couple of sprints” to fix all the really broken stuff. Executives’ eyes gloss over when you say the magic words “slow down to speed up”. Can’t really blame them — 5 weeks of your team’s time is about $150,000 (ref Kirsten Mann).
Rather than let things get too bad, I’m an advocate of building quality in. When the devs tell you something will take a week, you pass that quote up the chains as 3 weeks. One, because we all know devs don’t think about edge cases, and one week really mean two. Second, the other extra week is to apply the scouts’ rule of leaving the campsite cleaner than how you found it, and giving engineers the space to fix what’s slowing them down.
Not that I’m advocating lying to your managers. Oh, no, never. But use it as the cost of doing business, to keep things running smooth. As any martial artist will tell you, “slow is smooth, and smooth is fast”. But since karate-chopping your execs is a no-no, just allocate some time each cycle to keep on top of quality. If you do face heavy rewrites (replatforming, redesigns, etc), just fight to get them sooner — and fight by showing numbers.
Revenue Debt
This is an interesting concept, particularly applicable to early-stage products and start-ups. This happens when you chase — and capture — revenue that eventually costs you more. (I’m not talking about those customers who we wish would just go and harass the competition.) When you sign up that A-list customer, and they come with a list of demands, and then they have expectations of service, and not only do you need to bend over backwards to keep the pleased, you have to keep doing so at the expense of other customers.
The problem exacerbates whenever you have several such high-profile customers. Especially if they are across disconnected verticals, or with specific niche needs. Instead of solving issues that are applicable to a wide section of a specific industry, you end up with custom integrations and an eclectic collection of features that everyone suffers for but only one or two customers use.
When to take revenue debt on and when to pay it off
Revenue debt can be highly effective when opening a new vertical. Say you’re going after automotive companies, and you nab one of the Big 3. Or consultancies, and you sign up one of the Big 4. Or publishing houses, and you snag one of the Big 5. Having that logo will open doors and get you more deals. It’s worth dealing with those demanding customers, because of the benefit you get signing all the others on the back of them.
This implies having a strategy of concentrating on a vertical. Otherwise, if you don’t capitalise on those household names or even if just get those A-listers too early, it will drown you in requests and demands and not provide any long benefit. This is very prevalent at start-ups where “any revenue is good revenue!”. While it’s perfectly understandable that you have to keep the company afloat, sometimes monetising too early will kill growth. That’s what VC money is for. Strategy can be simple, but not easy — saying no to a deal is hard, which is why they call it the hard choices and why so many flounder at it.
Paying revenue debt should be a dispassionate decision. Keeping the customer happy has a cost, both direct (time spent on their requests) and indirect (opportunity cost). When that cost doesn’t match the benefits (attributable sales, or when no one else needs “their” features), it’s time to dial engagement down and let time do its thing. Another very hard choice, hence why it’s better to think carefully about who you target in the first place, and whether you will be better served serving the tier 2/3 players first.
Interestingly, 20 years ago that is something that Atlassian did exceedingly well. They sold their first software as cheap subscriptions, without an “enterprise tier” that would distract them from paying attention to the wider market.
Strategy Debt
Speaking of the hard choice of focusing on narrow verticals first, that’s strategy debt. This is most often manifested as Vision debt — the lack of coherent, strong vision for both short, medium, and long terms. It is almost always visible in a quarterly sales-led organisation, where we chase the market to close the next deal (see above).
You need a strong long-term vision, a rallying standard for everybody in the company — and VCs — to know where you’re planning to grow. But you also need a strong short-term vision, so that everyone can tackle the same problem.
For example, if my mission is to help reduce climate change, my long-term vision is to fix emissions from the automotive industry, my short term is a luxury, high performance electric vehicles, my medium term is mass-market affordable EVs, and the long terms is electric trucking and shipping. Imagine if Tesla had the mission and long term vision, but didn’t start very focused. Would they have grew the business in stages, if they tried to do too much too soon? The same with many other success stories, from Uber to HubSpot.
When to take on strategy debt
Never take strategy debt. It’s hard enough to align your whole organisation when you do have strategy. Without clear understanding of what you’re trying to achieve — and what you’re not touching — it’ll be impossible to make an impact.
While you need to retain agility in responding to shifting market and competitive landscapes, and sometime do a big pivot, you must always be working towards a strong vision. You must communicate and over-communicate that vision until you’re sick of hearing it, and then some more.
Organisational Debt
Every organisational structure is an exercise in optimisation. Choosing to collect and organise teams in certain ways will help solve certain problems better, which making other chores harder. While there isn’t a right or wrong answer — only a better fit for right now — there are certain signs you can watch out for.
Conway’s law states that any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure. Does your enterprise software require professional services, who are their own arm? Your product will end up obtuse to users and friendly only to the consultants. Do you have several highly empowered autonomous teams? Your product may lack cohesion, with different areas looking and behaving very differently.
Watch closely for any breakdown in communications, as evidenced by conflict, errors, blame games, etc. Watch for silos, which cause duplication of efforts and disconnects in user experience. Watch for frustration and low morale, which may be attributable to a lack of clarity around roles and responsibilities. Overall, watch for low psychological safety, poor decision-making and missed opportunities.
While there will always be some of that, but as soon as the ‘noise’ increases it may be time to tweak the org. Don’t delay, as re-orgs are oft traumatic and certainly costly. Try using continuous adaptive push and pull to smooth out cross-org comms. (Part of the allure of a 5-person startup is the immediacy of communications across the whole company — but it doesn’t scale). Think about problems the company faces today and what it might face tomorrow, and try to nudge things in the right way.
Decision Debt
I include this for funsies. You accrue decision debt by not making decisions or making poor ones. We’ve touched about the hard decisions above — not making those choices is a choice in itself, that usually has negative consequences. Poor decision-making can have multiple factors, from lack of data, lack of alignment / vision, deadline pressure, inexperience of resources, etc.
However, studies show that one of a key feature of high-performing team is the ability to decide quickly, move, and improve. So encouraging making decisions is sometime more important — because focusing on making right choices can lead to fear of making the wrong one, and this ‘decision paralysis’ is far more harmful over the long term. You should evaluate the need and potential implications of a decision, but you should still make them.
While no one has a crystal ball to predict the future, you can improve decision-making across the organisation.
Categorise the decision on reversibility, impact, urgency or whatever makes sense to you, to decide whether you should move quickly or research thoroughly. I like this 2x2 matrix by Robin Zaragoza.
Openly collect and share data across the organisation. Review regularly, and bring it into every discussion.
Align people on vision (ad nauseam) so they understand the strategy what matters, and coach leaders in classifying and making decisions.
Run retrospectives, without blame, to keep learning and improving.
There isn’t a good reason to consciously accrue decision debt, but you should monitor for decision paralysis, bottlenecks, and other blockers that effectively choke your organisation and best people. You should bias for action, and all that.
I hope this review of the various debt you can take while developing and managing products and organisations was helpful. Remember that some forms of debt can be good, like a loan where the leveraged payout is bigger than the cost. You just need to plan ahead about when that loan might be called in, and how best to handle it.
Thoughts? Comments? Types of debts I’ve missed, or something you’d like to add?
EDIT: I also gave a talk on the subject, which you can watch here.