The title said Product Manager. Leadership said: roadmap's done, ship it.
You do the job. Someone else runs the product.
The comic that went with this post tells the story in four panels. A PM announces they decide what features to add. The CPO laughs, with revenue, the board deck and the Q4 target on the screen behind him. Then the CEO joins in, and the PM costume gets crushed. It is funny because a lot of product managers have lived some version of it.
The useful question is not whether it is unfair. It is whether your organisation will ever let you make product decisions, and how to find out without waiting years. These are the five tests I coach PMs to run. Each one wins back a decision, or tells you the truth.
Tests that put evidence on the table
Put a better decision on the table. Back it with evidence and the risks you already mapped. Then watch: does a good argument change the plan, or just get noted? An organisation that listens will engage with the substance. One that does not will thank you and carry on.
Run a small experiment on an easy-to-prove roadmap item. No permission needed. Pick something where the result will be clear and fast. Then see if the result moves the roadmap, or just gets filed. A filed result tells you evidence is welcome as decoration, not as input.
Turn user interviews and behaviour into evidence leadership can't wave away. Not a slide of quotes, but a clear line from what users said and did to what that means for the plan. Then see if the evidence gets acted on, or only admired.
These three tests have the same shape. You bring something a decision maker should want: a better option, a proven result, evidence from users. How the organisation responds tells you whether product decisions are open to argument or already fixed above you.
A test of ownership
Ask to own one outcome, not one more task. One KPI, yours end to end.
This is the most direct test. Plenty of organisations will happily give a PM more tasks. Fewer will give a PM a result to own. See if the yes comes with budget and authority, or just a nod. A nod means you own the work and someone else still owns the call.
A test of the network around you
Build allies in engineering, design and sales before you need them.
Then see if the allies you built change what gets approved. Product decisions are rarely made by one person, even in top-down organisations. If a proposal backed by engineering, design and sales still goes nowhere, the decision was never in the room you were invited to. For more on building that support, Influence Without Authority at /vault/how-to-influence-without-authority covers the moves in detail.
What the five tests tell you
Run all five and the org answers you.
Either you win back your role as a product manager: decisions, autonomy, and all. Or you find out the organisation never planned to give you any of it, and you find one that will.
Both outcomes are better than staying in the middle, guessing. It is easy to spend years waiting for the role to open up on its own, reading every small sign of trust as a promise. The tests shorten that wait. They ask the organisation a clear question through action, and they make its answer hard to misread. The tests turn a vague frustration into evidence you can act on, about the role as much as about the product.
If you can't influence what gets built, you don't own the product. You own the delivery.