Questions to Ask a Product Manager
For a student, career changer or aspiring PM who has an informational interview or coffee chat with a working product manager. The questions follow the conversation: how they got into product, what the week holds, how they decide what to build and how it is measured, working with engineering, design and sales, getting a first PM job without the title, and how to close. The notes say what a PM's specific answer sounds like next to a polished one, and where the answer depends on the employer they tell you to ask how it works there.
Want questions from the whole vault instead? Try the random question generator.
The questions
Each question, and why to ask it
Their path
How did you get into product management, and what were you doing right before your first PM job?
Why ask it
Many PMs came across from another seat, so the job they held just before is the part to study: engineer, analyst, support lead, consultant, designer. Listen for whether they moved inside a company that already trusted them or were hired into the title from outside. The two routes ask for different things, and one of them is probably closer to where you are standing.
What did you think a product manager did before you became one, and what turned out to be different?
Why ask it
Their old picture of the job is likely close to yours now, which makes the correction worth hearing. Common ones are less deciding and more persuading, or less invention and more follow-through. If nothing surprised them, ask what surprises the new PMs they have worked beside.
What made you want to move into product instead of staying where you were?
Why ask it
Someone who wanted to be nearer the customer or the decision describes a different job from someone who wanted out of writing code or out of client work. Notice which of the two sounds like you. The second half of the story is the useful one: whether product gave them what they left for.
Which part of your earlier work do you still lean on as a PM?
Why ask it
A former engineer may say estimating, a former support agent may say knowing what customers really complain about. You learn what a background is worth after the title arrives, not only on the way in. Where your history turns out nearer to theirs than you expected, say so, and find out how they described it when they applied.
What was the hardest thing to learn in your first year in the job?
Why ask it
A specific answer, such as writing a spec engineers could build from or telling a senior person no, gives you something to practice before you have the title. 'Everything' is honest but hard to act on, so narrow it to the lesson that cost them the most.
What kind of product do you work on, and would you choose the same kind again?
Why ask it
Consumer apps, software sold to businesses, internal tools, hardware and platforms for other developers are different jobs under one title. What they would change, slow sales cycles or too little contact with users, points you at which kind to aim for first. It is worth asking early, because it colors everything they say later about their week.
How is the PM job at your company different from the other places you have seen it done?
Why ask it
The title stretches from writing tickets for one team to running a business line, and it can differ between two teams in the same building. Their comparison keeps you from treating one employer as the whole profession. A PM who has only worked in one place can still pass on what friends in the job elsewhere describe.
Where do PMs tend to go from here: managing other PMs, starting something, or moving to another function?
Why ask it
You are asking what the job leads to before you spend years getting into it. Notice which of those they want for themselves and whether they sound pleased about it. A PM who misses hands-on work after moving up is describing a trade you would face too.
The week
What does a typical week look like for you, going by last week's calendar?
Why ask it
Last week is harder to dress up than a typical one. Count what they list: meetings with engineers, calls with customers, reviews with leadership, time alone to think or write. If almost none of it is solitary work and you need that, weigh it now.
What do you enjoy most about being a product manager, and what wears on you?
Why ask it
The first half shows what keeps people in the job: for some it is watching a customer use the thing, for others it is getting a hard decision made. The second is often the constant switching between subjects, or being answerable for work that other people do. Picture a year of the wearing part before you decide the enjoyable part is enough.
How much of your time goes to deciding what to build, and how much to getting what is already decided out the door?
Why ask it
Many people want the first half and get mostly the second, at least early on. The split in their first PM job is the one that would apply to you, so get that figure as well as today's.
What do you write in a normal month: specs, strategy notes, updates for leadership?
Why ask it
Writing is much of how a PM gets a decision made when nobody reports to them. They may not be free to show you a real document, so ask what a good one of each kind contains. That gives you something concrete to practice.
How often do you talk to a customer or user yourself, and how do those conversations get set up?
Why ask it
Weekly contact that the PM arranges is one kind of job. Hearing about users secondhand through sales or a research team is another. If talking to users is why you want this work, let this answer steer which kinds of company you apply to.
What is the least glamorous task that still ends up on your desk?
Why ask it
Expect things like chasing a legal review, updating a help article, testing a build by hand or taking the notes in a meeting. PMs often pick up whatever has no other owner. Whether they tell it with a shrug or with resentment shows how heavy that part gets.
When did you last feel out of your depth, and what was the subject?
Why ask it
Pricing, a legal question, a technical design, a contract: PMs are regularly the least expert person in a room they are supposed to lead. Who they asked and how fast they caught up is the working skill. Someone who says it never happens is giving you the polished version.
How have AI tools changed what you do in a week, and what would you expect them to change for someone starting out?
Why ask it
Answers run from 'it drafts the first version of my specs' to 'my team ships AI features now and I had to learn how to judge them'. Those are two different skills, and it helps to know which one their employer cares about. Treat any forecast about junior roles as one person's guess and collect a few.
Build and measure
Where do the ideas for what to build come from, and how does one of them win?
Why ask it
Sources usually include customer requests, usage data, sales, leadership and the team's own hunches. The second half is the real question: you are hoping for a process, such as sizing the problem and holding it against a goal, as opposed to whoever argues longest. One idea traced from first mention to release will show you more than the general account.
What is the last thing you said no to, and who was asking?
Why ask it
Turning requests down is a large share of the work, and a recent example shows they do it. Notice whether they explained the refusal in terms the other person could accept, such as what it would have pushed out. If every example is a no to someone junior, ask about the last time it was someone above them.
What evidence do you want in hand before you commit engineers to an idea?
Why ask it
Strong answers name something checkable: a handful of customer interviews, a count of support tickets, a prototype people tried, a small test. 'It depends on the size of the bet' is fair if they then describe a small bet and a large one. Note the vocabulary, because PM interviewers probe the same ground.
Do you use a formal prioritization method, or is it mostly judgment?
Why ask it
Courses teach scoring frameworks, and you should know whether working PMs lean on them. A common reply is that a framework organizes the argument and judgment settles it. Interviewers may still expect the names, so find out which one they would learn first in your place.
How far ahead does your roadmap go, and how much of it do you expect to survive?
Why ask it
A PM who says the next few weeks are firm and the rest is a direction is being realistic. A year of fixed dates points to a business with long contracts, or to a plan handed down from above. The follow-up that sorts one from the other is who is allowed to change it.
How do you weigh fixing what already exists against building something new?
Why ask it
Bugs, slow pages and old code compete with features for the same engineers, and the PM usually has to defend the half nobody will demo. Some teams hold back a set share of each cycle for upkeep and some argue it case by case. Who pushes back hardest on that share, sales, leadership or the engineers themselves, shows where the pressure in the company sits.
When the data and your instinct disagree, which wins?
Why ask it
Get a real case and follow what they did next: ran a smaller test, talked to more users, or went with the number and watched. A PM who always trusts instinct, or always trusts the dashboard, is describing a simpler job than most. The interesting answers involve finding out why the two disagreed.
What have you built that you later wished you had not?
Why ask it
Every shipped feature has to be supported, explained and kept working, so the regret is often about cost and not embarrassment. A PM who can name one, and say what they would check beforehand now, has learned to count that cost. Give them a moment, since it takes some thought.
What is the one number your team is trying to move, and why that one?
Why ask it
Good PMs can give the metric and the reasoning without looking it up: retention because growth leaks without it, or time to first use because new accounts stall. The value itself may be confidential, so accept the type of measure. If there is no single number, ask how the team knows a quarter went well.
How is your own work judged, separately from how the product does?
Why ask it
A product can do badly under a good PM and well under a weak one, so companies judge the person in different ways: the metric, what shipped, what engineers and designers say. It varies by employer, so ask how it works where they are. The answer tells you whose opinion a new PM has to earn.
The team
What does a good working relationship between a PM and an engineering lead look like?
Why ask it
Hope for a division of labor: the PM brings the problem and the reason, the lead owns how and how long, and they argue in private before the team sees a plan. How long it took to reach that with their current lead is worth knowing, since a new PM starts from nothing. Constant conflict may be the pair or it may be the company, and they will usually say which.
What do engineers wish PMs would stop doing?
Why ask it
They will know, because engineers tell them: changing scope in the middle of a sprint, handing over a solution in place of a problem, promising a date nobody agreed to. Each item is a habit to avoid from your first day. It tends to lighten the mood, so keep it for when the conversation has gone stiff.
How technical do you need to be in your role, and where did you pick that up?
Why ask it
The expectation runs from following a discussion of trade-offs to reading code and querying a database, and it depends on the product and the employer. Have them name the first thing they would learn in your position. A former engineer can also tell you how the PMs beside them without that background manage.
When an estimate comes back far bigger than you hoped, what happens next?
Why ask it
The useful answers involve cutting the idea down to its most valuable piece instead of arguing with the estimate. Ask for an example of what got cut and whether anyone missed it. Leaning on engineers to shrink the number is the worrying version, and some PMs will admit they tried it once.
How early do designers come into your work, and who has the last word on how something looks and behaves?
Why ask it
Where a designer joins while the problem is still open, the PM frames it and stays out of the drawing. Where design arrives after the decision, the PM is closer to writing the solution. The line between the two roles shows most clearly when the PM dislikes a design, so ask about the last time that happened.
Outside engineering and design, who do you spend the most time keeping informed?
Why ask it
Sales, support, marketing, legal, finance and the executives each want something different from a PM, and which of them looms largest depends on the company. The form matters too: a weekly written update, a demo, a standing meeting. If you work in one of those teams now, you already know what they wish product would tell them, and that is worth saying in an interview.
What do you say to a salesperson who needs a feature to close a deal this quarter?
Why ask it
It is a classic test of a PM's judgment, and it turns up in interviews as a scenario. Listen for how they find out whether other customers want the same thing, and what the deal is worth against what it would delay. Some companies expect product to bend for a large contract and some do not, so ask how it goes at theirs.
How do you get people to follow a plan when none of them report to you?
Why ask it
Job postings call this influence, and the real methods are plainer: sharing the evidence early, asking for objections before the meeting, giving the credit away. If you have done something like it in a club, a cross-team project or a volunteer role, describe it and see whether they would count it.
How do you handle it when leadership wants something built that you think is a mistake?
Why ask it
You will hear how much room a PM really has. A good answer covers making the case once with evidence, then either committing or proposing a cheap way to test the idea first. If they simply build it, that says more about the company than about them.
Breaking in
If you were trying to get a first PM job today with no PM title on your resume, what would you do?
Why ask it
Ask this once they know a little about you, so the answer is aimed at your situation and not at beginners in general. Push for an order of steps, not a list. People tend to describe the door they used themselves, so check whether a newcomer could still walk through it.
Which skills matter most in a first PM job, and which did you only pick up once you were in it?
Why ask it
Writing clearly, reading data, running a customer conversation and deciding with half the facts come up often, but the order changes with the product. The second half is the relief: whatever they learned on the job is something you do not have to arrive with. Set the two or three they rank highest beside your resume and see which has no evidence behind it yet.
Which roles sit close enough to product that people move across from them?
Why ask it
Names you may hear include product analyst, product operations, program manager, solutions engineer, customer success, UX researcher and associate PM, but which of them truly lead across differs by company. The test is whether this PM has personally watched someone make the jump. A role nobody has left for product is a job, not a route.
What could I do in my current job or studies that a hiring manager would count as product experience?
Why ask it
Describe what you do now before asking, so they can point at something real. Typical answers: take charge of a small tool or process from start to finish, interview the people who rely on it, and write up what you changed and what happened. Whatever they suggest, ask how they would word it on a resume.
Between associate PM programs, an internal transfer and a small startup, which door have you seen people actually get through?
Why ask it
Each has a catch. Rotational programs take few people and may recruit on a fixed calendar, internal moves need a company that allows them, and a startup can give you the title with nobody to learn from. None of that is uniform, which is why what this PM has seen firsthand beats any ranking you find online.
Do courses, certificates or an MBA change anything when a PM resume is being screened?
Why ask it
Opinions differ sharply and so do employers, which is why one working PM's account of their own company beats a general claim. Find out what they look at on a resume before any credential. Where a course did help them, it matters whether it was the content or the people they met, because that is what you would be paying for.
When you have helped hire a junior PM, what made one candidate stand out?
Why ask it
If they have sat on a hiring panel, this is the closest you will get to the scoring sheet. Answers tend to be about clear thinking out loud and curiosity about users more than about experience. A PM who has never hired can still say what they believe got them their own first offer.
What were the rounds like when you interviewed for PM jobs, and which one do candidates trip over?
Why ask it
Formats vary by company. Product sense, analytical, execution and behavioral rounds are common labels, and some employers add a take-home exercise or a presentation. Get the names of the rounds exactly, since each has its own practice material, and ask how many weeks of preparation they needed.
Would a side project or a written teardown of a product help me, and what would make one worth reading?
Why ask it
Some PMs treat these as useful evidence and some never open them, so ask what would carry them past the first paragraph. A frequent answer is to show a decision and its reasoning, not a redesign of a famous app. If they offer to look at yours, send it within the week.
What did you read, listen to or practice that actually prepared you for the work?
Why ask it
Asking what prepared them, and not what they recommend, filters out the titles everyone lists. Write down the one or two they name and what each was good for: vocabulary, interview practice, or how to think about a customer problem. 'Nothing, I learned by doing' is a real answer too, and it points you back toward hands-on work.
Is there a product you think is especially well made that I should study, and what would you look at first?
Why ask it
You get to watch how a PM takes a product apart: the sign-up flow, the pricing page, what it chose to leave out. Do the exercise afterwards and mention what you found in your thank-you note.
Hearing my background, how would you tell the story of why I would make a good PM?
Why ask it
You are borrowing an insider's framing for your resume and your interviews. Write down the phrases they use, because they will be closer to how hiring managers talk than your own draft. If they struggle to find the story, that is the gap, and you can ask what would fill it.
What mistake do people trying to break into product make most often?
Why ask it
Expect to hear about applying only to famous companies, talking about features when asked about problems, or wanting the title more than the work. Check yourself against the list as they talk. Admitting on the spot that one fits you tends to get the better move described in the same breath.
Closing
What do aspiring PMs never ask you about this job that they should?
Why ask it
It gives them room to raise what you did not know to ask: how lonely the middle seat can be, how often plans are canceled, how pay and titles differ between companies. Ask it with a few minutes left and not as you stand up, so there is time for a real answer.
What is one thing I could do in the next thirty days that would move me closer to a PM job?
Why ask it
A deadline turns advice into a task. Good answers are small and checkable: talk to two more PMs, rewrite one resume line as a product outcome, apply to a specific kind of role. Repeat the step back to them so you both heard the same thing.
Who else should I talk to: a PM at a different kind of company, or an engineer or designer who works with PMs?
Why ask it
One PM gives you one company's version of the job, and the people who sit across the table from PMs will tell you things a PM will not. Check that they are comfortable with you using their name before you write to anyone. If they offer to make the introduction themselves, follow up within a day or two.
May I come back to you with a question or two when I reach the interview stage?
Why ask it
It keeps the door open without asking for a referral, which is a lot to ask of a first meeting. A request this small and specific is easy to agree to. Use it sparingly, and when you do write, say what you did with their earlier advice.
How to run a coffee chat with a product manager
Practical guidance for the conversation itself
Before you meet
Pick a PM whose path you could follow
A director of product has a wide view, but their first PM job may be a decade behind them. Someone in their first or second PM role went through hiring recently and can describe it as it is now. If you can, talk to one of each, and to PMs on different kinds of product, since a consumer app and business software are run very differently.
Use their product first
Sign up for what they work on, or read what is public about it if you cannot get in. Arrive with one thing you noticed and one thing you could not work out. A specific observation shows the curiosity product teams hire for and gives them something to react to. Do not arrive with a list of fixes.
Have your one-minute account ready
The questions under Breaking in only get useful answers if the PM knows where you are starting from. Prepare a short version: what you do or study now, why product, and what you have tried so far. Keep it to a minute and offer it early, so the rest of their advice is aimed at you.
Choose six to eight questions
A half-hour chat has room for about that many once follow-ups are counted. Take one or two from each group. If you are still deciding whether you want the job, lean on The week and Build and measure. If you already know, spend most of the time on Breaking in. Always keep one from Closing.
During the conversation
Open with their story
The questions under Their path are easy to answer and people enjoy them, so they make the first five minutes comfortable. They also tell you which of your later questions matter: a PM who came from engineering and one who came from marketing will give different advice about getting in.
Trade 'how do you' for 'when did you last'
PMs are practiced at describing process, and a general question gets a tidy general answer. Asking for the most recent time they turned something down, cut scope or disagreed with a designer gets a story with people and consequences in it, which is what you cannot find in a book about product management.
Respect what they cannot share
Roadmaps, metrics and customer names are often confidential. Say at the start that you are after the shape of the work and not the details, and accept 'I cannot go into that' without pressing. Asking what kind of number they watch works where asking for the number does not.
Leave the job out of it
Do not ask about openings on their team or for a referral. If they think you would fit somewhere, they will raise it, and they are more likely to once you have followed up on their advice. Asking in the first meeting turns a conversation into a favor they have to refuse or grant.
Keep the time yourself
When you reach the time you asked for, say so and offer to stop. Many PMs spend their days moving between meetings, and one that ends when promised is remembered. If they choose to keep going, that is their decision to make.
Making sense of what you hear
One PM is one company
How much a PM decides, how technical they need to be and how they are judged all differ from one employer to the next. Treat each conversation as a single sample. When two PMs contradict each other, ask a third what explains the difference: it is usually company size, the kind of product or who product reports to.
Ask yourself whether you want the week, not the title
After the chat, write down what they actually spent last week doing. If the list is mostly persuading, writing, chasing and saying no, and that still appeals, you have learned something good. If what drew you was building things yourself, engineering or design may be a better fit, and a PM is a good person to ask about that.
Turn their words into evidence
Note what they said would count as product experience and the phrases they used for it. Then look at your own history for one example that matches, and write it up the way they described: the problem, what you decided, what changed. That paragraph is the start of a resume line and an interview answer.
Look for the pattern after three chats
A single piece of advice may be one person's habit. Advice you hear from three PMs who do not know each other, such as learn enough data analysis to answer your own questions, is worth acting on first.
Mistakes to avoid
Asking what a product manager is
Anything a search would answer in a minute spends their time badly and suggests you have not started. Read a general description of the role beforehand and ask what is different about how it works where they are.
Pitching your app idea
It is tempting to show a PM your own product idea and ask what they think. It turns the meeting into a review of your idea and leaves you knowing little more about their job. If you have built something, mention it in one sentence and ask whether it would help an application.
Treating frameworks as the job
Prioritization models and interview formats are worth one question each. A chat spent on acronyms misses what only a working PM can tell you: who really decides, what gets in the way, and what the week feels like.
Going quiet afterwards
Send a short thank-you within a day that names one thing you will do because of the conversation. Then do it, and write again when you have. People who report back are the ones a PM remembers when a junior role opens or a colleague asks for names.