Q&A often feels scarier than the presentation itself.
When you’re presenting, you know what’s coming. You’ve got your slides, your talking points, and the story you’ve rehearsed. But the moment someone raises their hand, all of that goes out the window.
You probably do know the answer. You may have built the model, run the research, or led the project. But now you have to turn all of that knowledge into one response, in real time.
That’s where even experts come unstuck.
The pressure to respond quickly makes you start talking before you’ve worked out what to say. Then you remember a detail from testing, so you add a caveat. Three minutes later, the answer is way too long, and the person who asked is still waiting for the main point.
I know that feeling. I’ve done it myself. And I’ve coached plenty of smart people through the same problem. Because it doesn’t have to go that way. Handled well, Q&A is actually one of the fastest ways to build trust in a room. Here’s how to do it.
The SPEED Framework
This framework has five moves you can use to structure your response
- Silence – A short pause
- Point – A short answer
- Explain – The reason the answer matters
- Example – Evidence to support your answer
- Direction – An indication of what’s next
Let’s walk through each one with a real scenario.
Imagine you’re launching a new checkout page for a website. Technically, it’s a total success – the money goes exactly where it’s supposed to go every single time. But there’s a tiny, awkward lag. When the bank is slow to respond, the screen stays blank for a few seconds. Even though the transaction is finished, the customer is left staring at a frozen page, wondering if their money just vanished.
In your next meeting, you present this as an update, when your boss asks: “Given this problem, are we still ready to launch on Monday?”
That is exactly the sort of question that makes people rush. So here is how to answer it well.
1. Silence
Your instinct when a tough question lands is to catch it and throw something back immediately. Resist that.
Pause instead.
This is one of the biggest shifts I teach. Most people treat silence like dead air. It is not. Silence is part of the answer. It gives you a moment to separate the words of the question from the real issue underneath it.
In the payment portal example, the question on the surface is, “Are we ready to launch?”
But what they really need to know is whether the risk is under control and whether Monday still makes sense.
Those are slightly different questions, and if you answer the deeper one, your answer gets much stronger. Silence helps you see that before you open your mouth.
If the pause feels strange for you, or you need a phrase to hold the room while you think, use one of these:
- “Good question.”
- “I’ve got a few things to say about that.”
- “This is how I see the situation”
These lines buy you the precious seconds you need and signal to the room what kind of answer is coming.
2. Point
This is where a lot of experts go wrong. They want to be careful, so they start with all the context and hope the listener pieces together the answer themselves.
Don’t make people work for it. Give them the answer first.
For the payment portal, the point might be:
“Monday is still right for a controlled pilot. The full customer launch should wait until the issue is fixed.”
I often tell people that your point should be short enough that someone else in the room could repeat it afterwards. If your listener has to dig through your answer to find your view, you have made their job too hard.
3. Explain
Now you say why you gave that answer.
This is what stops your point from sounding like a gut feeling or a random opinion. It connects your answer to something the listener actually cares about.
For the payment portal:
“The reason is customer confidence. If someone pays and the screen stays unclear, they may think the payment failed and try again.”
Inside the project, the issue probably looks manageable – the payment works, the data is safe, it resolves itself after a moment.
But from the customer’s point of view, it’s a completely different experience. They’ve just handed over money and the page is giving them uncertainty. They might refresh, try to pay again, call support, or lose faith in the system.
Useful explain lines often start like this:
- “That matters because…”
- “The reason this is important is…”
- “This decision is critical because…”
Explaining well means telling people why they should care – not just what you decided.
4. Example
Now support your point with one clear example.
When people are nervous, they often dump too much evidence into the answer. They think more detail will make them sound more credible. Usually it just muddies the response.
For the payment portal, a clear example could be:
“In testing, when the payment finished, we saw half of participants try to refresh the page and resubmit the money.”
This shows what happened without walking everyone through the entire test plan.
5. Direction
A lot of Q&A responses fade out because the speaker keeps adding things. Direction gives you a clear finishing line and tells people what should happen next.
For the payment portal example, the direction might be:
“My recommendation is to run the Monday pilot with a small customer group, monitor confirmations and support contacts for 48 hours, and only move to a wider launch once the confirmation flow is clean.”
Useful direction lines include:
- “My recommendation is…”
- “The next step I would take is…”
- “The trade-off I would accept is…”
- “The decision I would make is…”
By the end of the answer, people should know where you stand.
Putting it all together
Here’s what the full answer sounds like:
“Good question. Monday is still right for a controlled pilot. The full customer launch should wait until the confirmation issue is fixed. The reason is customer confidence. If someone pays and the screen stays unclear, they may think the payment failed and try again. In testing, when the payment completed, we saw half of participants try to refresh the page and resubmit the money. My recommendation is to run the Monday pilot with a small customer group, monitor confirmations and support contacts for 48 hours, and only move to a wider launch once the confirmation flow is clean.”
It answers the question, names the stakes, gives one concrete example, and finishes with a sensible next step.
When you do not know the full answer
Some questions will catch you out. That’s fine – you don’t have to have everything figured out. The same framework still works.
Let’s say in the payment portal scenario, you genuinely don’t know how often the confirmation lag will affect real customers because you haven’t done enough testing.
A good answer might sound like this:
“Good question. The honest answer is that we know the issue exists, but we don’t yet know how often it will show up in live traffic. That matters because a rare issue can be managed in a small pilot, while a common one needs a fix before any customer release. What we do know from testing so far is that the payment itself still completes. My next step is to run a volume test today and bring back the expected customer impact tomorrow morning so we can make a decision before launch.”
The structure is:
- Silence: “Good question.”
- Point: “The honest answer is that we know the issue exists, but we don’t yet know how often it will show up in live traffic.”
- Explain: “That matters because a rare issue can be managed in a small pilot, while a common one needs a fix before any customer release.”
- Example: “What we do know from testing is that the payment still completes.”
- Direction: “My next step is to run a volume test today and bring back the expected customer impact tomorrow morning so we can make a decision before launch.”
You’re not hiding the gap – you’re naming it, anchoring it to what you do know, and giving a clear next step. That keeps your credibility intact. People respect honesty about uncertainty far more than a confident answer that turns out to be wrong.
How to practise before you speak
The best time to get better at Q&A is before you are in the room. So if you’re speaking at a big meeting or at an event, do not just rehearse your presentation, rehearse the pressure points that are likely to come up.
Think about the pressure points that tend to come up for any project you’re working on.
For most teams, those are cost, risk, evidence, timeline, ownership, failure, and the case for acting now. Pick one and practise answering it out loud using the SPEED framework.
And make sure you’re doing it out loud. A lot of people think they have practised because they have thought about the answer privately. That is not the same thing. The real skill is not just knowing what you think but being able to turn that thinking into clear speech.
Once you get more comfortable, make it harder. Ask someone to interrupt you halfway through. Ask for a 30-second version. Ask them to challenge your recommendation. That is where the real training kicks in – because you’re doing it under pressure.
Final thoughts
Q&A is one of the clearest tests of how you communicate under pressure.
In high-stakes moments, people are not only judging the content of your answer, but also whether they trust you. The SPEED Framework gives you a reliable way to settle yourself, answer the real question, explain why it matters, make it concrete, and finish with a clear next step.
Think and Speak Under Pressure is built for these moments: the unexpected question, the answer that needs to be shorter, and the decision-maker who is watching how you handle pressure. Find out how to get involved.
