The Product Manager’s Guide to Not Slowing Things Down
Length: • 4 mins
Annotated by Miguel
Why speed is the most underrated product strategy.
There’s a moment in every product cycle when you feel it. Usually after the third “quick sync” of the day.
The roadmaps fuzzy. The backlog is stale. Someone on Slack is writing a five-paragraph “+1.”
You’re stuck.
And the only way out is to ship something.
That’s it. That’s the post.
Well, not quite. But it really is that simple. Velocity solves everything.
Speed isn’t a vibe. It’s a muscle.
Malte Ubl (CTO at Vercel) said it nicely:
Iteration speed solves all known software problems.
At first that sounds like a meme. But once you’ve lived through a few quarters of overthinking, it hits like a gospel truth. Because most product problems—messy UX, tech debt, unclear value—don’t get solved in meetings. They get solved in motion.
You build. You learn. You fix. You repeat.
Speed isn’t about recklessness. It’s about respect. It says: I wont waste your time guessing.
It trades theory for evidence.
Just one example: we recently added Bun to the Docker image for Jules. It could have turned into a whole thing, a PRD, a strategy doc, some hand wringing over compatibility.
Instead, we treated it like what it was: a simple improvement. I wrote a coodination checklist. No speck, no kickoff meeting. There was a small bug with the agent, which took an extra day to track down, but no swirl, no meetings. Just heads-down problem solving and forward motion.
Now it’s live a few days after we kicked off the work, and no one had to sit through a single meeting about it.
That’s what iteration velocity looks like.
You build, you learn, you move. No ceremony, just progress.
Engineering isn’t the bottleneck. We are.
Let’s name the real problem. It’s not engineering blockers.
It’s PM swirl.
The Jules engineering team is fast. They’re smart, decisive, and ship daily. The secret is that no one asked a PM to show up. They don’t need another voice in the room. They need clarity. Speed. Space to build.
One of the best lessons I’ve picked up over the years is this: Put a great designer and a strong engineer in the same room, and then leave. What they make will probably delight you.
Our job is to create the conditions for that to happen, not to participate in it. And definitely not to slow it down.
But that’s what happens when we hesitate.
When we soft-circle decisions.
When we confuse “alignment” with “delay.”
We reopen threads. We crowd conversations. We rewrite the same doc three times because the formatting “feels off.”
Velocity dies in ambiguity. And ambiguity often dresses itself up as thoughtfulness.
So what does product management do here?
We do the work that unblocks the team. And we do it clearly.
Useful looks like:
- Writing the changelog so an engineer doesn’t have to.
- Running evals and triaging bugs.
- Drafting docs early, even if things will change.
- Validating data and cleaning up broken dashboards.
- Labeling GitHub issues so they’re clear and actionable.
- Taking customer calls when something breaks.
- Keeping the roadmap accurate every single day.
- Testing the product on real tasks (and filing bugs when it hurts).
- Writing checklists for every launch, even small ones.
- Prototyping flows to reduce back-and-forth.
- Following up, closing the loop, moving things forward.
- Saying “I’ll own it” and actually owning it.
A few months ago, I wrote a launch tweet before the feature existed. It helped clarify what we were building. That tweet became the changelog. The docs stemmed from there. Clarity scales.
Useless looks like:
- Asking open-ended questions you already know the answer to.
- Re-discussing decisions that were already made.
- Waiting for alignment instead of proposing a path.
- Offering feedback without a next step.
- Hosting syncs when an async update would do.
- Generating ideas without owning execution.
- Escalating issues without a first pass at solving them.
- Taking action that looks useful but leaves engineers with more questions.
I’ve done all of these. This isn’t a burn book. It’s a mirror and lessons learned.
Want to move faster? Try this.
Here are a few things I’ve seen actually work:
- Make a personal velocity board. Three columns: shipping, stuck, who owns it.
- Prewrite the launch docs. Even if it’s early. What will the tweet be? What will the changelog say? Which docs do you update and what’s the copy? What’s the blog post?
- Send a daily update: “Here’s what moved today.”
- Own your next three launches. Timeline, checklist, docs, users, support, actual dogfooding where you live in where it hurts.
- Stay two days ahead of engineering. Not to direct, just to be ready. (Knowing where the pain is helps with this).
- Kill your pet idea. Focus outweighs cleverness.
- Default to clarity. Even when it’s imperfect.
I once made a rule for myself: if something sits in Figma for more than ten days, it dies or ships. No purgatory. Just momentum.
The job is to help the team move. That’s it.
If nothing waits on you, you’re doing it right. If engineers feel like they can fly, you’re doing it right. If users see value faster becuase you did something quietly useful, you’re doin git right.
You don’t need reinvention. You need rhythm, motion, and follow-through.
Velocity isn’t a thing you say, it’s how you show up. Velocity isn’t the goal, it’s how you work.