top of page

Maybe PM should be slow

Updated: Feb 1

Ohh, what's really going to bake your noodle later on is, would you still have broken it if I hadn't said anything?
Ohh, what's really going to bake your noodle later on is, would you still have broken it if I hadn't said anything?

What if Product Management isn't about going faster? What if the whole point of Product Management is to SLOW THINGS DOWN?


Here's what happens when you just let developers develop:


  • They build things

  • Quickly

  • Really quickly

  • Cool things

  • Interesting things

  • Things they thought of in the shower

  • Things they saw on Hacker News

  • Things they want to rewrite "the right way"


And that's... actually the problem.


Developers are amazing at turning ideas into code. Give them a problem and boom - there's a solution. Usually several solutions. Usually by tomorrow morning. Usually with a new framework they're excited about.


But here's the thing about software (and we've talked about this before) - it's CUMULATIVE. Every single thing you build sits there forever, like digital sediment, forming the foundation for everything that comes after.


So maybe the real job of Product Management is to be the speed bump. The pause button. The "wait, but why?" person.


Because going fast isn't the hard part. Any decently caffeinated dev team can crank out features.


The hard part is going slow enough to:

  • Build the right thing

  • In the right order

  • For the right reasons

  • That will still make sense in 6 months

  • That won't paint you into a corner

  • That actually solves a real problem


This is why PMs often feel like they're playing defense:

  • "Can we validate that first?"

  • "What problem are we actually solving?"

  • "How does this fit into our strategy?"


It's not because PMs are trying to be difficult. It's because somebody has to ask these questions before that code becomes a permanent part of your product's DNA.


Development without PM = high velocity, random direction

Development with PM = low(er) velocity, intentional direction


You're not adding a PM to make development go FASTER. You're adding a PM to make development go BETTER.


This is why good PMs often feel like they're swimming upstream. Everyone else is shouting "FASTER! MORE! NOW!" and you're the one saying "wait, but why?"


And yes, sometimes this means you're the bad guy. The party pooper. The one who keeps asking annoying questions when everyone else just wants to start building.


But that's the job.


Because going fast isn't a strategy.

Building things isn't a strategy.

Even building GOOD things isn't a strategy.


The strategy is building the RIGHT things, in the RIGHT order, for the RIGHT reasons.


And sometimes, that means slowing down.


bottom of page