I once had a conversation with another product manager which went something like this:

“I finally figured out that there is a problem with the overnight load.”
“Oh, how did you discover that?”
“Let me show you this spreadsheet.  Right here, see, the numbers don’t match.”
“What is this spreadsheet, how did you get that data?”
“Every night this week I got up and manually counted the number of files in the folder at 11, midnight, 1 am, 2 am, and 3 am.”
“Wait, what?  Why didn’t your engineers write a script to check instead of you getting up?  That is a pretty simple script to write.”
“They didn’t believe me there was a problem.  This is the only way I could prove to them there was a problem and look, right there, there is a problem.”

We all have blind spots.  And there are symptoms of these blind spots we can see in daily life: dead letter queues that never get resolved, manual reviews of file movements, insufficient monitoring or logging, poor audit trails.  These are all signs of a group learning to be an adult team.  I can this kind of accidental, individual debt application or product vision because on both the software and strategy side it comes from the same root causes:

• Erosion of leadership presence and decision-making clarity
• Lack of a high level/architectural view
• Experience gaps, absent collaboration, skipped reviews
• Psychologically unsafe environments that punish early honesty
• Holes in key indicators creating insufficient signal that something has gone wrong
• Analysis paralysis replacing timely, grounded decision
• No strategy or upfront requirements to anchor decisions
• Tunnel vision from a loss of user intimacy and product vision

In other words, people at the ground level do the best they can but can’t align to a vision that isn’t present.  And without guiding principles, vision, and time to align to them, they can’t possibly make the right decisions.  Most of the time when an engineer tells me the application is sinking in debt, this is the kind of debt they mean even when they type we are most likely to prioritize is accidental/market debt (which we previously talked about here) when a tech stack becomes unsupported or intentional/market debt (upcoming post).  The reason we don’t like to talk about this despite it being so come is because the call is coming from inside the house.  And more often, because someone above us didn’t do something leaving us to make the best of a bad situation.

At one gig I had, one of my engineers always called me either “la jefa” or “the man”.  It was a not-so-subtle reminder that I had not only the honor, but the responsibility, of seeing around corners and helping make sure we didn’t end up in a blind canyon.  In our modern age, this is the place I think AI is going to create the biggest mess that future generations of engineers will be mucking out.  One of the ways I did this was creating an explicit prioritized debt backlog.  We regularly, in retros, discussed places with the biggest debt, both product and tech.  These were places where code joy diminished, features were unused, we saw dissatisfied clients based on win/loss calls or called out in proposals.  We would document these and, as much as possible, quantify the pain.  We did this through a combination of maintenance costs and loss of potential markets.  We did this often enough, and in an very open psychologically safe, people started to bring up things they had just coded.  “Hey, I just built this and it did the thing, but I think it’s gonna be a problem later” became a regular discussion point.  We would also quantify the difficulty to repair in terms of level of effort and complexity or amount of commitment.  It is easier to do this as a 2×2 chart that’s either effort v value or importance v urgency.

I would take this prioritized debt backlog and prioritize it alongside features.  The same way we would allocate time for maintenance or foundational work.  I would keep it visible to the team so that as there were spare cycles it was easy to pick up something that made our lives better.  Product debt in this category works similarly and benefits from the same effort to make it visible.  Where is something requiring significant effort and can be automated away?  Where haven’t we spent enough time understanding if the thing we built is actually solving customer problems.  In that case, the solution is to observe real customers and iterate.

On a broader loss of product vision, I spend time looking at our vision and running exercises to focus or goals:

• Identify market segments and user personas and then talk to real people to validate them
• Ask “What will our application look like in a year?” and “We create ____________ for _________.” And see where answers vary.
• Create team visions or product visions and see how they align to the organizational vision.
• Track “promises in progress”: things you have promised to customers but not yet delivered
• Build in metrics and OKRs/KPIs and have a regular review cadence that isn’t about reporting up but self-awareness

Where have you run into this kind of debt before and how did you convince your organization to face it head on?

Next time we are going to the other side of the grid: debt created intentionally by actively deciding to put something off.  We will start with external/intentional 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) by giving it my blog post.  Claude and Gemini came up with the best ideas but Claude executed way better.  I was extremely disappointed with ChatGPT this time.  CoPilot did a good job but it felt a bit too trite and like every other AI generated image.