Prioritizing Tech Debt and Opportunity Cost

Last week I found myself arguing with one of our engineers at Simple Energy about the ‘correct’ implementation of a feature. This argument centered around the issue of accruing ‘tech debt.’

(If you’re not familiar with the concept, check out the wikipedia page.) He argued that a longer implementation time to add additional functionality would save us time in the future. I argued for a shorter, less full functioning solution which was ‘good enough,’ but would likely lead to a small number of distractions for the engineering team in the future. We have very intelligent and highly capable engineers at Simple Energy, so I knew when we couldn’t reach a mutually agreeable conclusion, that I was missing something.

 

One of the most difficult things to work into any engineering workflow — in all the startups I’ve worked at — has been tech debt. This issue becomes highly charged at times because it is painful to deal with for the engineering team, but often hidden or difficult to see for the business decision makers. Having previously coded and led engineering teams, and now leading a product management team, has given me perspective into both sides of this argument, yet I still found myself frustrated trying to explain my position.

 

Then suddenly it hit me. The engineer was convinced that his side had merit because in spending extra time building this feature right, he would be saving more time than he spent in the future. There was a clear net gain, so why would we not build it? The answer is actually relatively simple: opportunity cost.

 

Opportunity cost is an economic concept used to address the allocation of a scarce resource towards mutually exclusive investments. In the tech debt scenario, our scarce resource is developer time and the mutually exclusive investments are specific instances of tech debt.

Example

 

Let’s look at an example to bring some clarity to this. Let’s assume that I have 1 engineer across a four week period and 4 pieces of tech debt with estimated paybacks over the next 18 months. (Granted it’s never this black-and-white in the real world — maybe just try to put it in hours, days, weeks, months instead.)

Item Initial Cost Time Saved — over next 18 months
Issue A 3 weeks 5 weeks
Issue B 1 week 4 weeks
Issue C 3 weeks 8 weeks
Issue D 6 weeks 5 weeks

 

Looking quickly at this list, we can see that Issue D should simply never be address. It has a net value of -1 week of productive time. From there it gets trickier though. We have 3 issues, all of which will provide net productivity gains from completion.

 

Yet we don’t have infinite resources; we have 4 person-weeks of time. Assuming the repayment of the debt is simply evenly distributed across the next 18 months, we will want to make sure that those limited resources are being used to address the largest gains possible first. In this case, Issue B wins by providing us with a 4x multiplier on our investment. Following this, Issue C gets us a 2.67x multiple and Issue A returns 1.67x. Therefore, our best option is to invest our 4 weeks into issue B followed by Issue C, returning a total of 12 weeks of benefit for our 4 week investment.

 

Looking at this through the lens of opportunity cost, we see that addressing feature A comes at the cost of not addressing 2 higher return issues, leaving us with a less-than-optimal outcome. This means our best choice is not to address issue A0 at all in this scenario.

 

This is the piece I was missing while explaining why I didn’t believe we should have been addressing the issue raised by our engineer. While building this feature ‘right’ would cost us roughly a week and likely save us 1-2 weeks of wasted time in the future, there are a number of other items in our tech debt backlog which we could be spending time on which will provide higher-than-1-2x multipliers on time investmented. Those are where we should be focusing our time, or we will lose ground with competitors, or worse, run out of capital before we reach our goal.

 

Coming Soon:
All this theory is nice, you may say, but how the hell do I intelligently put tech debt into my feature backlog? Well, that’s for another blog post.

Should I Use a P&L as a Product Manager?

I was recently trying to determine the value of building a P&L for some development projects. Concerned that it might end up being a time sink that doesn’t pay off in the end, I asked a mentor of mine for his thoughts. Here’s his reply:
I think if you approach the per project P&L with a big grain of salt, it can be a very useful tool. The grain of salt = your P&L will never be precise and you get diminishing returns past a certain point. Your instinct about using rough numbers and not spending much time is right on, and in fact I’m guessing you wont be able to find much of the accounting info you’d want so you’ll be left making some reasonable assumptions (read: guesses) into your model.  Before you’re done, you’ll have a bunch of numbers that are not at all “accurate” but are very useful for getting a ballpark sense of the world. That ballpark can help you and the team make decisions as well as look for things that are extreme corner cases that you might be overlooking.  As you note, this model could also be useful for evaluating your backlog and again you’ll just be using educated guesses about features::business performance. You don’t have to know exact numbers to answer “does this feature help us sell more? is it a little or a lot? does it help us renew the customer? etc” and the model will help you have a framework for thinking through those questions.

 

I think there might be some sensitivity to calling it a P&L. Instead maybe “business case” or “pro forma project financials” something like that. I’ve also seen people get very sensitive about actually quantifying expense of employees, especially if its a team that isn’t used to a lot of accountability. Just some things to consider.
On a side note, this could also help you spotlight the “one off” stuff you might be doing per customer deploy. That kind of stuff while sometimes necessary is a very dangerous, slippery slope and you’ll feel the pain first as the person responsible for the product. By definition, one off features are not scalable and don’t improve the overall product.

 

Ideally you as the product manager would say “no” whenever you see one. That’s usually not how things work, but having this model and a sense of the cost of doing a one off – in time, $, even feature trade offs – can help you start making the case to say no.

 

– Eric Wu (@ewu on Twitter)

 

This struck me a spot on, so I figured I’d share it. Hope it’s useful.