Tag: finance

Intentional Market Debt: Neglecting Your Way to Success

Posted on Posted in UncategorizedTagged , , ,

“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 3rd 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.

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

Posted on Posted in UncategorizedTagged , , , , ,

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.