Product Manager

A title with no agreed definition

There is no shared understanding of what a Product Manager does. At one company it is a role that runs discovery, decides what gets built, and answers for whether it worked. At another it is a delivery function that writes tickets from a roadmap set elsewhere. At a third it is closer to a project manager with a product vocabulary.

None of these is fake, and people move between them without noticing until an interview goes badly. A candidate describing strategy work to a company that wants execution sounds unmoored. A candidate describing sprint ceremonies to a company that wants discovery sounds junior.

Everything else here follows from working out which version you have done and which version is being advertised.

The question every interview is really asking

Whatever form the questions take, product interviews are trying to answer one thing: what have you actually decided, and how did you decide it.

This is where most candidates lose. They describe what shipped. The feature, the launch, the metric that moved. Shipping is evidence that a team functioned, not that you exercised judgment.

The material that lands is a decision with a real alternative. Something you chose not to build and why. A time you killed something after launch. A moment you disagreed with a stakeholder who outranked you, and what happened.

Write down three of these before you interview anywhere. For each: what you knew at the time, what you decided, what you were wrong about, and what you would need to know to decide faster next time. That preparation is worth more than any framework.

Read the posting for who owns the roadmap

The single most useful thing to establish before applying is whether this role decides what gets built or receives that decision from someone else.

The tells are usually there. A posting that talks about gathering requirements, writing specifications, and working with stakeholders to deliver is describing execution. One that talks about defining the strategy, owning outcomes, and being accountable for a metric is describing something closer to ownership.

Reporting line settles it. A PM reporting to a Head of Product at a company with several product teams usually has real scope. A PM reporting to an engineering manager, a founder who has strong product opinions, or a sales leader usually has less than the posting implies.

Neither is disqualifying. Execution roles at good companies are excellent training. But knowing which one it is stops you preparing the wrong stories and stops you accepting a job that will frustrate you within a quarter.

Working with a founder who owns the product

At smaller companies the founder often is the product manager, whatever your title says, and the job is different enough to be worth naming.

The work becomes translation and structure rather than direction. The founder has strong instincts and usually good ones, since they built the thing. What is missing is the discipline: talking to customers who are not the loudest, closing out decisions so the team can move, and saying what will not be built this quarter.

Candidates get this wrong in interviews by presenting themselves as the person who will bring strategy. To a founder that sounds like a bid for their job, and the conversation cools.

The framing that works is to say what you would take off their plate. Running discovery so their instincts get tested cheaply. Owning the backlog so engineering is not blocked waiting for their attention. Handling the stakeholder management that is eating their week.

Ask how decisions get made today and what happens when the founder disagrees with the team. The answer tells you whether the role has room in it or whether you would be writing tickets for someone else's roadmap under a title that says otherwise.

Metrics, and the trap of claiming them

Product Managers face the same shared-credit problem marketers do, made worse by the fact that engineers built the thing.

"Increased retention by 15%" invites the obvious question of what you personally contributed, and a weak answer to that question undoes the claim.

The way through is to be specific about your part. What you discovered that nobody else had, which option you argued for, what you cut to make it ship, what you measured to know whether it worked. The claim then rests on judgment, which is what you are being hired for, rather than on an outcome that many people produced.

Where a metric did not move, say so. A PM who has shipped something that failed, understood why, and changed their approach is more credible than one with an unbroken record, because everyone in the room knows the unbroken record does not exist.

Technical enough, and what that actually means

Postings ask for technical PMs, and candidates either overclaim or apologise. Both are avoidable.

What engineering teams want is a PM who can hold a conversation about trade-offs without needing everything translated, who does not promise things that are architecturally impossible, and who understands why the estimate is three weeks rather than three days.

That is a much lower bar than writing code, and a much higher bar than knowing the vocabulary. You can meet it by being able to describe how your product works end to end: where data comes from, what happens when a user clicks, what breaks under load.

If you do have an engineering background, be careful with it. PMs who relitigate implementation decisions are a known failure mode, and interviewers screen for it. Mentioning that you know when to stay out of it will do you more good than the background itself.

The product sense interview

Somewhere you will be asked to improve a product, design something for a user group, or say which metric you would watch.

The common failure is jumping to solutions. A candidate who hears "improve our onboarding" and immediately proposes three features has skipped the part the interviewer is assessing.

The structure that works: who is this for and which segment specifically, what problem do they have that you believe is real, why has it not been solved already, what would you build first, and how would you know within a month whether you were wrong. That last part separates senior candidates from everyone else. Most people design something. Fewer say how they would find out it was a mistake.

Ask clarifying questions before starting, and pick a narrow user segment on purpose. Candidates who try to serve everyone produce answers with no edges.

Coming into product from somewhere else

Most Product Managers arrive from another function, usually engineering, design, analytics, support or sales. Each brings something and lacks something, and interviewers know the pattern.

Engineers arrive credible with the team and are screened for whether they can talk to customers and hold ambiguity. Designers arrive strong on users and are screened for commercial judgment. Analysts arrive strong on measurement and are screened for whether they can decide without complete data. Support and sales people arrive knowing customers better than anyone and are screened for structure.

Name your gap before they find it, and say what you have done about it. A former engineer who has run twenty customer interviews has answered the objection in advance. One who has not will spend the interview being probed on it.

Apply into the domain you already know. An analyst in insurance moving to product in insurance is a far easier hire than the same person moving to consumer social.

Scope, not title, sets the band

We do not print salary numbers, because a figure from Seattle means nothing in Toronto, Mumbai or Nairobi.

What holds across markets is that product compensation tracks scope, and scope is measurable in ways title is not. How many engineers work on what you own. Whether you are accountable for a business metric or a delivery date. Whether anyone reports to you. Whether the thing you own makes money directly.

The moves that reprice you: from an execution role to one that owns outcomes, from an internal tool to a revenue-generating product, and from a local company to a multinational in the same city. A promotion from Product Manager to Senior Product Manager inside the same company usually moves you within your existing band rather than to a new one.

For what the role pays where you live, our salary calculator takes your city and your years of experience.

Start here

Write your three decisions. Not launches, decisions, each with the option you rejected. If you cannot fill three, that is the honest signal about which version of this job you have been doing, and it tells you what to go and get.

Our job search builder searches every board you trust at once, and the ATS scanner shows what a filter sees first.