The Product Manager (PM) is the person who decides what to build, negotiates when to build it, explains why it’s being built, and absorbs the blame when it shouldn’t have been built — all without the authority to build anything themselves.
The Product Manager owns the roadmap, which is a document describing what the company will build over the next twelve months, revised every six weeks, believed by nobody, and referenced by everyone. The roadmap is simultaneously the PM’s most important artifact and most obvious fiction — a plan that will not survive contact with the next CEO town hall, the next enterprise sales deal, the next production outage, or the next morning, depending on the volatility of the organisation.
The PM is the only role in technology that is accountable for the outcome without controlling any of the inputs. The PM does not write the code (Engineering Manager). The PM does not approve the budget (CFO). The PM does not set the strategy (CEO). The PM does not hire the team (HR). The PM decides what to build, then asks other people to do every part of the building, then presents the result as if it were a coherent plan rather than a series of negotiations, compromises, and the specific exhaustion of a person who has said “that’s a great idea, let me add it to the backlog” four hundred times while knowing that the backlog is where ideas go to die.
The Intersection
The PM’s job is to stand at the intersection of four competing forces and disappoint each one slightly rather than disappoint any one completely:
The CEO wants the product to match the vision they presented at the last conference. The vision was aspirational. The vision did not include a timeline, a budget, or an acknowledgement that the engineering team is already behind on the previous vision. The PM must translate the vision into work without telling the CEO that the vision cannot be built in the timeline the CEO promised the board.
The Engineering Team wants to build the thing correctly — which means addressing Technical Debt, refactoring the module that breaks every Tuesday, and not committing to dates that require the team to work evenings. The PM must protect the engineering team’s capacity without telling the CEO that protecting the engineering team’s capacity means the vision ships later.
The Customers want the thing they asked for, which is not the thing they need, which is not the thing the PM is building, which is not the thing the CEO announced. The PM must manage customer expectations without telling the customers that their request is item #347 on a backlog of 400, and that items #1 through #346 were also described as “critical.”
The Sales Team wants the feature they promised to the enterprise client during a dinner that the PM was not invited to. The feature does not exist. The sales team promised it would ship in Q2. It is now Q1. The PM must decide whether to build the promised feature (disrupting the roadmap) or explain to the enterprise client that the feature was not promised (contradicting the sales team). The PM will do neither. The PM will find a creative interpretation of an existing feature that partially satisfies the promise, present it to the client as “exactly what you were looking for,” and add the real feature to the backlog at position #401.
The PM vs. The Product Owner
The difference between a Product Manager and a Product Owner is a question that has launched a thousand LinkedIn posts and resolved nothing.
The theoretical distinction: the Product Manager is strategic (what to build and why), the Product Owner is tactical (what to build next and how to describe it in a User Story). The Product Manager talks to customers and the market. The Product Owner talks to the development team and the Backlog.
The practical distinction: in most organisations, it’s the same person with two titles, attending two sets of meetings, doing two jobs for one salary, and satisfying neither role’s expectations because fulfilling one requires time that the other consumes.
In organisations that have both roles, the PM and the PO spend approximately 30% of their time coordinating with each other, which is time that neither of them has, producing alignment that neither of them needs, because the alignment was obvious before the meeting and will need to be re-established after the next Sprint Planning session anyway.
The Backlog
The PM’s backlog is a list of everything the product could become, ordered by a priority system that appears rational but is actually a political document.
The top of the backlog: items the CEO mentioned in a town hall, items the enterprise client was promised, items that are on fire. These are built.
The middle of the backlog: items that would genuinely improve the product, supported by data, requested by customers, technically sound. These are “prioritised for next quarter.” Next quarter, they are prioritised for the quarter after. They migrate downward through the backlog like sediment, each quarter adding a new layer of “not yet” above them.
The bottom of the backlog: items that were “great ideas” when a stakeholder proposed them and were added to the backlog to end the conversation. These will never be built. Everyone knows this. The items remain in the backlog because removing them would require telling the stakeholder that their idea will not be built, which is a conversation the PM would rather have never than today.
The backlog grows. The backlog never shrinks. The PM occasionally proposes “backlog grooming” — a session in which old items are reviewed and closed. The session produces arguments, because every item in the backlog has an advocate, and closing the item is a Career-Limiting Move directed at the advocate.
The Roadmap
The roadmap is the PM’s primary communication tool and primary source of suffering.
The roadmap promises dates. Engineering does not commit to dates. The PM presents dates anyway, because the CEO needs dates for the board, the sales team needs dates for the client, and the customer needs dates for their own planning. The PM knows the dates are wrong. The PM presents the dates as “targets” rather than “commitments,” which is a distinction that nobody outside the PM community has ever understood or cared about.
When the dates slip — and the dates always slip — the PM is held accountable. Not the engineering team (who warned that the dates were aggressive). Not the CEO (who needed the dates for the board). Not the sales team (who promised the dates to the client). The PM. Because the PM put the dates on the roadmap, and the roadmap is the PM’s document, and the document is the commitment, regardless of how many times the PM said “these are targets, not commitments.”
The PM learns to pad the dates. The PM adds 30% to every estimate. The engineering team, knowing the PM pads, reduces their estimates by 30%. The PM, knowing the team reduces, adds 50%. The team adds 20%. The dates are now a negotiation between two parties who are each trying to outsmart the other’s buffer, producing timelines that bear no relationship to reality but satisfy the requirement that a timeline exist.
Measured Characteristics
- Roadmap revisions per quarter: 3-5
- Backlog items that will never be built: ~80%
- Backlog items that exist to end a stakeholder conversation: ~30%
- Stakeholders who believe their item is top priority: all of them
- Items that are actually top priority: 3
- Slack messages asking “is this on the roadmap?”: 847 (per week)
- Features promised by sales that don’t exist: 2-4 per quarter
- PM hours spent in meetings: 6 of 8
- PM hours spent thinking about the product: in the shower
- Date padding by PM: 30%
- Estimate reduction by engineering: 30%
- Resulting date accuracy: no better than before
- PMs who have considered going back to engineering: they were never in engineering
- PMs who have considered leaving product management: weekly
- PMs who love the job despite everything: the good ones
