Product Management

What this area actually covers

Product management is accountability for what a team builds, in what order, and why — then for whether the outcome was worth the quarter it consumed. Three activities make up almost all of it. Discovery is working out which problems are real and worth solving, through user conversations, usage data, support tickets and lost deals. Prioritisation is choosing among more credible options than you have capacity for, and defending the choice to people who wanted a different one. Execution is getting the chosen thing shipped, which mostly means keeping a decision unambiguous while it passes through design, engineering, legal, support and marketing without quietly changing shape.

What surprises people is the medium. The job is conducted almost entirely in writing and conversation: a problem statement, a spec, a metric definition nobody can argue with later, a paragraph in a channel that stops the wrong build. If you dislike writing you will dislike this job, because a PM who cannot make an argument on a page falls back on meetings, and meetings do not scale past one team.

Two things get wrongly bundled in. Project management overlaps but is a different accountability — the PM owns whether the right thing gets built, the delivery manager owns whether the agreed thing lands on the agreed date. And product marketing owns positioning and launch, which in small companies falls to the PM and in large ones certainly does not.

A third, subtler confusion is between product management and requirements gathering. A business analyst collects what stakeholders say they want and renders it precisely; a product manager decides which of those wants will be served, which will be refused, and which are symptoms of a problem nobody has articulated. The two roles produce documents that look similar and involve entirely different accountability. If your organisation calls you a PM and nobody expects you to say no, you are doing the other job.

The seven areas underneath

This section is split along the lines of the interview itself rather than the job, because a PM loop tests the same person through six or seven different lenses and candidates are usually strong in two of them and unprepared for the rest. Each subsection corresponds to a question type you will meet.

Product Sense & Design covers the improve-this-product and design-for-this-user prompts that open most loops. It exists separately because it is the least teachable-looking part of the interview and the most structured underneath: the score comes from whether you narrow to a specific user, derive the proposal from a stated goal, and generate genuinely different options rather than three variants of one idea. Open it for worked chains from goal to segment to need to proposal, and for the ways candidates skip a link and lose the round.

Prioritisation Frameworks deals with RICE, Kano, cost of delay, weighted scoring, and the far more common situation where no framework applies and you must still choose. It is its own area because interviewers use it to test whether you understand that a framework is a way of making an argument legible, not a way of avoiding one. You will find the mechanics of each, their honest failure modes, and scripts for telling a senior stakeholder that their item did not make the cut.

Metrics & Analytics is about choosing a north-star metric that resists gaming, defining guardrails, diagnosing a drop that could have a dozen causes, and doing back-of-envelope estimation out loud without a spreadsheet. It is separate because it is the most mechanically assessable part of the loop and the one where unprepared candidates visibly flounder. Expect diagnostic trees, definitions that survive being argued with, and the distinction between a metric that measures value and one that measures activity.

Discovery & Research covers opportunity solution trees, interview technique, assumption mapping and the discipline of designing a test that could actually disconfirm you. It exists as its own subsection because the failure here is invisible from the outside: a PM who runs twenty user interviews and hears their own hypothesis twenty times has done no discovery at all. The material is about question construction, sampling, and knowing when you have learned enough to stop.

Execution & Trade-offs is the shipping half of the job: cutting scope against a fixed date, deciding launch readiness, working with engineering when the estimate triples, and communicating a slip before it becomes a surprise. It is separated out because it is where a PM's credibility with their own team is made or lost, and because the interview questions are scenario-shaped rather than analytical.

Strategy & Market moves up a level to segmentation, competitive positioning, build-buy-partner decisions, and pricing and packaging. It is its own area because the reasoning is different in kind — you are arguing about where the company should compete, over a horizon of years, with almost no data — and because senior loops weight it heavily while mid-level loops barely touch it.

Product Case Studies works full cases from prompt to recommendation with the evaluation criteria stated up front. It sits last because it is the integration exercise: a case draws on every preceding area at once, and reading one after you understand the parts is far more useful than reading it first.

Where it sits in a real business

A PM sits at the join of three functions answering to different bosses. Engineering can build more than the company can sell or support. Sales knows exactly what the last ten lost deals asked for, and they are not the same ten things. Leadership has a strategy pitched at a level of abstraction that does not tell you what to do on Tuesday. The PM converts these into one ordered list a team can execute, then absorbs the disappointment of everyone who ranked third.

The structural fact is responsibility without authority. You do not manage the engineers, the designers or usually the analysts, so every instruction you give is really a case you have made. Newcomers read this as a defect in their company; it is the design. Authority would let you push through decisions your team thinks are wrong, and a team that thinks the roadmap is wrong builds it slowly and badly anyway.

