April 8, 2026 · 3 min read
Scaling your PM practice before it breaks
The PM practice that got you here was designed for a team that doesn't exist anymore. Here's how to scale it before the cracks show.
There's a version of this story that plays out at almost every startup that gets traction.
Early stage: one PM, close to the product, close to the users, making fast decisions. It works. Then the team grows, the product gets more complex, and suddenly the thing that made you fast — one person knowing everything — is the thing slowing you down. The PM practice didn't scale with the product. And by the time anyone notices, you're six months behind where you should be.
This is a predictable problem. Which means it's a preventable one.
The first sign is always the same
Decisions start taking longer. Not because the team is slower — because the process that worked at ten people doesn't work at thirty. The roadmap is still in someone's head. Priorities are still resolved in ad hoc conversations. New team members don't know how decisions get made because nobody wrote it down.
This isn't a people problem. It's a system problem. The PM practice that got you here was designed for a team that doesn't exist anymore.
What actually needs to change
Three things break first when a PM practice doesn't scale, and they're worth fixing in this order.
The roadmap needs to stop living in someone's head and start living somewhere everyone can see it — with the why, not just the what. Every item should have a line that says: we're building this because we believe it will move X. If you can't write that line, the item isn't ready to be on the roadmap.
Prioritisation needs a framework that the whole team understands and can apply without the PM in the room. RICE works. MoSCoW works. The specific framework matters less than the consistency. When everyone uses the same criteria, fewer decisions need to escalate.
Communication needs to become proactive, not reactive. At small scale, everyone knows what's happening because they're in the same room. At larger scale, that stops being true. A short written update — what's happening, what changed, what's next — sent regularly to the right people eliminates most of the status meetings.
What not to change
The instinct when things slow down is to add process. More ceremonies, more meetings, more sign-offs. That's usually the wrong answer.
The thing that made the early-stage PM practice work — fast decisions, close to the user, clear ownership — is exactly what you need to protect as you scale. The goal isn't to become a larger version of a corporate product team. It's to add just enough structure that the fast, user-close decision-making can keep happening at greater scale.
More process doesn't make you faster. Clearer process does.
The moment to act
Don't wait until things are broken. The time to formalise the PM practice is slightly before you feel like you need to — when the team is growing but the cracks haven't appeared yet. By the time the symptoms are obvious, you're already six months into the problem.
Look for the early signs: decisions escalating more than they should, priorities shifting without a clear rationale, new team members confused about how things work. That's the signal. Act on it early and you won't have to fix it under pressure.
For the prioritisation piece specifically, I've written about which frameworks hold up at different stages and how to make prioritisation a system. And for the communication side, building stakeholder communication as a system is where the proactive updates piece lives.