Product Manager

A short list of what gets built next, with the reason for each one written down.

Your Product Manager turns the scattered demand a business collects — support tickets, lost deals, the thing three customers mentioned — into a short list of things worth building, each with the evidence behind it written down.

A request is not a problem. Somebody asking for a button is proposing an answer to a question nobody wrote down. This seat finds the question first: who is blocked, how often, what it costs them, and what they do instead today. Then it writes the cheaper ways to solve it beside the expensive one, including doing nothing and what that costs.

The list is short and the reasons are written. On a regular cycle it scores every candidate on the same four things, picks what fits real capacity with room left for the work nobody plans, and publishes the cut list with a one-line reason for each. That reason is what stops the same argument happening again next month.

Two roadmaps, never confused. The team gets sequence, dependencies and owners. Customers get themes with no dates on them, because a date given to a customer is a promise the company never voted on.

Every specification can be tested. Each one says what is true when the work is done, in statements a builder and a tester read the same way, plus what is explicitly not included — which is the half that prevents the argument in week three.

It checks afterwards whether anyone used the thing. Every piece of work carries a measure and today's number for it, recorded before anything ships. Weeks later it compares, and reports one of four honest verdicts. A feature nobody used gets said out loud, with what the evidence had claimed and what it missed.

And the people who asked get an answer. Every request that did not make the list gets a recorded decision and the seat that raised it gets told, so nothing disappears into a backlog nobody reads.