What a product manager actually spends the week doing
On paper, a product manager decides what the team builds and in what order. In practice, the job is a string of trade-offs made without line authority over the people doing the work. Engineers don't report to you, designers don't, and sales certainly doesn't. Everything runs on clarity, persuasion and trust.
Some organisations split the role between a product manager, who looks outwards at users and the market, and a product owner, who works day to day with a delivery team on the backlog. Others use the two names interchangeably. Either way, the same situations keep coming round:
- A big client wants a feature, sales has all but promised it, and you have to say whether it goes on the roadmap, when, and why.
- A round of user interviews shows the problem isn't the one everyone assumed, and the quarter's main project needs to change course.
- Engineering says the planned solution will take three times longer than hoped, and you need a smaller version that keeps what matters.
- Leadership wants a date, the team wants time to pay down technical debt, and support wants the bugs filling its inbox fixed. Everyone's right, and there's only one team.
Good versus great: where the difference really shows
A good product manager ships what was planned. The roadmap holds, tickets are well written, and nobody wonders what to pick up next. That's already a lot.
A great one is judged on something else: what changed for users. Colleagues rarely describe a great PM in terms of releases. They talk about a hard call that got made and stuck, a project stopped before it swallowed another quarter, a meeting where the real problem finally surfaced. The contrast tends to look like this:
- A good PM passes requests on. A great one digs for the problem behind the request, and sometimes comes back with something simpler than what was asked for.
- A good PM says no politely. A great one says no with reasons the disappointed person can repeat word for word to their own line manager.
- A good PM tracks what shipped. A great one checks, a few weeks later, whether behaviour actually changed, and says so plainly when it didn't.
- A good PM writes thorough specs. A great one explains the why so well that the team makes the small decisions on its own.
The skills people see, and the ones they only notice later
Some strengths are obvious from the first meeting: speaking clearly, staying composed in front of senior leaders, summing up a twenty-minute debate in three sentences. They matter, but they're also the easiest to put on for an hour in an interview.
Others only show from inside the team, and they're what a PM's reputation rests on. A CV can say you launched a product; only a colleague can say how.
- Curiosity about other people's work: knowing enough about the technology to ask an engineer the right question, without making their decisions for them.
- Listening to users, including when they say what you'd rather not hear, and the discipline not to lead them with your questions.
- A memory for decisions: knowing why an option was ruled out six months ago, and having written it down where the team can find it.
- An eye for the details users actually run into: an error message, an edge case, a screen nobody designed.
- Honesty about results, especially when the idea that didn't work was your own.
Mistakes even experienced PMs make
Most of these aren't about missing skills. They come from the role's natural pull: under pressure, it's tempting to accept everything, specify everything, or hide in the tools. The PMs people recommend most warmly aren't the ones who've never made these mistakes, but the ones who spotted them in themselves and changed how they work.
- Becoming a ticket desk: logging everyone's requests in the backlog without ever tying them to an outcome. The team ships plenty, and nothing much changes.
- Falling for your own solution, and reading user research as confirmation.
- Writing specs so detailed that engineers and designers have no room left to suggest something better.
- Mistaking a date for a result: celebrating the release, then never looking at what it changed.
- Forgetting the people who weren't in the room: support and sales find out about a change on launch day.
What hiring managers look for in a product manager
Product manager CVs tend to look alike: products launched, teams supported, frameworks named. So the person hiring goes looking for what's hard to write about yourself, and on those points other people's words carry more weight than yours. It's also what a reference check sets out to confirm: our guide to what employers ask your referees shows the questions your contacts are likely to get.
If you've collected recommendations on Take Your Skills, put your profile link on your CV or attach the PDF to your application, so the hiring manager can read what engineers, designers and clients wrote about you, under their own names, before the first interview. From the public ones, Take Your Skills also writes a professional portrait, in English and French, drawing out the skills people mention most and what sets you apart.
Here's what hiring managers are usually looking for:
- Trade-offs told as stories: what was chosen, what was dropped, and why.
- Your relationship with engineering and design, often probed with a question about a disagreement.
- How you measure: which signals you watched, and what you did when they didn't move.
- Whether you can talk about a failure without shifting the blame.
Which personality profiles thrive in this role?
No profile is made for product management, and none is shut out of it. But some natural dispositions help at particular moments in the job. The personality test for work on Take Your Skills describes sixteen profiles, built from around forty everyday work situations. Here are a few whose strengths line up with what the role asks.
The Strategist thinks several moves ahead and gives the team a direction that doesn't buckle under the next crisis. That's exactly what a roadmap needs: not to be rewritten every time a client gets impatient.
The Clarifier cuts through the muddle and spots the flaw in an argument before it proves costly. Faced with vague requests and shaky assumptions, they're the one asking “what makes us think that?” before a line of code gets written.
The Unifier rallies very different people around a shared goal. A product manager has no authority over the people who build the product, so getting engineering, design, sales and support behind one priority is the job itself.
Other profiles succeed in other ways. The Guardian, who looks after people and details alike and notices what everyone else misses, isn't who most people picture running a product. Yet they bring what's often missing: attention to the edge case, the forgotten user, the support colleague who'd otherwise hear about the change last. Every profile can excel in this role in its own way; the test helps you see your natural strengths, and who to lean on for the rest.
Who to ask for a recommendation, and how
The role sits where several teams meet, and your recommendations should show it: one voice, even your line manager's, only tells part of the story. Ask just after a launch or a milestone, while memories are fresh, and name the moment you have in mind, the sign-up redesign, say, so the person knows what to write about. Our guide on how to ask for a reference has messages you can adapt.
On Take Your Skills, the Ask for a recommendation button on your profile gives you a link to send by email or message. Plenty of engineers would rather not write a long text from a blank page, and the writing assistant helps: it asks one question at a time about real situations they shared with you, then suggests a draft they read and edit before publishing. Their answers are never published, and they can always write without it.
Aim for a spread:
- an engineer or engineering lead, on how clearly you framed problems and handled technical constraints;
- a designer, on the room you left for exploration and how you stood up for users;
- someone from sales or customer support, on how you said no without damaging the relationship;
- your line manager or head of product, on your trade-offs and how you kept the bigger picture in view;
- a newer PM you mentored, who can talk about how you pass on what you know.
Eight example references for a product manager
These are written to be adapted. Replace the parts in square brackets, and above all add one detail only the writer would know: that's what makes a recommendation believable.
- From an engineering lead: “On [project], what stood out about [First name] was the quality of the questions before anything got built: why, who for, and what we were agreeing not to do. When the planned solution turned out to be far too heavy, [First name] rang two clients that afternoon and came back the next morning with a smaller version that kept what mattered. I'd recommend [First name] to any team that wants to understand what it's building.”
- From a product designer: “[First name] always gave me time to explore before anything was fixed. On [project], it was [First name] who had the nerve to tell the leadership team that our first idea didn't solve the real problem. The journey we eventually launched was far simpler, and support requests on that topic dropped noticeably.”
- From a sales director: “[First name] told me no more than once, but never without a reason, and always with an alternative I could take back to the client. When [client] pushed for [feature], [First name] got on a call with them to find out what they actually needed, and what we offered kept them happy without pulling the team off its priorities. With [First name], you know exactly what you can promise.”
- From a customer support lead: “With [First name] in charge, support never found out about a change on the day it went live: we had the screens, answers to the questions we'd be asked, and someone to call. [First name] also read our weekly round-up of client issues and turned several of them into fixes that made a real difference to our customers.”
- From a client: “[First name] invited us to take part in research interviews soon after we started using [product]. I've rarely seen anyone listen so carefully without trying to defend their product. Several of our suggestions turned up in later releases, and [First name] told us personally each time.”
- From a head of product: “I gave [First name] our trickiest product, with a long list of stakeholders and expectations pulling in opposite directions. [First name] built a roadmap everyone could follow, proposed retiring [feature] because it cost more than it gave back, and explained that to the teams affected without leaving any bad feeling behind.”
- From a data analyst: “[First name] always asked the awkward question first: how will we know if this works? When the results from [project] were disappointing, [First name] took them to the leadership team exactly as they were, with a plan for what to try next. That honesty earned the whole team's trust.”
- From a PM they mentored: “[First name] taught me the job without ever handing me a ready-made answer. Every trade-off came back to the same question: what are we trying to change for the user? I ran my first launch on my own, with [First name] in the background, and afterwards we went through what hadn't worked. I now do the same for people joining the team.”