A survival guide for the first 90 days, when the questions are faster than your onboarding.
It is week two of your first product manager job. You are in a meeting. The meeting has been going fine. You have been nodding at a roughly appropriate cadence. You drank water at a socially acceptable moment. Things are going great.
Then a senior engineer turns to you and says: “So — what's the actual goal here? Like, what are we optimizing for?”
Everyone looks at you.
You do not know. You have known about this product for eleven business days. You have not yet found the bathroom on the third floor. You do not know what you are optimizing for. You do not know what optimizing means in this building. You are fairly sure one of the words in the acronym they keep using is “synergy,” but you are not sure which one.
You have roughly 1.8 seconds to respond.
This is the Verbal Ambush. It is the single most common unspoken nightmare of the new product manager, and almost no one writes about it because no one wants to admit it happens. So: hi. It happens. To everyone. The only real difference between new PMs and senior PMs is that senior PMs have a larger library of things to say when they don't know the answer.
Below is the library. Steal freely.
Before the phrases
Why “just be confident” is the worst advice a new PM has ever been given
A lot of early-career PM content tells you to project confidence. Own the room. Speak with authority. Bring data.
This is catastrophic advice for your first ninety days, for one simple reason: the people you work with — especially engineers — can smell confident nonsense from two floors away. Confidently guessingis the single fastest way to lose your team's trust. You get one shot at being the person who makes things up, and then you are that person for the rest of your tenure.
The actual skill of a brand-new product manager is not knowing things. It is saying the true thing in a way that does not light your credibility on fire. This is a real skill. It is trainable. Most PM courses do not cover it because “here are some phrases” feels less impressive than “here is a framework.” But the phrases are what you will actually use at 10:47 a.m. on Tuesday.
Here they are.
Class 1
The honest “I don’t know yet”
For when you just… don't know.
When a stakeholder asks a question you can't answer
“That's a fair question and I don't have the answer in front of me. Let me come back to you by end of day with something concrete.”
Why it works — It is not an apology. It is not a flinch. It's a short, adult sentence with a commitment attached. You then write a sticky note that says CALLBACK in all caps and you actually do it. Doing it is the whole trick.
When an engineer asks “why are we building this?”
“Good question. I've got a working answer, but I want to pressure-test it with you — can I walk you through what I've got and you tell me what doesn't hold up?”
Why it works — You flip the ambush into a collaboration. Engineers love pressure-testing things. You are no longer defending a position; you are co-authoring one. Also — crucially — you now have a reason to go find a real answer before the meeting.
When someone asks for a number and you don't have one
“I don't want to give you a number I'd have to walk back. Give me until [specific time] and I'll get you something I can actually defend.”
Why it works — “A number I’d have to walk back” is the most PM thing you can say. It signals you understand that made-up numbers become real commitments roughly four minutes after they leave your mouth.
Class 2
The clarifier
For when you literally don't understand the question.
Half the time, the reason you can't answer is not ignorance — it's that the question was vague, loaded, or secretly three questions in a trench coat.
When a question has too many parts
“Can I play that back? I want to make sure I'm answering what you're actually asking.”
Why it works — You now get to restate the question in terms you can answer. This is not a trick. It’s the single most underrated move in product management. You will be shocked how often the person says “actually no, what I really meant was…” and tells you exactly what to respond to.
When someone uses a term you don't recognize
“Quick check — when you say [term], do you mean [your best guess], or something more specific?”
Why it works — It's honest without being helpless. You are demonstrating that you care about precision. Nobody has ever been fired for asking for precision. Plenty of PMs have been fired for nodding at the word ICP for eight months and then revealing they thought it meant Insane Clown Posse.
Class 3
The acknowledge-without-committing
For when the question is a trap.
Some questions are not questions. Some questions are feature requests wearing a question costume. Some are timeline demands pretending to be curiosities. Some are HiPPO pronouncements with a question mark glued on the end.
When someone “just wondered if we could add” something
“Interesting — I want to give this the real treatment rather than a yes or no on the fly. Can you send me the use case and I'll come back with how it stacks against what's already on the roadmap?”
Why it works — You have said nothing. You have also not said no. You have not committed to building it. You have moved the decision out of the meeting and into a place where evidence can enter the room. This is 70% of the job.
When an exec asks when something will be “ready”
“Happy to give you a date. I just want to be honest that any date I give you right now is a guess dressed up as a commitment. If you want a real one, I need [X] days to scope with engineering. If you want the guess, I'll caveat it loudly.”
Why it works — You are giving them a choice between a real answer and a fake one, and making clear which is which. Most execs, when framed this way, will pick the real answer. The ones who pick the fake answer have now been warned, in front of witnesses, that it is fake.
Class 4
The redirect
For when you are not the right person to answer.
New PMs feel a gravitational pull to answer every question asked in their direction, because admitting you're not the right person feels like admitting you're not a real PM. This is wrong. Real PMs redirect constantly.
When a deeply technical question lands on you
“I want to make sure you get the right answer, not mine. [Engineer] has been in this part of the codebase — let's pull them in rather than me paraphrasing badly.”
Why it works — You've made your engineer look important. You've also avoided saying something technically wrong in front of people who will remember it forever. Win, win.
When a business question lands on you and you have no context
“I don't want to answer for [function] — let me get the real context from [person] and come back with something grounded.”
Why it works — Same principle. You are the router, not the encyclopedia.
Class 5
The buy-time
For when you need the meeting to move on so you can think.
In a standup when you don't really have an update
“Nothing blocking. I'm heads-down on [thing] and I'll have something more concrete by [day].”
Why it works — Standups are not status theater. Nobody needs a play-by-play. “Nothing blocking” plus a next milestone is a complete, professional update. You do not need to invent drama.
When someone asks what you think and you have not finished thinking
“Honestly, I'm still forming a view on that. Give me a day with it and I'll have a real take.”
Why it works — “Forming a view” is a phrase that buys you infinite runway, because thoughtfulness is a feature, not a bug. Nobody wants a PM who takes a position on every topic within four seconds of hearing it. Those PMs are called consultants.
Blocklist
What to absolutely not say
There is a parallel phrasebook of things that new PMs instinctively reach for that will quietly nuke their credibility over a six-month window.
“Um, I think so?”
If you think so, say so without the um. If you don’t know, say you don’t know. This hybrid is the worst of both.
“I'll circle back.”
Fine once. After that it becomes the PM equivalent of “the check is in the mail.” Replace with a specific time: “I’ll have this by 4pm Thursday.”
“That's a great question.”
Everyone knows this is a stall. Engineers especially. Use sparingly, and never twice in the same meeting.
“We should probably…”
“Probably” has no place in a product decision. Either we should or we shouldn’t. If you don’t know which, say that directly.
“No, yeah, totally.”
You are not agreeing. You are buffering. We can hear the buffering.
The real skill
Practicing before the meeting, not during it
Here is the uncomfortable truth. You cannot improvise your way to good PM responses. These phrases work because they have been rehearsed. You need reps before you need polish.
The problem is that reps in real meetings are expensive. Every ambush you fumble costs you a small amount of credibility that compounds over months. The engineers start to sigh when you speak. The VP starts cc'ing your manager. The roadmap review becomes something you dread at a cellular level.
You need a place to be bad at answering questions before it matters.
Low-stakes reps
The PM Simulator is built for this.
It drops you into real decision scenarios, throws the ambushes at you, lets you respond, and shows you how the response would have played out with a real team. You can fail safely on a Tuesday night on your couch, rather than in front of your CTO on a Thursday morning.
Try the PM Simulator→That's the actual edge new PMs get. Not more frameworks. Not another Kanban book. Just enough repetitions that when the senior engineer turns to you in week fourteen and says “so what are we actually optimizing for?”, the first words out of your mouth are calm, short, and true.
You still might not know the answer.
But you'll know exactly what to say.
Are you a new or aspiring product manager getting blindsided by questions you don't know how to answer? Try the PM Simulator at PM Depot — practice stakeholder ambushes, engineering pushback, and exec pressure in a low-stakes environment, so the first time you face them isn't in a real meeting.
Open the Simulator→