Accidental Market Debt: When the Market Moves and You Don’t

Have you ever worked for a company that one day woke up to realize that it was no longer competitive in its market?  I have.  It’s surprisingly common.  It’s also a sign of accidental market-based product debt.  This is the thing about talking about debt.  It too often becomes a conversation simply about rot, a natural thing that happens in a living system like software.  But the reality is there are a lot of reasons why the software starts to drift from what the market wants.  If we don’t pay attention to those things, we quickly end up in a very expensive situation where we are paying down debt we didn’t even know we acquired.

Market Threats

I worked for a company that did lead management for OEMs (original equipment manufacturers), mostly in the housing market (think construction equipment, cabinets, hot tubs, HVAC controls).  It was a really interesting market niche.  These large companies sell to consumers like you through independent channels that can vary from big box stores (e.g. home depot) to dealers (mom and pop hot tub store down the street).  But most of the leads (people looking to buy that hot tub) go to the manufacturer to inquire about the product.  So literature flows from the manufacturer and then the lead about that consumer needs to get from the manufacturer to the dealer.  The company I worked for fit really well into that niche, doing qualification and attribution systems along side manual entry of leads and find-a-dealer lookups for distribution.

Then in 2008 the bottom fell out of the housing market with the subprime mortgage crisis.  At the same time a little company called Salesforce.com became an utter category killer in lead management and sales force automation.  We faced market threats from two sides: customers that didn’t or couldn’t pay and affordable alternatives.  This is accidental/market product debt.  The market changes while you aren’t paying attention.  A category killer competitive threat enters; there are changes to regulation or compliance.  There is a loss of competitive moat.  This isn’t a debt that comes from an intentional choice to do or not do something, it comes from neglect.  Let me give a few more examples.

I worked for a company that had built their competitive moat around HIPAA compliance.  This was an effective moat when the regulation was new.  Hospitals and health systems were scrambling to be compliant with new rules around data storage, access, and protection (same thing happened with GDPR) and are generally conservative movers anyway, not trusting a lot of vendors.  By 2018, though, other companies had figured out how to work with the regulation.  The overall regulatory environment became such that data protection was expected for all kinds of businesses, not just health care.  In addition, the base product we were selling was commoditizing while the market we were selling into was consolidating.  In other words, there was less differentiation between the product offerings and few buyers.  Accidental/market tech debt.  In 2020 the pandemic did the same thing to many companies that relied on in person or high contact products.  2022 brough constriction on VC funding that impacted a lot of startups.  Now we are dealing with AI.  All these disruptions (as I have talked about before) require deft and foresight to navigate well.  And too many companies ignore them until it’s too late.

The lessons from these situations are ones I have learned painfully, and firsthand.  Macroeconomic situations matter.  As product folk we can’t afford to just look inside to our teams.  We must pay attention to what’s going on in the macroeconomy, trends in other companies, emergent markets and competitors.  We don’t want to be overly swayed by competitors (this becomes a different kind of debt), but we also don’t want to be caught unawares like we were in that lead management company.  When you determine that you need to make a pivot, that requires committing to a path.  In the company I worked with that had the HIPAA moat, once they saw that moat drying up they couldn’t commit to pivoting to something else.  They are still trying to defend an ineffective moat.

The tools we can use to protect from this kind of threat come from b-school more than from software development practices.  When is the last time you did a SWOT analysis on your product?  SWOT stands for Strengths, Weaknesses, Opportunities, and Threats.  It’s an honest, non-defensive, look at yourself and your market in the form of a 2×2 grid (man, I love those).  You look at things in the market that will impact your business positively (opportunities) that you can take advantage of or negatively (threats) that you need to defend against.  You then also look at your own product (or company overall) for where you are strong and weak.  This becomes the backbone of a strategic plan.  Companies like Amazon do an amazing job of living in their SWOT.  Another thing to find is your differentiation, your unique moat, your unfair advantages.  These are all different ways of talking about similar concepts.  You want to find the thing that makes your customers say “yes” uniquely to you.  And make that the core of your business.  And fun fact it can’t be “our people are the best” but it can be “culture” when you spend time at it (see Netflix as an example).  Counterintuitive to that is to also think about opportunities to diversify, carefully and protecting your overall exposure (3 horizons is a good model for this).

Technology Changes

There is a similar accidental/market tech debt.  For example, one company I worked with got really excited about using this brand-new framework: Angular 1.  Well, we built a product on top of that and then the framework stopped being supported.  The same thing happened in another case when we were debating between Mongo and SQL.  In another case the debate was whether to move from a monolith to a services architecture.  The root causes of all these situations look pretty similar: committing to a tech stack that becomes unsupported or scope creep and shifting requirements creating unexpected complexity.

The lessons I learned from working on this kind of tech debt is to choose small, internal apps for testing new frameworks, pivot quickly by intentionally protecting yourself with integration layers (something I have ranted about with AI recently), and make sure you are having open debate about your tech stake and where you are investing so be in common, open agreement about the potential debt you are creating.  Regular architecture reviews and help you catch creeping problems before they become breaking.  You should be capturing stories to refactor and test stack changes regularly.  Technical leadership should lead and promote this gap analysis.  As a product person, I encourage experimentation into POCs that we can harden before bringing into the main application.

I always start with this category of tech debt because it is extremely common but rarely talked about because teams think it is outside their control.  But it’s not.  Awareness, proactive conversations, and honest assessment will help you from suddenly running up a huge bill.  Next time, I will talk about the old side of this same problem: accidental/individual debt: those cases where we accidentally create a debt.


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.  Claude loves it’s graph paper style too much while copilot is deep into infographics with a lot of background.  After several rounds I beat chatgpt into something usable.  I continue to find Claude most helpful on inspiring titles and LinkedIn text.