"The real problem of communication is not what is said, but what is understood.” - Peter Drucker
I was on a call last month with a product leader named Priya. She'd just come out of an exec meeting. You know the one.
You spend weeks turning over a problem. You map the dependencies, follow a thread from a customer complaint through three layers of operations to a root cause that explains everything. You sit down with the team, confident, and lay out the conclusion.
The room goes quiet.
Then someone asks about a detail you resolved two weeks ago. Someone else suggests an alternative you already ruled out. You explain the same point three different ways, and people nod, but the nod doesn't mean anything.
Priya said: "I felt like I was speaking a different language."
Her team had spent six months building a feature set for enterprise clients. The usage data was clear: clients adopted the new tools, but after thirty days, they dropped off.
Priya had done the work no one saw - interviewed users; mapped the onboarding sequence; realized the problem wasn't the features - it was that clients were being handed too many setup decisions at once.
Her conclusion: strip first-phase configuration down to three default choices and delay advanced settings until week four.
She brought this to the executive team.
They nodded. Then they asked for more data as they were worried about alienating power users. They even suggested a different segmentation model. One person asked if she'd considered a phased rollout, which was exactly what she'd just proposed.
What they couldn't see was the trail of dead ends she'd already walked - the A/B test that showed more choices led to drop-offs; the sales calls where reps admitted they were overriding setup because clients got stuck.
Priya had done the work. But she'd presented the answer without showing the path.
I've done this myself more times than I'd like to admit.
In Issue #44 of The Storyteller we’ve written about the power of what often goes unsaid - the stories we don’t tell, the moments we leave out. This is a similar problem. Except here, it’s not the story that’s missing. It’s the thinking behind it.
What Priya needed - what any of us need in that moment - is a way to let people walk the path with you. Not a simplified version of the conclusion. The actual route you took.
I've found a structure that works, though I'll warn you it sounds almost too simple. Three parts.
Start with the original question. In Priya's case: "We built these features. Usage was up at day one, but down at day sixty. We didn't know if it was the product, the onboarding, or the client profile."
Then show what you examined next. "We shadowed five onboarding calls and saw the same thing: each client spent the first forty-five minutes on setup decisions that had nothing to do with their use case. Sales was defaulting to 'just show them everything.'"
Then state what became clear. "The issue wasn't missing features. It was that we asked clients to become experts before they'd even used the product."
That's it. No elaborate deck needed.
The next time Priya walked stakeholders through that arc - question, observation, insight - she told me the difference was immediate. People stopped proposing alternatives she'd already considered. They started asking better questions. One person said, "Oh, I see it now."
Try This Week
Pick a decision you're about to present. Instead of opening with your conclusion, put down what you actually saw
the customer comment that made you pause
the spreadsheet number that looked wrong
the meeting where someone connected two problems you'd been treating separately.
Then tell them where it led you.
Most audiences aren't resisting your idea. They're just trying to catch up. Show them the path. Better yet, walk them through it.