Can You Give Me an Update?
Why great PMs answer differently depending on who’s asking — and how the “Answer → Explain” method builds trust, clarity, and momentum.
Let me start with a situation every Product Manager knows too well.
The Story: When a Simple Question Turns Into a Maze
It’s 4:00 PM on a Tuesday.
You’re switching between tabs, half-preparing for tomorrow’s review, half-answering Slack pings.
Your Engineering Lead messages you:
“Hey, quick one — how’s the onboarding experiment going?”
You start typing:
“Well, we’ve been running it for two weeks. Last week we had an unexpected issue with the event tracking, so data is a bit incomplete. We’re cleaning it now. Also, Design suggested a small tweak in step four, so the variant isn’t fully consistent across markets. And we haven’t added the fallback logic yet, because—”
You pause.
You re-read the message.
You sigh.
Because you know exactly what happened:
You didn’t answer the question.
You explained your work.
Not the status.
And the worst part? Your Engineering Lead didn’t ask for any of the context. They asked for exactly one thing:
👉 Is the onboarding experiment working?
And this is where most PMs — even the senior ones — unconsciously slip.
We answer with the process instead of the point.
Why This Matters More Than You Think
When someone asks you:
“Can you give me an update?”
They’re not asking for a diary entry.
They’re trying to make a decision.
Different people make different decisions:
A VP wants to know whether to invest more, pivot, or stop.
A Head of Customer Support wants to know whether to hire more people.
A Design Lead wants to know whether the experience improved.
A Business stakeholder wants to know whether this affects revenue or cost.
An Engineering Lead wants to know whether it’s stable and worth optimizing.
Your squad wants to know what to do next.
But if you respond with:
who you talked to
what meetings you had
how the process went
which confluence page you updated
or the Jira ticket journey of a single feature
…you’re not enabling decisions.
You’re creating noise.
No one can act on noise.
And that’s why the Answer → Explain method is so powerful.
It turns noise into clarity — fast.
The Core Method: Answer → Explain
This is the storytelling technique that turns a 3-minute monologue into a 15-second answer that builds trust, clarity, and direction. A great update — the kind that travels across the company — has two parts:
1. ANSWER (what they want to know)
This is the headline.
The bottom line.
The “one big number” people will remember and repeat.
Answer = Big Number + Decision
Examples:
“Activation is up +6% — I recommend we expand the experiment.”
“The chatbot resolved 62% of questions — we can delay hiring additional agents.”
“Drop-offs decreased by 14% — the redesign is working.”
2. EXPLAIN (only what they need to make that decision)
This is not a process recap.
This is not your journey.
This is not your Jira board.
Explain = Relevant context → Why this matters → What’s next
That’s it. This structure forces clarity, reduces noise, and builds trust fast.
And now let’s combine it with the most important PM skill of all: understanding who’s asking.
Understanding Who’s Asking (and Tailoring Your Answer)
One question. One big number. Different explanations.
Imagine you launched an AI support chatbot.
After four weeks, you have one memorable, simple headline number:
👉 The chatbot resolved 62% of incoming questions without escalation.
That is your Answer.
You do NOT change this number per audience.
The number stays the same — the meaning changes.
Below: the same ANSWER, tailored EXPLANATIONS for each role.
1. VP of Product
🎯 Their decision: invest more, pivot, or stop.
ANSWER:
“It’s working — the chatbot resolved 62% of questions. I recommend scaling it.”
EXPLAIN:
“We focused on simple ‘quick questions.’ This reduced load on agents and improved issue resolution time. We have one guardrail: improving fallback for ambiguous intents before full rollout.”
2. Head of Customer Support
🎯 Their decision: Do we need to hire more agents?
ANSWER:
“The chatbot resolved 62% of questions — we can avoid hiring two additional agents this quarter.”
EXPLAIN:
“Most deflections were password resets and delivery ETA queries. Complex cases still go to agents, but the load reduction gives your team breathing room.”
3. Engineering Lead
🎯 Their decision: Is the system stable? Do we optimize?
ANSWER:
“It’s stable — 62% resolution with healthy latency.”
EXPLAIN:
“No major incidents. The only improvement needed is stronger fallback logic for unclear intents next sprint.”
4. Design Lead
🎯 Their decision: Was the experience improved?
ANSWER:
“We resolved 62% of issues — users finish support flows faster with less friction.”
EXPLAIN:
“Feedback shows clarity in simple flows. Users struggle with multi-step topics, so we have room for refinement.”
5. Business / Commercial Stakeholder
🎯 Their decision: Does this reduce costs or increase value?
ANSWER:
“The chatbot resolved 62% of issues — it meaningfully reduces handling costs.”
EXPLAIN:
“We’re lowering per-ticket cost while keeping satisfaction stable. This impact will grow as we expand to more segments.”
6. Your Squad
🎯 Their decision: What do we build next?
ANSWER:
“The chatbot resolved 62% of questions — next we focus on better fallback logic.”
EXPLAIN:
“This unlocks coverage for more complex topics and increases overall resolution rate.”
Notice What Happened Here
You didn’t change:
the number,
the success signal,
or the core message.
You changed the lens — because different roles make different decisions.
That is Product Storytelling.
Bad Answers That Every PM Should Avoid
🚩 Process dumping
“We deployed the first version last week, then cleaned the data pipeline, then ran into a bug…”
Nobody asked.
🚩 Chronological recaps
“First we tested A, then B happened, now we’re working on C…”
This is a status log, not a decision-enabling update.
🚩 Thinking out loud
“So maybe users are expecting… I guess we’re seeing some traction…”
If you are unsure, they become unsure.
🚩 Burying the headline
“We talked to support yesterday and…
…oh yes, the experiment is actually performing well.”
Start with the answer.
Always.
How to Use Answer → Explain in Your Daily PM Work
Here’s what great PMs do consistently:
1. They choose ONE big, repeatable number.
The number that travels across the company.
2. They form a headline that carries a decision.
Not “progress.”
A decision.
3. They tailor the explanation to the listener’s decisions.
Staffing.
UX.
Stability.
Revenue.
Direction.
4. They make their update useful, not exhaustive.
Useful = “I know what to do next.”
Exhaustive = “Why did they tell me all this?”
5. They turn updates into momentum.
Every answer ends with a clear next step.
Closing: Your Update Is Not About You
It’s not about your process.
It’s not about the effort you put in.
It’s not about the meetings you attended.
It’s about enabling someone else to move.
When someone asks:
“Can you give me an update?”
You respond with:
Answer → the headline, the big number, the decision.
Explain → only the context that helps them make their decision.
That’s how you build trust.
That’s how you influence decisions.
That’s how you lead.
Not by talking more —
but by saying the right thing, in the right order, for the right person.
Please, Just Answer the F*** Question! 🤌
To illustrate what this article is about, let’s start with a dinner scenario. Imagine you’ve invited your friend over for dinner, and they ask a simple question:
You need to share the same context with the person who is going to listen to your answer. They are not just expecting answers. They are hoping you will point them toward the next step.