Following one idea from arrival to judgement makes the shape of the job concrete, and shows where the loops close.

flowchart TD
    A[Signal arrives from a user, a loss or a metric] --> B[Problem statement, one paragraph]
    B --> C{Is the problem real and worth solving}
    C -->|No| D[Killed, and the reason written down]
    C -->|Yes| E[Options generated and one chosen]
    E --> F[Spec, metric and guardrail agreed]
    F --> G[Built, shipped behind a flag]
    G --> H[Measured against the stated metric]
    H --> A

The branch to look at is the one that goes to "killed". In most organisations that arrow is missing in practice, because nothing is ever formally stopped and the backlog becomes a graveyard of half-agreed obligations. A PM who can point to things they deliberately killed, and say why, is describing a functioning process; one whose backlog only grows is describing a queue.

The other detail is that the loop closes back to the signal rather than to the next feature. The measurement step is the one most commonly skipped under delivery pressure, and skipping it is how a team ships continuously for a year without knowing whether any of it worked.

Who does this work

Read responsibilities rather than titles. An associate PM owns a feature area inside someone else's roadmap. A PM owns a product area and a team. A senior PM owns something with a revenue or retention number attached, or a genuinely ambiguous problem space. Group PM and director begin managing PMs, which is a change of profession. Product owner in a Scrum context is narrower on purpose — backlog and sprint scope, often without discovery or strategy.

Technical product manager is worth separating out. A TPM owns products whose users are engineers: platform, APIs, data pipelines, developer tooling, machine-learning systems. Your users can articulate their problems precisely and will read your design doc adversarially, so the credibility bar is different — you cannot bluff an API review. The compensating advantage is that discovery is cheap: your users sit twenty metres away and will tell you the truth unprompted.

Building is absent. Everything you make is an input to somebody else's work, and that is the adjustment engineers and designers moving into the role find hardest. The second adjustment is that your calendar belongs to other people: the block of quiet hours in which you intended to write the strategy document will be consumed by an escalation, and the document will be written on a train.

It is also worth naming who a PM depends on and does not manage. A designer, who will often see the user problem more clearly than you do and whose objections are worth more than a stakeholder's. A tech lead or staff engineer, who is the single most important relationship you have, because their private opinion of your judgement determines how much slack your decisions get. A data analyst, if you are fortunate. And a support or customer success lead, who is sitting on the best unfiltered discovery material in the company and is almost never asked for it.

Demand, adoption and how that is changing

Be honest about this market, because most PM content online describes 2021. The discipline expanded enormously through the 2010s software boom, when the constraint on growth was headcount rather than efficiency. The 2022-2024 cost correction hit PM harder than engineering for a structural reason: PM is overhead against engineering capacity, so cutting teams means fewer roadmap owners, and flattening middle layers makes the PM-to-engineer ratio an obvious place to widen. Entry-level PM contracted sharply — the bootcamp-to-PM route that worked in 2019 largely does not now.

Demand did not collapse, it moved. Technical PM roles held up better than general ones, because platform, data and infrastructure products still need an owner and few people can credibly hold that conversation. Domain-heavy PM held up too: payments, health, insurance, industrial software, anywhere the binding constraint is regulation or a real-world process. AI product roles are genuinely new demand rather than relabelled demand, since probabilistic behaviour needs decisions about evaluation, failure modes and human review that no existing playbook covers.

The AI point deserves a sentence more, because it is the one place where the craft itself is changing rather than the market for it. A feature whose output is correct ninety-two per cent of the time is not a feature in the traditional sense; it is a system whose acceptable error profile has to be designed, whose failures have to be made visible and recoverable, and whose success cannot be measured by a conversion funnel alone. PMs who can specify an evaluation set, argue about the cost of a false positive against a false negative in the specific business context, and design the human review step are scarce, and that scarcity is real rather than hype.

So PM remains in high demand for people who bring a second thing — technical depth, a domain, or shipped outcomes with numbers attached — and is brutally competitive for people whose only asset is wanting to be a PM. That asymmetry has widened, and it is the most useful fact on this page.

What makes it hard

Deciding without sufficient evidence and being answerable anyway. The study never settles it: your data covers the users you already have, your interviews cover the people who agreed to talk, and the deadline arrives before either concludes. The skill is calibrating how much certainty a decision warrants — reversible and cheap means decide now, irreversible and expensive means buy information first — then committing clearly enough that a team can act.

Influence without authority is a real skill rather than a soft one. Getting a staff engineer who thinks your priority is wrong to engage with it, a designer to cut scope they love, a sales leader to accept that their biggest account waits a quarter: each is a separate act of persuasion, and none works from positional power you lack.

