Liz's PM notebook · Field note
Ways of WorkingThe PM Work Between the Milestones
The invisible product management work that happens between roadmap milestones and determines whether those milestones mean anything.
Every roadmap has the same shape: a row of diamonds, each one a milestone, connected by a thin line that implies the space between them is just... time passing. Design review. Beta. GA. The line between the diamonds looks empty on the slide.
It isn't. That line is most of the job.
What actually happens in the gap
Between "spec approved" and "design review," someone has to notice that two teams read the same requirement differently and are quietly building incompatible things. Between "beta" and "GA," someone has to decide whether a bug that only shows up under a specific account type is a blocker or a known issue, with real consequences either way and no clean rule to apply. Between "approved" and "shipped," someone has to keep going back to an engineering lead who's now three sprints deep and doesn't want to hear that the requirement shifted, and make the case for why it has to shift anyway.
None of that is on the roadmap. None of it produces a diamond. All of it determines whether the next diamond happens on time, happens at all, or happens as something quietly different from what was promised.
I've noticed the PMs who look the most in control aren't the ones with the cleanest roadmap slides. They're the ones who've done this invisible work so consistently that the milestones just... land, on schedule, matching spec, without anyone downstream having to absorb the cost of decisions that didn't get made. From the outside that looks like nothing happened. From the inside, that's the whole job.
Why it is invisible by design
The work between milestones resists being logged because most of it doesn't resolve into an artifact. You don't ship the Slack thread where you talked an engineer out of a scope-creep "quick fix" that would've broken the permission model three months later. You don't put "had the uncomfortable conversation about why the metric everyone liked was actually unmeasurable" on a slide. It just becomes the reason the next milestone was clean.
This creates a real incentive problem. If you're rewarded on milestones, and the milestone work is visible while the gap work isn't, the rational move is to under-invest in the gap and over-invest in milestone theater: polished reviews, clean-looking dashboards, and decks that make progress legible even when the underlying work is shaky. I've watched teams get very good at producing the appearance of the diamond without doing the work that makes the diamond durable. It always shows up later, usually right when it's most expensive to fix.
What the gap work actually looks like
It is rarely dramatic. It is:
- Catching a misalignment in interpretation before it becomes two incompatible implementations, which means reading specs closely enough to notice ambiguity other people glossed over.
- Making a judgment call on an edge case with no clean precedent, and being willing to own that call instead of escalating it to make it someone else's problem.
- Going back to a stakeholder with bad news early, when it is still cheap, instead of waiting until it is undeniable and expensive.
- Saying no to a scope addition that would look fine on this milestone and cause real damage two milestones from now, and having the technical grounding to know the difference.
The actual measure of the job
That last point is why the gap work is so tied to actually understanding the system you're building on. You can't make a good call about whether a shortcut is safe if you don't understand what it's a shortcut around. The PMs who do the gap work well are usually the ones who went and learned enough about the token flow, the data model, and the failure modes to know which corners are load-bearing and which aren't. That knowledge doesn't come from the roadmap either.
If you want to know whether a PM is good, don't look at whether the milestones happened. Milestones mostly happen regardless. Someone will always ship something by the deadline. Look at what the thing looks like when it ships, whether the team that built it is still functional afterward, and whether the next milestone is easier or harder because of choices made in the gap before it.
The roadmap is the record of what got decided. The work between the milestones is where it actually got decided. One of those is visible. Only one of them is the job.