How My Thinking on Product Leadership Has Evolved (2019 → 2026)

I’ve just been updating my website and rediscovered an article from 2019 where I discussed developer productivity with Insight Partners**. Reading it seven years later was… illuminating. Not because I was wrong then. I believe the fundamentals still hold, but my thinking has sharpened in ways I didn’t expect with every incremental experience in product leadership. Good and Bad.

I thought it would be nice to walk you through what’s changed.

The Setup

Back in 2019, I was Director of Product Management at WorkForce Software. Insight Partners convened an interview on developer productivity within the portfolio, and I laid out, along with Ken Surdan, what I believed mattered most:

Clarity of vision
Managing tech debt
Removing ambiguity
Making decisions quickly

All true. All still important. But within the constraints of the interview, a little incomplete.

What I (Think I) Got Right (And Still Believe)

1. Clarity is everything

“Providing clarity and removing ambiguity gives engineers confidence that you know what you’re talking about and why they should follow you.”

Still true. Engineers need to trust that you have a clear picture of where you’re going. Vague product strategy destroys team confidence faster than anything else. Although what is typically sought is a plan, a strategy if presented correctly is far more powerful.

2. Product owns the “why”, Engineering owns the “how”

This boundary still matters. Your job as a PM isn’t to tell engineers how to build - it’s to ensure they understand why they’re building it and what customer problem it solves. Countless articles on AI have massively blurred theses lines to the point you think all PMs need to Senior Developers, however that judgment on ‘why’ is more crucial than ever even if a majority of the value chain is now accelerated by AI.

3. Tech debt isn’t optional

“You have to acknowledge the team’s need to repay debt. Your focus is always going to be on the customer, but you have to balance that with respecting your team.”

The teams I see struggle most are the ones where product treats tech debt as “engineering’s problem.” It’s everyone’s problem. There are great examples of a ‘no bug’ culture out there and still to this day the best PMs in my team work closely with engineering so they feel heard and included on priorities.

4. Make decisions

“I’d rather make a wrong decision than indecision. We move quick enough and light enough that a bad decision isn’t a big deal and can be rectified as needed.”

Still my default mode. Indecision is expensive. Really that decision is typically a learning moment, which if you’ve read previous articles, my argument is that learning is the moat.

What’s Changed (The Nuance I Missed)

1. Vagueness isn’t always the enemy

2019 Mike said: “Clarity of vision is the most important thing, long-term.”

2026 Mike adds: “But vagueness in early exploration is necessary.”

Here’s what I’ve learned or now able to better articulate than before: There are two kinds of ambiguity.

Deadly ambiguity: Vague vision. Unclear strategy. No north star. This kills teams.
Productive ambiguity: Not knowing the answer yet because you’re still learning. This is discovery. Obvious you say but the amount of organisations that still don’t prioritise or do any actual discovery is worrying.

The PM’s job isn’t to eliminate all vagueness, and again, the great one’s thrive on ambiguity, but they need to be crystal clear about what phase you’re in:

Are we exploring? (Embrace uncertainty, learn fast)
Are we building? (Increased demand on clarity, shipping more confidently)

Mixing these up is where teams get lost.

2. Tech debt conversations need to tie to business outcomes

2019 Mike said: “Acknowledge the team’s need to repay debt.”

2026 Mike says: “Help teams understand which debt matters for the product’s next chapter.”

Not all tech debt is created equal. Some of it slows you down. Some of it doesn’t matter for years.

The best PMs don’t just “give the team time for tech debt”, they help the team identify which technical investments unlock the next phase of product growth.

Tech debt isn’t a backlog category. It’s a strategic conversation about where you’re going and what’s in the way. What really matters now, this week, next 4 weeks…

3. Meetings should be rare, not routine

2019 Mike said: “Standup, Planning, and Retro are all meetings which add value.”

2026 Mike says: “Most meetings could be async. The real value is thinking together, not status updates.”

