You see the problem. The button is in the wrong place, the workflow has a hidden trap, the export feature loses people who need it most. You raise it. The PM nods, says "good point, let me check the roadmap." Six months later, nothing has changed. The next day, you find five new tickets about the same problem.
This is the daily reality for designers, engineers, support leads, and analysts at most product organizations. They see issues the PM does not. They cannot just put them on the roadmap themselves. The skill that closes the gap is influence without authority, and it has surprisingly specific moves. This article distills what works, building on Tanya Donska's Mind the Product piece.
The core mistake non-PMs make
The instinct is to advocate for the problem in your own language. Designers describe UX violations. Engineers describe technical debt. Support leads describe ticket patterns. Analysts describe metric anomalies. All accurate. None of them sound like roadmap problems to a PM who is balancing 30 competing requests in business terms.
The translation that works is moving the problem from your function's language into a business metric the PM is already tracking. Once it lives in their world, it competes for priority on familiar terms.
Move 1: Translate the problem into business metrics
The pattern
Take your observation and express it as a cost or opportunity that maps to something the PM is measured on. The same problem expressed two different ways:
| Your language | PM's language |
|---|---|
| The export button is hard to find | Users spend 4 minutes trying to find export. Times 1,200 weekly users, that is 200 wasted hours per month and roughly 12% of churn risk in the segment |
| The password reset flow is broken | Password reset fails 22% of the time. Each failure generates a support ticket costing 7 minutes of support time. 1,200 tickets per month equals 140 support hours |
| The empty state of the dashboard is confusing | New users who see the empty state churn at 3x the rate of users who reach the populated state in week 1 |
The translation effort is what unlocks the conversation. The PM cannot say no to a number that connects to their goals.
Move 2: Find the metrics they are already watching
Before bringing a problem to a PM, find out what their current priorities are. Three sources:
- Their quarterly OKRs (usually shared internally)
- The metrics they cite in roadmap meetings
- The complaints from their stakeholders they have repeated lately
If they are focused on activation, frame your problem as an activation blocker. If they are focused on retention, frame it as a retention risk. If they are focused on cost-to-serve, frame it as a support cost. The same underlying issue can usually be framed to fit whichever priority is current.
Move 3: Make fixing it cheaper than ignoring it
PMs do mental cost-benefit calculations on every roadmap request. The fastest way to lose is to present a problem without an estimate of the cost to fix. The fastest way to win is to come with a solution scope that looks small.
Adoption hit 68% in three months after the navigation rebuild. That is the kind of evidence that moves roadmaps.
You do not need to know the actual engineering cost. You need to make the case that the cost of not fixing it is larger than any plausible fix. If you can also suggest a small-scope first version ("we could test moving the button without redesigning the page"), the request goes from "another big ask" to "low-cost experiment."
Move 4: Offer the smallest possible fix first
The classic trap of non-PMs advocating for fixes: they describe the ideal solution, which is large. The PM mentally adds it to the multi-quarter list and forgets it.
Reframe as the smallest version that would test whether the fix matters. A button move. A copy change. A simple A/B test. If the small version shows impact, the bigger version becomes easier to justify. Most fixes get on the roadmap as small experiments, not as full features.
Move 5: Know when you have lost and what to do instead
Not every advocacy effort succeeds. Sometimes the priority just is not yours. Three responses that preserve future influence:
- Graceful acceptance. "Got it, makes sense given everything else competing. I will keep collecting data on this; let me know when it might come back up." Burning a relationship to win one fight costs all future fights.
- Document the evidence. Even when the answer is no, log the data you brought. Six months later, when the problem has grown, your prior advocacy with evidence is what makes the second attempt land.
- Find the alternative path. If the roadmap will not move, can you fix it in your function? A designer can ship a small UX improvement in an existing release. An engineer can include a fix in a refactor. The roadmap is not the only channel.
What does not work (and why we keep trying it anyway)
- Repeating the problem louder. If the framing did not land the first time, repetition does not help. Change the frame.
- Going around the PM to their manager. Wins this round, loses every future round.
- Personal frustration in the message. "I keep bringing this up and nothing happens" reads as a relationship problem, not a roadmap problem.
- Citing other companies that solved it. Useful as context, useless as the main argument. PMs care about their product, not benchmark companies.
- Showing the design or technical detail. Save these for the implementation conversation. The advocacy conversation is about the business case.
The compound effect of doing this well
Non-PMs who learn to advocate effectively become the people the PM seeks out for input. The relationship shifts from "someone bringing me problems" to "someone whose problems are worth my attention." Over a year, this means:
- Your insights shape the roadmap consistently, not occasionally
- You get invited into earlier-stage product conversations
- Your career growth accelerates because you are seen as strategic, not just tactical
- The product itself gets better because the floor-level signal reaches the decision layer
The takeaway
You do not need authority to influence the product. You need translation. Take the problem you see, express it in the business language the PM is measured on, find the metric they are already watching, make fixing it look cheaper than ignoring it, propose a small first version, and accept gracefully when the answer is no. Done consistently, this turns ground-floor observation into shipped changes. Without it, the best insights die in conversation while the product accumulates the friction nobody had the framing to fix.
