“We have to choose between these features and this needed upgrade to .Net Core”

“Competitors just released a new feature and our customers are now asking when we will have it too.”

“Our OWASP scan says we have these security risks”

“We have become dominate in this market so we should explore what opportunities there are in that other market”

“Don’t worry about that monitor, it’s always red”

We have all had these moments.  The tradeoffs are real, the external pressures are intense, something must give.  And whichever road you end up taking it, it doesn’t make any difference: it all creates debt.  Robert Frost need not apply.

This is the debt we create when market forces create pressure and industry standards change.  We have no control over the environmental impacts but we must make an intentional decision what to put off.  Often this looks like choosing between a major platform upgrade and a feature, one market and another, or quality of life improvements vs customer requests.

Neglect

On the technical side, the market changes include major runtime or platform updates, deprecation of 3^rd party dependencies, neglected security standards, or aging/failing test suits.  When you look in a code base and see plain text or hard coded passwords that is a sign that someone made a tradeoff years ago and now you are paying that debt.

I remember at one company I worked with we had a monitor up on the wall that showed all the test suites as colored blocks.  Many of the blocks were red day after day.  So, one day I asked one of the lead engineers about it.  He said not to worry about it, those tests are always red.  They are noisy and we never know if the errors are real or due to anything we have changed recently so we ignore it.  I asked if we should take the time to fix them and he told me the juice wasn’t worth the squeeze because that was a part of the system, we were actively rewrite and decommissioning.  So, you know what I did?  Told him to remove the tests from the monitor.  That kind of intentional decision to ignore something creates false positive blindness that bleeds into everything.

We can’t control when the environment changes, but it is part of our job to keep on top of a changing industry and standards.  And right now the industry is changing rapidly, which means we are creating this type of debt rapidly as well.  Trading off something with the speed to market and automated code generation.

There are solutions here though.  It starts with the intentional part of the debt.  Audits should always come with action plans of when security or other risks will be addressed.  Create a safe space to raise up what the trade-offs actually are.  But most importantly, understand Conway’s law is and when express ownership is necessary.

Conway’s law states, simply, anything an organization builds will look like the structure of that organization.  If you have an isolated security team then thinking about security gets delegated to that team instead of feeling like everyone’s responsibility.  If the engineering team is isolated from customer requests and product it won’t build software that solves customer needs.  Expressly saying a team owns an application experience is a good thing but make sure you are cutting your cake so you have a complete piece instead of just icing (e.g. an isolated process).

Market Opportunities

Often the intentional market tech debt comes from neglecting technical upgrades in favor of product features.  On the product side of the house, intentional market debt looks like trading off one market segment for enough or being overly reactive to competition.  It’s just the nature of business that it is truly rare, and usually following catastrophic failure, that we put features on hold in order to solve a major technical problem.

With product thinking comes learning about how extended you can become and then actively derisking the balance between markets you are serving and opportunities you are evaluating.  I have worked with companies that have become so dedicated to a specific segment that when macro events changed the nature of that segment, they were overextended to the point of no longer having a customer base.  On the other hand, I have also worked with companies where their offering was so generic, not thinking deeply about segmentation, as to be uncompetitive.  One lesson I have taken from this is to document your “whys” behind market focus and reevaluate regularly, considering changing market conditions.  We talked before about living your SWOT in accidental market debt.  With the intentional side this becomes design thinking, horizons planning, regular market segmentation, value proposition canvases (link is to strategyzer’s excellent template), and hypothesis testing.  Basically these are all tools you can regularly use to keep focused on what those international tradeoffs are between markets.

Project Management Iron Triangle vs Product Management Triangle

I know when I provide that list of tools that I say is important to avoid, or respond to, this kind of debt what a lot of product managers are thinking right now: how do I find the time?  That is because we have confused project management and product management over time.  Both are essential skills.  And both are part of the job of a product manager.  But there is a huge difference on the scope of the two sets of work and the easiest way I have had to explain this is the iron triangle.

In project management the iron triangle is scope, cost and timeline.  Project management often talks about these in terms of trade-offs.  If one side changes, the other sides also must change.  For example, we increase scope in the project (I know, never happens).  Then we need to either change the cost or the timeline.  Or sometimes both.  In this case cost could include the number of people on the projects or it could include buying an external solution or AI tokens.  If we shorten the timeline, the scope needs to increase and/or the cost needs to increase.  This is a valuable way to talk about tradeoffs in a project mindset.  And it’s a conversation I have frequently had.  And, of course, we have to be wary of the mythical man month (an excellent short essay if you haven’t read it by Fred Brooks) in those trade-off conversations (e.g. when you add more people to a project it can make the project take more time).

This is project thinking and there is no problem with project thinking.  If your goal is to complete a feature on time and under budget it’s the right way to think about things.  But if you own a product that is living and breathing you end up exchanging long-term thinking (like about markets, competition, lifecycles) for short (delivering features).  So I tend to think about both a project management iron triangle and a product management triangle.  The time vs scope vs cost tradeoffs become one tradeoff in product management which I have called “constraints”.  The other two tradeoffs are quality or scalability and value.  If you want to focus more on project constraints, then you don’t have the time to make something high quality and scalable and/or lose out on market value.  If what’s most important to you is proving market value (which is where every startup I have worked with ends up) then you are reducing the predictability of your releases (constraints) and/or making a lower quality and less scalable product.

Product thinking means you have to take time to think about these other factors and let some of the rigor of delivery slide or be someone else’s job.  I’ve had the honor of working with some very talented delivery leads, quality assurance engineers, release managers, and project managers who have given me the time and space to focus on product thinking.

Three Horizons

Another tool for dealing with intentional market product debt is the three horizons model.  But this is also the point where I realize this blog post has become too long and three horizons is a huge topic.  So here is where I promise that I will take a slight diversion from my debt model to go in depth on three horizons in my next post.  So consider that a pin.

As we have explored, things are constantly changing and we have to intentionally decide what to focus on.  As my theatre professor told us all the time: you are always making a choice.  If you decide not to decide, you have made a choice.  So let’s at least be active in the decision making and pay attention to what is happening around us.

---

Note: I don’t use AI to help write my posts or create example pictures. I do use AI to create the header image (sometimes). In this case I prompted Claude (Anthropic), Gemini (Google), ChatGPT (OpenAI) and CoPilot (Microsoft/GitHub) by giving it my blog post.  In a surprise move, Gemini won this round though copilot had a solid runner up option.