Product manager job description template: product stage, decision rights and screening questions
On this page
Product manager postings fail in a specific way: they describe the ideal product manager instead of the job. "Own the vision, delight customers, drive alignment, data-driven, technical, strategic and hands-on" fits every PM role ever written and screens for none of them. What a strong candidate wants to know is narrower: which product, at what stage, with how many engineers, measured on what, and who actually decides the roadmap. Below is a copy-ready product manager job description template, the pay and EEO lines, how each must-have becomes a screening question and scorecard row, and the mistakes that bury the real job. The general method is in how to write a job description that screens.
Name the product type and stage first
| Type | What fills the week | Must-have that separates it |
|---|---|---|
| New product (zero to one) | Customer discovery, prototypes, deciding what not to build | Has taken something from idea to first paying or active users |
| Growth | Funnels, experiments, onboarding and pricing changes | Has run experiments and changed a metric, and can explain why it moved |
| Core or mature product | Roadmap trade-offs, customer escalations, reliability vs features | Has said no to a large customer or stakeholder and held the roadmap |
| Platform or technical | APIs, internal tools, developer experience, data platforms | Has written requirements engineers or developers used directly |
| B2B enterprise | Customer councils, sales requests, compliance and admin features | Has worked with sales on deals without turning the roadmap into a deal list |
Then settle decision rights with the hiring manager. Who sets priorities: the PM, a head of product, or a sales-driven committee? Does the PM own the metric or report on it? How many engineers and designers work with them? A posting that says "you will own the roadmap" when a committee sets it will produce a short, unhappy tenure.
The product manager job description template
[Associate / Senior / Group] Product Manager, [product area]
[Company], [city] — [On-site / Hybrid: days / Remote within: states
or time zones]
Pay: $[min]–$[max] per year, plus [bonus / equity, if any].
[Benefits summary, if required.]
SUMMARY
You will own [product area: e.g. onboarding for small business
customers / the public API / mobile checkout] at [stage: early, growth,
mature]. You will work with [N] engineers, [N] designer(s) and
[analyst / researcher], and report to [title]. You will be measured
on [metric: activation rate / API adoption / retention / revenue from
area].
WHAT YOU WILL DO
- Talk to customers [N times a month] and turn what you learn into
problems worth solving.
- Decide priorities for [area] and explain the trade-offs to
[stakeholders].
- Write [specs / one-pagers / user stories] that engineers and
designers can build from.
- Define success measures before launch and report on them after.
- Work with [sales / support / marketing] on launches and customer
feedback.
- [Senior: set direction across [N] teams and coach other PMs.]
YOU MUST HAVE
- Shipped [features / products] as the person deciding what to
build, in [N or more] release cycles.
- Talked to customers directly and changed a plan because of what
you heard.
- Used data to decide or measure a product change, [writing your own
queries / working with an analyst].
- [Platform: worked through technical trade-offs with engineers on
APIs or systems.]
- [B2B: worked with sales and customers on enterprise requirements.]
NICE TO HAVE
- Experience in [domain: payments, healthcare, logistics].
- Experience with [tools: analytics, experimentation, roadmapping].
If you meet the must-haves and none of these, please apply.
HOW WE HIRE
[Recruiter screen; hiring manager conversation; a product discussion
of a real problem we have [live, 60 minutes]; meetings with engineering
and design partners.]
[EEO STATEMENT]
If you need an adjustment to apply or interview, email [address].
A filled-in summary (invented example)
The example below is invented to show the level of detail, not a real role:
You will own onboarding for our small-business invoicing app, from
sign-up to the first invoice sent. The product is in growth: about
half of new sign-ups never send an invoice, and that is the number
you will move. You will work with four engineers, a designer and a
shared analyst, and report to the Head of Product. You set priorities
for onboarding; pricing changes are decided with Finance.
A candidate reading this knows the problem, the team, the metric and the limits of their authority, which is exactly what they would otherwise spend the first interview asking.
Pay range and EEO statement
Pay. Leave the range bracketed until it is approved on the requisition. Remote PM roles open to several states can trigger several pay transparency laws; see pay transparency laws by state. If equity is part of the offer, say so, and follow the local rules on whether it must be described. For an outside reference, be careful: the management section of the BLS Occupational Outlook Handbook has no profile for product managers (checked October 2026), so a BLS figure for a nearby occupation would be a loose comparison at best. This page does not quote figures; use the approved range and a compensation survey your company trusts.
EEO statement. The EEOC says ads may not show a preference or discourage applicants because of protected characteristics, and gives "recent college graduates" as an example of wording that may discourage applicants over 40 (EEOC). Associate PM programs often use that wording; describe them as for people new to product management instead. Close with your standard EEO statement and an accommodation contact.
From must-haves to screening questions and scorecard rows
Product managers are fluent talkers, so the screen has to pull for specific decisions and their consequences. Ask "what did you decide" more than "how do you think about".
| Must-have | Screening question | Scorecard competency | Evidence of a strong answer |
|---|---|---|---|
| Decided what to build | "What is something you chose not to build that someone senior wanted? What happened?" | Prioritization | Names the trade-off, the evidence and the conversation; owns the outcome |
| Customer contact | "Tell me about a customer conversation that changed your plan." | Customer insight | A specific customer, what they said, and what changed in the product |
| Data to decide or measure | "What metric did your last launch move, and how do you know it was the launch?" | Analytical rigor | Baseline, measure, and an honest view of other causes |
| Working with engineering | "Describe a time engineering said your plan would take too long. What did you do?" | Collaboration and technical judgment | Understood the cost, cut scope sensibly, kept the goal |
| Stage fit | "Which stage of product have you enjoyed most, and what was hard about it?" | Role fit | Honest match to the stage in the posting |
The full first-round screen is in product manager phone screen questions. The interview guide for product managers carries the same competencies into the product discussion and partner interviews, and the 30-60-90 day plan for product managers shows what the hire should achieve in the first quarter.
Common mistakes in product manager job descriptions
"Owns the vision" with no product named
Name the product area, its stage and its users. Candidates choose PM roles by problem, and an unnamed problem attracts people who have not thought about yours.
A unicorn list
"Technical, design-savvy, data-driven, strategic, hands-on, an expert in growth and enterprise" describes a team. Pick the two or three must-haves the product stage really needs.
Decision rights that are not real
If sales commitments or a committee set most of the roadmap, say so. Experienced PMs ask in the interview anyway, and finding out late wastes everyone's time.
Years instead of scope for level
"Seven years of product experience" says little. "Owns a product line with three engineering teams" defines a senior or group role without guessing at tenure.
An unbounded strategy homework
A multi-day "product strategy deck" filters for free time. If you use an exercise, cap it and state the cap in the posting.
Before you publish
- Product area, stage, users and the metric the PM moves are in the summary.
- Team size and the decisions the PM makes alone are stated.
- Must-haves fit the product type; tools and domains are nice-to-haves.
- The interview steps and any exercise length are listed.
- An approved pay range, the EEO statement and an accommodation contact close the posting.
Paste the finished posting into Interview Signal and it builds the screen around these must-haves; the scorecard quotes the decisions and trade-offs the candidate described, so the hiring manager reads evidence rather than adjectives.
Questions people ask
Should a product manager job description require a computer science degree?
Rarely. Product managers come from engineering, design, analytics, sales, support and the domain itself. If the product is technical, such as an API or data platform, require the ability to work through technical trade-offs with engineers and screen for it, rather than using a degree as a stand-in.
What is the difference between a product manager and a project manager posting?
A product manager decides what to build and why, and is judged on outcomes such as adoption or revenue. A project manager plans and delivers an agreed scope on time and budget. If the person will not choose what goes into the product, the role is closer to project or program management and should be titled that way.
How do you level a product manager role in the posting?
By scope and decision rights rather than years. An associate product manager owns features inside a defined area, a product manager owns an area and its roadmap, and a senior or group product manager owns a product line or several teams and makes trade-offs across them. State the team size and what the person decides alone.
Should a PM posting include a take-home exercise?
If you use one, state its length in the posting and keep it short. Many teams get better signal from a live discussion of a real product problem, or from asking candidates to walk through a decision they made, than from a long written strategy document.