Then attribution. Retention rose four points — your onboarding change, the pricing change, seasonal mix, or the enterprise cohort that landed in March? Usually unknowable, so you build judgement from a signal that is confounded and a quarter late. And saying no is most of the job and unpleasant every time, because the requests are not stupid; they are individually reasonable and collectively impossible.

There is a fifth difficulty that only shows up after a year, and it is the one that pushes people out of the discipline. You are permanently accountable for things you do not control, in a role whose contribution is invisible when it goes well. A quarter in which you stopped three bad builds and shipped one good one looks, from the outside, like a quarter in which one thing shipped. Learning to make your own reasoning visible — in writing, before the outcome is known — is both a survival tactic and the thing that separates PMs who get promoted from PMs who get restructured.

Prioritisation without turning it into a religion

Every PM interview will reach a prioritisation question, and the wrong instinct is to name a framework quickly and apply it mechanically. Frameworks are devices for making an argument legible to other people; they do not contain the judgement, they display it. Knowing what each one is good for, and what it quietly assumes, is the actual competence.

The strong answer in an interview names the constraint that makes one of these appropriate rather than reciting the acronym. If the room contains a director who wants an audit trail, a weighted score is the right instrument. If the room contains three engineers and a designer who trust you, a paragraph saying "we are doing A before B because the renewal is in March and B has no deadline" is better than any spreadsheet.

What interviewers listen for underneath all of it is whether you priced the thing you did not do. A candidate who says "we chose A" has made a statement; a candidate who says "we chose A, which cost us the enterprise onboarding work, and we accepted that because the two customers waiting on it had already renewed" has demonstrated the reasoning the whole exercise is trying to elicit.

Metrics, and the words that mean specific things

Numeracy in this job is not statistics; it is precision about what a word means before you attach a target to it. Most metric arguments inside a company are definitional arguments in disguise, and a PM who settles the definition in writing has resolved half of them in advance.

The diagnostic version of this skill is the one interviewers reach for most often: sign-ups fell eleven per cent last week, what do you do. The scoring is almost entirely about whether you decompose before you speculate. Is the drop in the measurement or in reality — did a tag break, did a report change. Is it in one segment, one platform, one region, one traffic source. Is it a change in volume at the top or in conversion partway down. Only after that partition does a hypothesis have any value, and candidates who leap straight to "maybe the competitor launched something" are demonstrating exactly the reflex the question was designed to catch.

Execution, and what a scope conversation really looks like

The execution round is usually a scenario: the date is fixed, the build is late, and something must give. What is being examined is whether you can hold a decision steady while several people with legitimate interests push on it. It is worth seeing the shape of that conversation as a sequence, because the ordering matters more than the words.

sequenceDiagram
    participant E as Tech lead
    participant P as Product manager
    participant D as Designer
    participant S as Sales lead
    E->>P: Integration is two weeks over, date is in ten days
    P->>E: What is the smallest version that still solves the problem
    E-->>P: Manual onboarding step instead of the automated flow
    P->>D: Does the manual step break the promise we made
    D-->>P: Acceptable for the first cohort, not at scale
    P->>S: We ship on the date with a manual step for early accounts
    S-->>P: Two accounts were told it was automated
    P->>S: I will write to both today with the sequence and the date

The interesting move is the second one. A weak PM answers the first message by asking for the date to slip or by asking the team to work harder; a strong one immediately converts a schedule problem into a scope question, because scope is the only variable a PM genuinely controls. The other thing to notice is the last exchange: the cost of the decision lands on named customers, and the PM takes the communication rather than leaving sales to discover it. Interviewers score that instinct heavily, and it is the single most common gap in otherwise analytical candidates.

Why study it

Study it if you like the whole problem rather than your slice — if you find yourself asking why the company is building this at all and the answer matters more to you than the implementation. Study it if you would rather be judged on whether something worked than on whether you built it well. The reasoning is also portable to founding a company, running a business line, and most senior consulting.

Do not study it to escape technical work you have gone off: PM has more meetings, more politics, less control of your calendar and no compiler to tell you when you are wrong. Do not do it for money, since senior engineering matches or exceeds PM at equivalent levels at most large technology companies. And be realistic about entry — the fastest route in is sideways from inside a company that already trusts you, as an engineer, designer, analyst, support lead or sales engineer.

There is a specific reader who should study this page and then stop: the engineer who wants more say in what gets built. That is a real and reasonable want, and changing discipline is an expensive way to get it. Tech lead and staff engineer both carry substantial influence over what a team builds while keeping the part of the work you presumably enjoy, and in a healthy organisation a staff engineer who brings evidence to a roadmap discussion is listened to at least as carefully as the PM is.

