Product management fundamentals

You own the problem, its priority and the definition of success; you do not own the solution, the design or the estimate. That split is the whole job. Owning the problem means you are accountable for whether the thing built was worth building, which is why "engineering delivered what I asked for and nobody used it" is your failure and not theirs. Not owning the solution means the design and the architecture belong to the people whose craft that is, and a PM who arrives with wireframes and a schema has spent their leverage on the part of the work someone else does better. The authority question follows from this: you rarely have formal power over anyone, so the decisions you make stick only to the extent that the reasoning behind them is visible and holds up when argued with.

A product manager decides what to build and why; a project manager decides how the agreed work gets coordinated and lands on time; a product owner is a role defined inside Scrum, accountable for the backlog and its ordering. The distinction that matters in an interview is scope of question. A project manager optimises delivery of a decision already taken, so their failure mode is a perfectly run project that shipped the wrong thing. A product owner as Scrum defines it is a subset of product management — backlog, acceptance, sprint-level trade-offs — with no necessary claim on strategy, pricing or market. Many organisations use "product owner" as a job title for a backlog administrator with no discovery mandate, and if you are interviewing for one it is worth asking directly which version they mean, because the two jobs are not the same career.

An output is a thing you shipped; an outcome is a change in behaviour that followed. "We launched the referral programme" is an output, "invited-user signups went from four to eleven per cent of new accounts" is an outcome. The distinction is not vocabulary policing — it changes what you commit to. A team committed to outputs is done when the feature is live and has no reason to look at it again, whereas a team committed to an outcome has to keep working until the number moves or has to conclude, publicly, that the approach was wrong. That second option is the expensive one and the reason most roadmaps are lists of outputs. The honest caveat to give an interviewer is that some work genuinely has no measurable outcome in a quarter — a compliance deadline, a platform migration — and pretending otherwise produces invented metrics.

Every feature carries four independent risks, and the point of naming them separately is that each is tested by a different activity.

Feature: in-app invoice scanning. Photograph an invoice, get a draft
expense record with supplier, date and amount pre-filled.

risk         the question              how it fails             cheapest test
-----------  -----------------------  -----------------------  ------------------
VALUE        will they choose it       they keep keying by      6 interviews about
             over what they do now     hand because the photo   last month's actual
                                       step feels slower        entry, not the idea

                                                                fake-door: put the
                                                                button in, count
                                                                taps, no feature
                                                                behind it

USABILITY    can they succeed at it    OCR returns a wrong      5-person prototype
             unaided                   amount and the user      test with their own
                                       does not notice, so      real invoices, not
                                       the fix is invisible     clean samples

FEASIBILITY  can we build it with      accuracy on crumpled     2-day spike: run 200
             what we have, in the      phone photos of thermal  real invoices through
             time we have              receipts is 60%, not     the candidate vendor
                                       the 95% on the demo      and score by field

VIABILITY    does it work for the      OCR cost per account     unit-economics sheet
             business - legal,         exceeds the margin on    plus one call each
             margin, support, sales    the tier that wants it;  with support, legal
                                       support cannot triage    and finance
                                       a wrong amount

Verdict here: feasibility and viability are the binding risks, not value.
Test those first, in that order, before any design work.

The reason to separate them is that teams reliably test the wrong one. Value gets tested obsessively because interviews and surveys are cheap and pleasant, while feasibility is deferred to the sprint where it becomes a problem, and viability is often not tested at all until support and finance object after launch.

The ordering rule is to attack the risk that would kill the feature soonest and costs least to resolve. Here the vendor accuracy spike takes two days and can end the project, so doing it before a single screen is designed saves the design work rather than validating it. A team that runs the interviews first learns that people want this — which everyone already believed — and learns nothing about whether it can exist.

Usability is the one candidates collapse into value. They are different: people can want a thing and still fail to use it, and the failure mode here is particularly nasty because a wrong amount that looks confident is worse than an empty field. That specific failure is what a prototype test with real, messy invoices surfaces and a clean demo hides.

Viability is the risk PMs are uniquely responsible for, because nobody else in the room is accountable for margin, legal exposure or the support load. Naming it unprompted is one of the fastest ways to sound like a PM rather than a requirements author.

Whoever owns the axis being disagreed about, and most of these disputes go away once that is said out loud. If the disagreement is about whether the problem is worth solving now, it is yours. If it is about how the solution is built, the sequencing of technical work, or what the estimate is, it is theirs. The genuinely contested cases are trade-offs across the boundary — six weeks of hardening against two features, or a shortcut that ships in April and costs a year — and those resolve by making the cost explicit in the other's currency rather than by seniority. If it still deadlocks, escalate with a written recommendation and both positions, and accept the answer visibly. A PM who wins by escalation habitually finds that estimates start arriving padded.

You owe them a prioritised problem rather than a specification, the reasoning behind the priority so they can make a hundred small decisions without asking, a decision when they need one instead of a deferral, and enough stability that the plan is not re-cut weekly. They owe you honest forecasts with the uncertainty attached, early warning of a slip rather than a heroic recovery, options with costs instead of a flat refusal, and the technical constraints translated into consequences you can weigh. Both failure modes are recognisable. A PM who specifies solutions removes the judgement they hired engineers for and gets compliance instead of ideas. An engineering lead who hides risk until it is unrecoverable removes your ability to manage the expectations you set on their behalf.

Because it describes authority you do not have and omits the skill the job actually requires. A chief executive can hire, fire, allocate budget and overrule; a PM typically controls none of those and gets outcomes by assembling evidence, framing trade-offs and persuading people who do not report to them. The phrase also sets a bad posture for new PMs, who read it as licence to direct and then find that engineers and designers route around them. The more accurate framing is that you are accountable for the outcome and responsible for the decision quality, with influence as the only instrument — which is why the standard interview probe is a time you changed a decision without authority, and why "I escalated" is a weak answer to it.