ProductA product manager at a 20–500 person company

When every department has its own request, I want to refuse what is not worth building, so the roadmap does not become the loudest person's wish list.

Khi mỗi phòng ban đều có yêu cầu riêng, tôi muốn từ chối được thứ không đáng làm, để lộ trình sản phẩm không thành danh sách mong muốn của người nói to nhất.

Job context

Who
A product manager with no authority over any requester
When
Every planning cycle
Trigger
A leadership request landing straight on the roadmap
Situation
Every requester has a correct reason for their own part
Constraints
Refusing without data reads as defending one's own preference

5 Pains

  • Every request has a correct reason

    High

    None is wrong, and together they exceed capacity many times over.

    Root cause: Each person optimises the part they are accountable for

  • Requests from above bypass every filter

    High

    They land on the roadmap without competing against anything.

    Root cause: Authority beats process in every organisation

  • No way to compare two unlike requests

    High

    A revenue request and a technical one share no unit.

    Root cause: There is no common scale for value

  • Refusing damages a relationship needed later

    Medium

    The product manager needs those same people's cooperation elsewhere.

    Root cause: Influence without authority runs on relationship capital

  • Refusing without data reads as personal preference

    Medium

    And the data only exists after building.

    Root cause: Evidence of value only exists downstream of the decision

5 Desired Outcomes

  • Have a common scale for comparing requests

    Functional

  • Requests from above go through the same filter

    Social

  • Refuse and keep the relationship

    Social

  • Decide on evidence rather than volume

    Functional

  • Stop feeling every decision must be defended

    Emotional

5 Existing Solutions

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

  • A prioritisation scoring framework

    Product

    Creates a common scale in which every input is estimated by the requester.

  • A roadmap visible to the whole company

    Product

    Makes the trade-off visible, which is the most effective thing here.

  • Refuse by ranking it last

    Workaround

    Refusal without refusing, leaving a backlog nobody ever clears.

  • Ask the requester to define success

    Behaviour

    The cheapest effective filter — most requests withdraw at this step.

  • Escalate the decision

    Behaviour

    Moves the accountability and reduces the standing needed next time.

2 Opportunity Gaps

  • There is no common scale for value, so requests are compared by the volume and authority of whoever raised them.

    Why existing solutions fail: Every scoring framework needs a value estimate supplied by the person who wants it, so the common scale becomes a contest in optimism.

    Potential opportunity: Requiring requesters to state how success will be measured and what counts as failure, instead of stating expected value.

  • The requester gains if right and loses nothing if wrong, while the product manager carries both directions.

    Why existing solutions fail: No process attaches consequence to the requester, so requesting is costless and the volume always exceeds capacity.

    Potential opportunity: Recording the requester's name beside the post-launch result, giving requests a small price.