When I need engineering to prioritise something, I want them to believe it is worth doing, so I am not spending authority on something I am also only guessing at.

Job context

Who

A product manager working with an engineering team they do not manage

When

At every planning session and every mid-cycle change

Trigger

An urgent reprioritisation with no explainable reason

Situation

The team has seen many urgent priorities lead nowhere

Constraints

Does not manage them, and spent trust takes long to rebuild

5 Pains

• Mid-cycle changes waste work already done

  High

  The cost of switching lands on the team, not on whoever switched.

  Root cause: The person changing direction does not bear the cost of changing

• Cannot explain why this matters

  High

  The real reason is sometimes an unsayable request from above.

  Root cause: Information is filtered before reaching the product manager

• Estimates are always wrong

  Medium

  Both sides know it and both must plan with them anyway.

  Root cause: Estimating unprecedented work is a guess

• Technical debt never gets prioritised

  High

  No user asks for it, so it loses to everything.

  Root cause: Priority is decided by external demand while technical debt is an internal need

• Read as the person who only brings more work

  Medium

  The role appears when there are requests and rarely with good news.

  Root cause: Good outcomes belong to the product while requests carry a name

5 Desired Outcomes

• Change priorities with the team understanding why

  Social

• Explain the real reason behind a request

  Social

• Plan despite unreliable estimates

  Functional

• Technical debt has a place on the roadmap

  Functional

• Bring the team good news, not only requests

  Emotional

5 Existing Solutions

A solution is not the same thing as a product — a customer can hire a behaviour or a workaround too.

• Share outcome data with the team

  Behaviour

  The most effective trust-building act, requiring outcome data to exist first.

• Reserve a fixed share of capacity for debt

  Product

  The only way debt gets addressed, and it must be defended every quarter.

• Put the team in front of users

  Behaviour

  Shifts motivation from authority to understanding — most effective and rarely done.

• Borrow authority from above

  Workaround

  Works once, spending precisely what is needed next time.

• Write down the reason for each reprioritisation

  Workaround

  Product managers build the organisation's memory so they are not read as capricious.

2 Opportunity Gaps

• The person changing direction does not bear the cost of the change; it lands on the team mid-work.

  Why existing solutions fail: No system records the cost of a switch, so switching looks free to whoever decides.

  Potential opportunity: Recording the work discarded at each reprioritisation, so it carries a visible number.

• Technical debt is a need no user asks for, so it falls between product priorities and engineering priorities.

  Why existing solutions fail: Roadmaps are built from external demand and capacity is measured in features shipped; neither system has a field for investing in the ability to work later.

  Potential opportunity: Measuring debt by the time it costs each week, so it competes in the same unit as features.