Product management is deciding what a team builds and why, and being accountable for the outcome without owning the people who build it. The job splits three ways — discovery, prioritisation, execution — and most of it is writing and persuasion.
High demand21 min readProduct Manager, Senior Product Manager, Technical Product Manager, Group Product Manager, Product Owner, Director of ProductUpdated 2026-07-27
Assumes you know: Enough numeracy to reason about a funnel and a unit economic without a spreadsheet, Comfort writing to persuade, since most of your output is documents
Overview
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.
Now practise it
22 interview questions in Product Management, each with the rubric the interviewer is scoring against.
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.
Subsection
What it is for
Product Sense & Design
Reasoning from a user problem to a proposal
Prioritisation Frameworks
Choosing, and defending the choice to the loser
Metrics & Analytics
Naming, moving and diagnosing a number
Discovery & Research
Finding out whether the problem is real
Execution & Trade-offs
Getting it shipped when something has to give
Strategy & Market
Where the company should play, and at what price
Product Case Studies
Full cases, worked end to end
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.
Loading diagram…
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.
Where the week goes
Roughly
What it looks like
Discovery
4-6 hours
User calls, session recordings, support tickets, a sales-loss debrief
Writing
5-8 hours
Specs, metric definitions, the document that ends an argument
Team-facing
4-6 hours
Refinement, design review, unblocking an ambiguity mid-sprint
Alignment
3-5 hours
Leadership review, a sales escalation, saying no so it survives
Data
2-4 hours
Whether last month's launch did anything, and whether the dashboard lies
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.
Method
What it is good for
What it quietly assumes
RICE
Comparing many small, similar items with a shared goal
That reach and impact are independently estimable, which they usually are not
Weighted scoring
Making a multi-criteria decision defensible to a committee
That the weights were chosen before the options, rather than reverse-engineered
Kano
Distinguishing basic expectations from delight in a feature set
That the survey population represents the segment you are serving
Cost of delay
Anything time-sensitive - a regulatory date, a seasonal window
That you can estimate the value of shipping a month earlier, which needs a real model
Opportunity cost, stated plainly
Small teams, high-trust rooms, senior audiences
Nothing much, which is why it is often the honest choice
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.
Term
What it means
Where it goes wrong
North-star metric
The single number that best proxies delivered value
Chosen to be easy to move rather than hard to fake
Guardrail metric
A number that must not get worse while you move the north star
Omitted, so a conversion win is paid for by a support-cost loss
Leading indicator
A signal that moves before the outcome does
Treated as the outcome, because it reports faster
Activation
The point at which a new user has received the core value
Defined as an event that is convenient to log
Retention
The share of a cohort still active after a period
Ambiguous until you fix the cohort, the window and "active"
Vanity metric
A number that rises regardless of whether you helped
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.
Loading diagram…
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.