@nurijanian
I help smart Product People expand skills, make smart choices & lead confidently ✨Get My 100+ AI Prompts for Product Work ➡️ http://tiny.cc/100-ai-prompts get 20% off all my products ➡️ http://tiny.cc/product-bundle
12/ To summarize:
1. Map impact, not details
2. Create shared visibility
3. Pick strategic battles
4. Maintain the 20/20/60 rule
5. Track frustration metrics
6. Make engineers partners
Found this useful? Follow me for more PM crisis survival guides 🎯
11/ Remember: You're not just managing code.
You're managing people.
Engineers don't quit because of tech debt.
They quit because they feel unheard.
Make them part of the solution, and they'll help you fix it.
10/ Real talk: You need a system for this.
I keep my tech debt tracking templates in prodmgmt.world (it's helped hundreds of PMs in similar situations).
And if you want AI prompts to help write tech debt assessment docs, reply "prompts" below.
9/ Your secret weapon: The 20/20/60 rule
20% of time: Must-have features
20% of time: Tech debt reduction
60% of time: Regular development
This balance keeps everyone sane.
Don't break this rule for 3 months. Watch team morale improve.
8/ When engineers say "We need to rewrite everything":
Ask: "What's the smallest change that would make your job 50% easier?"
Often, it's not a full rewrite.
It might be:
- Better testing tools
- Automated deployments
- Code cleanup in one critical area
7/ Specific tactics that work:
Morning standup: "What technical issue slowed you down yesterday?"
Weekly retro: "Rate your frustration with our codebase (1-5)"
Monthly planning: "Which tech debt directly affected customers?"
Track these metrics religiously.
6/ For product leaders reading this:
Your PM needs your support here.
They're not being slow or indecisive.
They're preventing a costly crisis.
Every week of tech debt investment now saves months of emergency fixes later.
5/ Here's the hard truth about tech debt:
If you try to fix it all, you'll fail.
If you ignore it all, you'll fail.
The secret is to pick the right battles.
Focus on debt that:
1. Blocks revenue features
2. Causes customer pain
3. Makes good engineers quit
4/ Create a "Tech Debt Impact Matrix"
X axis: Business Impact (Low to High)
Y axis: Engineer Frustration (Low to High)
Plot every issue they raise.
This does two things:
- Shows you're listening
- Creates shared understanding of priorities
3/ Your engineers are probably right about the problems.
But they're likely wrong about the solution.
They'll want to fix everything.
You need to make it strategic.
Here's how to turn angry engineers into strategic partners:
2/ Most new PMs make this critical mistake:
They try to understand *all* the technical debt first.
Don't.
Instead, map the impact first:
- Which issues block new features?
- Which ones cause production incidents?
- Which ones slow down development?
1/ First, breathe. If you're feeling overwhelmed, that's normal.
Technical debt isn't just a technical problem.
It's a trust problem.
It's a morale problem.
It's a business problem.
But there's a way through this.
If you inherit a product with massive tech debt, then your first 30 days will define if your engineers stay or quit.
I've watched 5 engineering teams implode because their PMs made the same mistakes.
For 4 years, I had to fix a few such disasters.
Here's what actually works:
I hope you've found this thread helpful.
Follow me @nurijanian for more.
Like/Repost the quote below if you can:
8/ I've collected prompts for having these hard conversations with executives in tiny.cc/ai-prompts
But remember: Even without fancy frameworks, being honest about uncertainty is better than pretending to be certain.
7/ A simple game plan for your next ROI conversation:
1. Talk in ranges, not exact numbers
2. Connect work to company goals
3. Show what could go wrong
4. Ask for sales commitments
5. Explain maintenance needs
Your executives will trust you more.
6/ Here's a framework that works better than ROI:
If someone pushes you for exact numbers, ask them:
"If we commit to building this by June, can you commit to selling $ X by September?"
They'll understand the challenge immediately.
5/ The secret most PMs don't know:
Half of all development work is just keeping the product running well.
If you don't do this work, your product dies slowly.
This work needs no ROI justification.
It's like changing the oil in your car.
4/ Here's what smart PMs do instead:
When an exec asks for ROI, they shift the conversation to ranges and risks.
Instead of saying "This will make $1M"
They say "This could make between $500K-$2M, and here's what could go wrong..."
3/ If you work in a big company, there's an even bigger trap:
You can't tell which feature made you money.
If your product has 50 features and you add 3 new ones, you'll never know for sure which one drove the sales up.
2/ Here's a real story:
A PM was asked to predict ROI for a new feature.
Engineering said it would take 3 months.
It took 9 months.
Sales said it would make $2M.
It made $500K.
The PM looked incompetent.
But this happens ALL THE TIME.
1/ If someone asks you for the ROI of a product feature, they're asking you to predict the future twice:
First prediction: How much will it cost to build?
Second prediction: How much money will it make?
If you multiply two guesses, you get an even bigger guess.
I lost a major product initiative because I couldn't "prove the ROI."
If you're a PM dealing with ROI pressure, this will save you a lot of pain.
After helping a few fellow PMs with this, here's what actually works 🔍
Question for PMs: What's the smallest change you could make to simplify your planning today?
Bonus: If you want a simple planning system template, I've curated several in prodmgmt.world
They're designed specifically for small teams, tested by real PMs.
No enterprise complexity. Just what works.
For product leaders reading this:
Your small-team PMs need permission to:
1. Simplify drastically
2. Focus on outcomes
3. Skip processes that slow them down
4. Build momentum through shipping
Help them do less, better.
The uncomfortable truth:
90% of small-team PMs I work with spend more time:
- Managing their tools
- Updating processes
- Creating workflows
Than actually:
- Talking to users
- Solving problems
- Shipping value
What about all those customer requests?
Keep a simple log:
"Customer X asked for Y on [date]"
Review it quarterly.
If something keeps appearing, it moves to NOW/NEXT.
If not, it stays in the log.
4. Your roadmap format:
Single page with:
- 3 month commitments
- Major dependencies
- Key outcomes
If it doesn't fit on one page, you're trying to do too much.
(Product leaders: This is perfect for board updates too)
3. Your prioritization framework:
"Will this matter in 3 months?"
If yes → Consider for NOW
If maybe → Put in NEXT
If no → Drop it
Save that fancy prioritization matrix for when you have 10+ PMs.