Presentation Tips for Product Development Managers
By Daniel Harper · Career & Business
How should a product manager present a roadmap? By outcome and time horizon, not as a list of features with dates. When a request is not on it, explain the criteria you used before the decision itself: people accept an unwelcome decision far better when the process behind it is fair and visible. Then give the person asking a way back in.
A product development manager presents to more audiences than almost anyone: executives at quarterly planning, engineering at kickoff, sales before a launch, customers at a user group, and every week to a colleague who wants their feature on the roadmap. The common thread is that most of these presentations involve saying no to someone, and how you say it decides whether they keep working with you.
Present the roadmap by outcome, not by feature
A roadmap that lists features with dates is read as a set of promises, and every date that slips becomes a broken one. A roadmap organised by outcome and time horizon is read as a plan:
- Now: what the team is building this quarter, and the outcome it is for. High confidence.
- Next: what comes after, by problem rather than by feature. Medium confidence.
- Later: the problems you intend to tackle. Low confidence, and labelled as such.
Say the confidence out loud as well as showing it. "Next quarter is our best current view, and it will change" saves you an argument three months from now.
Saying no in the room
The hardest moment in most product presentations is the one where a stakeholder asks why their request is not there. The instinct is to give the decision and move on quickly. The research suggests the opposite order.
Joel Brockner and Batia Wiesenfeld reviewed 45 independent samples on how people react to decisions that affect them. Across them, the fairness of the process mattered more to people's reactions precisely when the outcome was unfavourable to them.1 When people get what they want, they care less how the decision was made. When they do not, the process is most of what they have to go on.
So when you say no, show the process first:
- The criteria. What every request was judged on: customer impact, number of customers affected, effort, fit with this year's strategy.
- How their request scored, beside the things that made the cut.
- The decision.
- What would change it. New evidence, a larger customer need, a change in strategy. This is their way back in, and it turns a closed door into an open question.
"We weighed every request on impact, reach and effort. The export feature scored well on impact but reaches about forty customers, and the onboarding work reaches all of them. If we see the export requests from enterprise accounts grow, it moves up, and I'd like your help tracking that."
Show the scoring, not just the result
A simple table of five or six candidates with their scores does more for trust than any explanation. It shows that the request was considered, that the same rules applied to everyone, and that the decision was not personal. If the table makes your own priorities look arbitrary, that is worth knowing before the meeting rather than during it.
Launch go/no-go meetings
A go/no-go decision should be made against criteria agreed before the meeting, not argued from scratch in it. Present each criterion with its status (met, at risk, not met), give your recommendation first, and name what would have to be true to launch if you are recommending against it. A launch decision made on gut feel in a room full of tired people is how products ship with known problems.
When the date question comes up
Roadmap reviews always reach "when?". Answer with a range and the condition it depends on, not a single date. Presentation tips for software development managers covers how to present a date you are not sure of, and it applies to product timelines as much as to engineering ones.
Bring one customer into the room
The strongest argument for a roadmap choice is usually one real customer: what they were trying to do, where they got stuck, and what it cost them. Put it next to the number that shows how common the problem is. A story alone is an anecdote; a number alone is easy to ignore. Together they explain why this, and why now.
If a stakeholder pushes back hard on a decision, objection handling covers how to grant what is true in their objection and still hold your position.
References
- Brockner, J., & Wiesenfeld, B. M. (1996). An integrative framework for explaining reactions to decisions: interactive effects of outcomes and procedures. Psychological Bulletin, 120(2), 189–208. https://doi.org/10.1037/0033-2909.120.2.189