It’s OK to Say I Don’t Understand

A brief survival guide for PMs on calls where the brief is too technical or too vague.

We’ve all been there: you’re on a briefing call, the client is explaining what they need, and about four minutes in, you realize you’ve lost the thread. Maybe they’re using acronyms you haven’t heard before or talking about their processes as if you were working in their company for the past 10 years. So you find yourself nodding and typing notes, but you’re thinking: I have no idea what I just agreed to.

A common onboarding of a PM is to hold it together in such situations, keep nodding, and say that you will check with the team after the meeting is over (hoping you captured the keywords in your mind correctly).

Here’s a better approach.

Saying “I don’t understand” is not a confession of incompetence. It’s a professional move when done right.

The version that works: “Just to make sure I’ve got this right, let me repeat back what I’m hearing…” Then summarize in your own words, simply. This does three things:

• it confirms your understanding
• it gives the client a chance to correct any gaps
• it signals that you’re paying attention

Clients actually find this reassuring because someone who is summarizing is someone who is engaged. On the other side, someone who is nodding may oversee requirements that should have been discussed.

Questions are there to just expose what you don’t know. They can help the client clarify what they actually want, because often, clients themselves haven’t fully defined the requirement yet.

Try: “When you say [technical term], do you mean [your interpretation]?” Or: “What does success look like for this feature specifically?” These questions reframe the brief into something concrete.

Also, avoid the trap of asking vague questions like “Can you please clarify that?” It’s important to give the other speaker something to react to, like your interpretation, because even if wrong, is more useful than a blank request for more information.

Make it a habit to end every call with a clear summary of what was discussed, on top of sending it in a follow-up email. This positions you as organized and thorough, but it also gives you a chance to revisit anything you weren’t sure about.

Just say: “Allow me to sum it all up, and please correct me if I’ve missed anything”. Nonetheless, this helps you go over your notes so you speed up your time reviewing them before sharing them after the meeting.

The PM role isn’t about being the most technical person on the call, not even in this AI era. It’s about translating between what the client wants and what the team can build. You don’t need to know how an API works, but you do need to know enough about the industry to ask the right questions, spot the risks, and hold the scope together.

Of course, there will still be moments when you have summarized, asked the right questions, and the topic is still too technical to confirm on the spot. That is when it is completely fine to say: “I’ll confirm this with the dev team and come back to you within X.” It should not be the first answer you reach for, but it is much better than pretending to understand or confirming a scope that is not actually clear.

• How to Handle Unclear Project Scope in 5 Steps – LinkedIn Advice
• How to Handle Unclear Instructions – LinkedIn Advice
• Dealing with Unclear Requirements – ProjectManagement.com
• The Cheat Sheet on Communication with Clients – Netguru
• 5 Client Management Skills Every PM Needs – Birdview PSA
• How to Start Projects Better with Your Clients – The Digital Project Manager