Prioritisation that survives the meeting
Every team has far more requests than people. This lesson gives you a request intake that collects the same facts for every ask, scoring models to rank them (RICE, ICE, cost of delay, Kano and MoSCoW), and the traps that make a score lie, so your ranking holds up when a department head pushes back.
By the end you can
- Run a request intake that turns chat messages and hallway asks into comparable requests with evidence
- Score a backlog with RICE, with Impact anchored to time and errors saved for internal tools
- Use cost of delay to decide order when timing matters
- Use Kano and MoSCoW for the jobs they are good at, and avoid their traps
- Say where a score misleads you, and turn a request down with a reason
The everyday picture
Think of the triage nurse at a busy clinic. Patients are not seen in the order they arrived, and not in order of who complains loudest. The nurse asks everyone the same few questions (what is wrong, since when, how bad), writes the answers down, and gives each patient an urgency level. A child with a high fever goes before a sprained wrist that arrived an hour earlier.
Two more things make triage work. The nurse checks again on people who are waiting, because some get worse the longer they wait. And the scoring sheet doesn't replace judgement: an experienced nurse can move someone up when something looks wrong, and writes down why. Product prioritisation is the same job: one front door, the same questions for everyone, a score to start the conversation, attention to what gets worse with waiting, and written reasons for every override.
One front door for requests
Before you can rank requests, you need them in one place and in one shape. In most companies they arrive everywhere: a chat group message at 11 pm, an email to your manager, a comment at the end of a meeting, a phone call from a store. Most arrive as solutions ("add a photo button") with no facts attached. You can't compare a chat message with an email thread.
A request intake fixes this. It has three parts:
- One form, short enough that people fill it in. Ask for the problem rather than the feature, who has it, how often, how many people, today's workaround and what it costs, any evidence, a deadline and why, and what happens if nothing is done. The questions are the same ones you used to find the problem behind a request in Problems before solutions.
- A weekly triage, 30 minutes with the PM, an engineer and a designer. Each request is checked against the strategy first, then sent back for missing facts, scored, parked with a review date, or declined.
- A promised reply. Every requester hears back within an agreed time, say five working days, including when the answer is no. People stop going around the process when the process answers them.
For internal tools this matters even more, because the requesters are department heads with real power, and the users can't leave. You will go deeper into saying no to department heads in Product management for internal tools.
Quick check
The head of HR messages you "we need shift swaps in the Store app ASAP". What should happen first?
Without facts, any score is your guess dressed up as a number, and any decision is a reaction to who asked. The form gets the same facts you get for every other request. Declining before you understand the problem is as hasty as accepting it.