If a PM loop is next week, understand what it tests. Very little is recall. You get a product-sense prompt, an analytical or metrics prompt, an execution scenario, a strategy prompt, and a behavioural round on things you shipped. The scoring is the same across all five: do you impose a structure on an unbounded problem, narrow to a specific user, derive the proposal from a stated goal, quantify visibly, name the metric and the risk unprompted, and hold up when the interviewer adds a complication. Structured thinking under ambiguity is the whole examination, which is why a wrong-but-well-reasoned answer routinely outscores a right-but-unreasoned one — the interviewer is predicting your next hundred decisions, not marking this one.

It helps to know roughly what the interviewer's sheet looks like, because it is more mechanical than candidates expect.

PRODUCT SENSE ROUND - SCORING SHEET

  Structure          Did they state an approach before diving in
                     Strong: goal, then segment, then need, then options
                     Weak:   started listing features in minute two

  User specificity   Could I name the person they designed for
                     Strong: "parents booking the Friday evening slot"
                     Weak:   "users who want convenience"

  Option generation  Were the options mechanistically different
                     Strong: a UI change, a notification, a price lever
                     Weak:   three variants of the same screen

  Decision           Did they choose, and give the reason for choosing
                     Strong: chose, priced the rejected option
                     Weak:   "it depends, you could do any of them"

  Measurement        Named a metric and a guardrail unprompted
                     Strong: also said what would disprove them
                     Weak:   named engagement

  Under pressure     Held or updated their answer when I complicated it
                     Strong: incorporated it, said what it changed
                     Weak:   abandoned the whole answer and restarted

Read down the "weak" column and note how many of those are things a competent person says naturally when thinking aloud without preparation. That is the point: the round rewards a habit of structure that has to be practised out loud, not knowledge that can be read.

Your first hour

Take one product you use and write a single page in this shape. Research nothing; the point is to find out whether you can reason.

PRODUCT: a supermarket's click-and-collect slot booking

Goal:        fill van and picker capacity evenly across the week.
Earns from:  basket margin, plus a fee on the most contended slots.
Segment:     parents booking Fri 17:00-19:00, the slot that sells out.
Unmet need:  they would accept another slot but cannot see which nearby
             ones are free without restarting the flow.
Options:     (a) show adjacent-slot availability inline
             (b) waitlist with a push when a slot frees
             (c) 50p off any slot before 15:00
Choice:      (a) - costs no margin and no notification permission, and
             it tests the need before (b) or (c) are worth building.
Metric:      share of sessions that reach a booking.
Guardrail:   average basket value, in case earlier slots buy less.
Disproves me: if abandonment concentrates in sessions where NO slot in
             the week is free, this is a capacity problem, not a UI one.

Now inspect it. If the segment could be anyone, you have not narrowed. If the three options are variants of one mechanism, you have not generated. If the metric would move for a dozen unrelated reasons, it is a vanity metric. And if the last line is blank, you have a preference rather than a hypothesis — that line is the one interviewers reach for and the one candidates most often cannot fill.

When you have one, do it again for a product you dislike, and notice how much harder it is to reason about something when your instinct is that it is simply bad. That difficulty is the job. Most of the products you will work on are ones you would not have chosen, serving users who are not you, and the discipline of reconstructing why a decision was reasonable before proposing to reverse it is the habit that makes a new PM trusted by an existing team.

What this is not

It is not being a mini-CEO. That is the most misleading phrase in the discipline: a CEO can hire, fire, reallocate budget and overrule, while a PM can write, persuade and decide inside a scope somebody else set. Believing the analogy produces a PM who issues directives and cannot understand why the team ignores them.

Nor is it writing tickets. Backlog hygiene is a task inside the job, not the job, and a PM whose week is entirely grooming has a project-coordination role with a product title — worth checking in interviews, since the two are advertised identically. The diagnostic question to ask a prospective employer is simple: when was the last time this team stopped building something because the PM said the evidence had changed. If nobody can remember, the role is delivery coordination.

It is not design, though you will have opinions and should keep most of them quiet for a month. It is not analysis, though you must read a funnel and challenge a dashboard. It is not an escape from technical detail either — the PMs whose engineers respect them are the ones who understand the shape of the system well enough to know which requests are cheap and which are architectural.

And product sense is not a quality you either have or lack. Claiming you have it is unfalsifiable and therefore worthless in an interview; the only version that counts is a reconstructable chain — this goal, so this segment, so this need, so these options, so this choice, and here is the evidence that would have changed my mind. Show the chain and the claim is unnecessary.

Responsibility without authority is not a flaw in your company's org chart, it is the shape of the job: every instruction you give is really a case you have made.