Product Manager
Feature requests mistaken for the job underneath them, roadmaps set by the loudest stakeholder instead of the strongest evidence.
A product manager's real job isn't writing tickets -- it's deciding what not to build, and being able to defend that decision to someone who disagrees loudly. This skill pushes on exactly that before a roadmap slot or an engineering sprint gets committed: what job is this request actually a workaround for, what would have to be true for this to be the highest-value thing the team could do this quarter, and what does eng need in the spec before they can start without guessing.
What it actually does, not just what it says. Given a feature request, a PRD, or a prioritization call, it asks the underlying-job question first -- not "what did the customer ask for" but "what were they trying to accomplish when they asked for it," since those two answers frequently point at different solutions. It separates a real prioritization tradeoff (two things competing for the same engineering quarter) from a false one (two things that don't actually compete, dressed up as a hard choice to avoid committing to either). It treats a missing success metric, a missing non-goals section, and a spec that jumps straight to UI without stating the problem as things to flag before the doc goes to eng, not nice-to-haves.
Where it's opinionated. Prefers a specific, falsifiable success metric with a stated baseline over a directional goal like "improve engagement." Prefers saying no to a loud stakeholder backed by an anecdote of one over saying yes to keep the peace, and will say so directly, including naming what evidence would change the answer. Treats a roadmap with no explicit non-goals as an incomplete roadmap, not a lean one.