I used to defend the practises, (but have and still detest when they are called ‘rituals’.) Standup! Planning! Grooming Refinement! Retro!

Now I question them by default.

Most of what happens in standups could be written down. Most planning sessions are low-quality thinking disguised as collaboration. Most retros surface issues that should have been addressed in the moment.

The best teams and PMs minimise synchronous time and maximise deep work time. If a meeting exists, it should be because you genuinely need to think together, not because the calendar says it’s Tuesday.

4. Scope changes aren’t inherently bad

2019 Mike said: “Scope creepiness makes the team lose confidence that product has a clear vision.”

2026 Mike says: “Scope changes are bad when they’re reactive. Scope changes are necessary when you’re learning.”

I used to think changing the scope signalled weak leadership.

Now I refine this: Changing scope based on evidence is strong product leadership.

The difference is the “why.”

Teams lose confidence when scope changes feel random or stakeholder-driven. They should gain confidence when scope changes reflect customer learning and strategic clarity, and when positioned as such.

The job was never to lock scope. The job is to signal why we’re pivoting.

5. Speed isn’t the only thing that matters

2019 Mike said: “I frequently just ask for ‘working software at least every two weeks.’”

2026 Mike says: “Before you ask for delivery velocity, ask: have we learned enough to build the right thing?”

This is my personal biggest shift. Deep to my core is the mantra of ‘learning’.

I used to optimise for shipping cadence, likely due to the system I was in. Now I optimise for decision quality.

Shipping every two weeks is valuable - but only if you’re building the right thing. If you’re moving fast in the wrong direction, velocity is a liability. This has always been a case and one I’ve expressed verbally.

The best PMs still need to create space (hold space now it’s 2026 :) ) for strategic thinking before tactical execution. They challenge false urgency. They know when to slow down and learn.

What I’d Add to My “12 Positive Things” List

In the 2019 article, I shared 12 things I do as a Product Manager to help development teams succeed.

Here’s what I’d add in 2026, 7 years later*:

13. Write things down

Decision logs, strategy docs, and clear written artifacts beat verbal clarity every time. If you can’t write it clearly, you don’t understand it clearly.

14. Protect discovery time

Before you ask for delivery velocity, make sure the team has had real space to learn. Discovery isn’t a luxury - it’s how you avoid building the wrong thing fast.

15. Make space for strategic thinking

PMs need uninterrupted time to think, not just coordinate. Block time to wrestle with hard problems. Your calendar shouldn’t just be stakeholder management.

16. Default to outcomes, not outputs

Don’t measure “features shipped” - measure “customer problems solved.” Output is easy to track. Outcomes are what actually matter.

17. Challenge false urgency

Most “urgent” requests aren’t. Help stakeholders distinguish real deadlines from manufactured ones. Your job is to protect the team’s focus, not accommodate every fire drill.

*I couldn’t tell you if this was 7 years of bad luck or 7 years of good luck. I’ve met and continuing learning from some incredible people, have had amazing opportunities, but also lived the realities of many product leaders (IYKYK). However, whether it was good or bad, I’d like to believe I’m all the better product leader for it.

The Through-Line

What hasn’t changed: Product leadership is about creating the conditions for teams to learn and make high-quality decisions.

What has changed: I’m less dogmatic about how that happens.

Clarity still matters. But so does knowing when to embrace uncertainty.

Speed still matters. But so does knowing when to slow down and learn.

Vision still matters. But so does being willing to change course when the evidence says you should.

Final Thought

If you’re early in your product career, the 2019 advice is probably what you need right now: Get clear. Focus. Make decisions. Ship fast.

If you’re more experienced, the 2026 nuance is probably where you’re headed: Know when clarity matters. Know when speed matters. Know when to challenge the defaults.

The fundamentals don’t change. But the wisdom is in knowing when to apply them.

Read the original 2019 discussion: Tips from the Top: How to Boost Developer Productivity (Insight Partners)