By Simon Sovič, Senior Product Manager
Hiring your first product manager is one of the highest-stakes decisions you'll make as a founder. Get it wrong and you end up with someone who builds beautiful roadmaps but ships nothing. Get it right and you have a force multiplier who turns messy customer feedback into features people actually pay for. This guide breaks down what to put in your job description, what skills matter most, and how to use the Kano model to test whether a candidate thinks about features the way a great PM should.
Why an Early-Stage PM Role Is Different From Every Other PM Role
Most PM job description templates are written for mid-size or enterprise companies. They list things like "manage a cross-functional team of 12" and "own the product roadmap across three product lines." That is the wrong template for a seed or Series A startup.
At the early stage, you likely have fewer than 20 employees, a product that is still finding its market, and no dedicated UX researcher or data analyst. Your PM is not managing a team. Your PM is the team, at least for product decisions.
This means the traits that predict success are completely different. Enterprise PMs can succeed by being good process managers. Early-stage PMs succeed by being good problem finders and fast experimenters.
Before you write a single bullet in the job description, ask yourself: do I need someone to maintain what we have, or someone to figure out what we should build next? Almost always at the early stage, the answer is the second one.
What to Include in the Job Description (and What to Leave Out)
A good early-stage PM job description is short, specific, and honest about the chaos. Candidates who thrive in this environment are attracted by honesty, not repelled by it.
Here is what to include:
- The problem the company solves- In two sentences, not a paragraph of mission-speak.
- Where the product is today- Be specific. "We have 300 paying customers and a 6% monthly churn rate we need to fix" is more useful than "fast-growing SaaS platform."
- What the PM will own on day one- Not a vague list of responsibilities. A real deliverable, like owning the onboarding flow or cutting time-to-value from 14 days to 7.
- Who they will work with- If they will report directly to the CEO and work with two engineers, say that.
- How decisions get made- Do they have budget authority? Can they kill features? Candidates need to know before they apply.
Here is what to leave out:
- Generic phrases like "strategic thinker" or "excellent communicator" - these signal nothing and waste space.
- Requirements lists longer than eight items - you are not looking for a unicorn, you are looking for the right person for this stage.
- Degree requirements that do not actually predict PM success - many of the best early-stage PMs have non-traditional backgrounds.
For more on how a new PM should operate from day one, the guide on How to onboard as a new product manager at a startup Covers the first 90 days in practical detail.
The Core Skills That Actually Matter at the Early Stage
Every PM job description lists the same skills. Here is how to think about which ones actually matter when your company has fewer than 20 people and limited runway.
| Skill | Why It Matters Early | Red Flag in Interviews |
|---|---|---|
| Customer interviewing | You have no research team. The PM must go talk to users directly, often weekly. | Candidate relies only on survey data or usage analytics to understand users. |
| Prioritization under constraints | You have one or two engineers. Every sprint decision has a real opportunity cost. | Candidate cannot articulate why they would say no to a feature request. |
| Writing clarity | The PM sets context for engineers and founders through written specs. Poor writing slows everything. | Candidate's work samples are vague or jargon-heavy. |
| Comfort with ambiguity | There is no established process. The PM often has to create structure from nothing. | Candidate asks for a defined framework before they can answer a hypothetical. |
| Basic data literacy | The PM needs to read dashboards, spot trends, and ask the right questions of the data. | Candidate cannot interpret a simple retention cohort without help. |
Notice that "roadmap management" and "stakeholder alignment" are not on this list. Those matter later. Right now you need someone who can find the right problem to solve and help a small team ship a solution fast.
How to Use the Kano Model to Evaluate a PM Candidate's Feature Thinking
One of the most revealing things you can do in an interview is give a candidate a real feature prioritization problem and watch how they think. The Kano model is a practical tool for this, and whether or not a candidate knows the model by name, you can see if they reason through features the way the model describes.
The Kano model, developed by professor Noriaki Kano in the 1980s, sorts product features into three main categories based on how users respond to them:
- Basic features (must-haves)- Users do not notice these when they work. They are furious when they do not work. Think: a login page that loads in under two seconds.
- Performance features (more is better)- User satisfaction scales directly with how well these work. Think: faster search results, cheaper pricing, more storage.
- Delight features (unexpected positives)- Users do not know they want these until they have them. When a feature lands in this category, it generates word-of-mouth and emotional loyalty. Think: Spotify Wrapped, or a SaaS tool that auto-suggests the next action based on what you just did.
In an interview, try this: describe a real feature request your company has received and ask the candidate to categorize it using whatever framework they prefer. A strong PM will instinctively ask: "What happens if we do not build this? Will users churn, or will they just be less happy?" That is Kano thinking, even if they never say the word Kano.
A weak PM will jump straight to building. They will not ask what problem the feature solves or whether it serves basic, performance, or delight needs.
For a deeper look at how to apply this kind of thinking to real product decisions, the article on How to build a minimum lovable product Walks through how to identify which features create emotional resonance versus which ones just clear a baseline bar.
From experience, candidates who can correctly identify a "must-have" feature they would deprioritize in favor of a delight feature - because the must-have is already good enough - are the ones who ship products people talk about.
Structuring the Interview Process for an Early-Stage PM Role
You do not need a six-round interview process. You need a process that surfaces the skills that matter and respects the candidate's time. Here is a three-step structure that works for most early-stage startups.
- Screening call (30 minutes)- Founder or hiring manager. Goal: understand their motivation for joining an early-stage company and get a feel for how they communicate. Ask them to describe a feature they killed and why. If they cannot name one, that tells you something.
- Work sample (2-3 hours maximum)- Give a real problem from your product. Ask for a one-page brief: what problem this solves, who it is for, how they would measure success, and what they would not build. Keep the brief format loose. How they structure their thinking matters more than the format.
- Deep-dive conversation (60 minutes)- Walk through the work sample together. Push back on their assumptions. Ask: "What if your biggest assumption here is wrong? What does that change?" Strong candidates get more interesting when challenged. Weak candidates get defensive or cave immediately.
Pay attention to how they talk about users during the entire process. Do they say "users want X" based on intuition, or do they say "in our last round of interviews, three out of five users mentioned Y?" The latter is the mindset you are hiring for.
Setting up a system to continuously capture that kind of user signal is something every PM should do early. The guide on How to set up a product feedback loop from scratch Is a practical starting point for that conversation during interviews too.
FAQ
What is the difference between a product manager and a product owner at an early-stage startup?
In large companies, a product owner typically works within an agile team and writes user stories, while a product manager owns strategy and roadmap. At an early-stage startup, this distinction rarely matters. You usually need one person who does both: sets the direction and rolls up their sleeves to write the specs. If a candidate insists on a strict separation of these roles, that is a sign they are used to enterprise environments.
Should an early-stage startup hire a junior or senior PM?
This depends on how much guidance the founder can provide. A senior PM with early-stage experience can operate independently from week one. A junior PM may have more raw instinct and hunger but will need more coaching on prioritization and stakeholder communication. If you as a founder have strong product intuition and time to mentor, a sharp junior hire can work well. If you are heads-down building or selling, you need someone senior enough to self-direct.
How do you write a PM job description that attracts the right candidates?
Be specific about where the product is today, what success looks like in the first 90 days, and how decisions get made. Avoid generic phrases. State the real constraints: small team, limited resources, high ambiguity. The right candidate sees those as a reason to apply, not a reason to pass. The wrong candidate filters themselves out, which saves everyone time.
What does the Kano model have to do with hiring a PM?
The Kano model is a useful lens for evaluating how a PM candidate thinks about features. A candidate who naturally distinguishes between must-have features, performance features, and delight features has a more mature mental model than someone who treats all feature requests equally. You can surface this thinking with a simple interview prompt: give them a real feature request and ask them to reason through whether it should be built, and why.
How soon should an early-stage startup hire a PM?
Most founders should wait until they have at least one clear paying customer segment and a product that has been used by real people. Before that point, the founder is usually the right person to own product decisions because they are closest to the problem. Hiring a PM too early - before there is enough signal from the market - means the PM has nothing concrete to work with and risks building in the wrong direction.
This page was made by SuperDuperSEO →