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 does. 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.