There’s a section of my blog where I write “build notes,” reflections from someone without a traditional tech background who learned to build things anyway.
This one isn’t a technical build. It’s about what years of building analytics engines and helping people make better decisions taught me the hard way.
Across consulting and later building data products, I realised two lessons kept showing up. Both were shaped by setbacks, embarrassing client moments, and plenty of “we should’ve done better” reflections. And it all started with the most painful one.
About eight years ago, I was the most junior person on a consulting team. We spent months designing a beautiful report: polished slides, clever charts, the works.
The client’s feedback?
YES, the smiley was part of the email.
It still ranks as one of the most embarrassing moments of my career. Not because the work was bad, but because it completely missed the point.
The client had already decided to enter a new country. The strategic why was settled. What they needed from us was painfully simple:
“How do we do this?”
Which partners matter? What are the first three moves? Who do we speak to?
Instead, we gave them a beautifully structured argument for why they should enter the market.
Wrong question, wrong direction.
Looking back, the mistake was rooted in the scoping phase: we didn’t apply first-principles thinking, and we never checked whether we were solving the question they were actually asking.
That experience stuck with me as I moved from pure consulting into data and product, where I had to productize the entire idea of helping someone make faster, more effective decisions.
Over time, the patterns became very clear.
I know what you’re thinking. “Empathy” gets thrown around so casually that it feels like motivational wallpaper. Overused advice, repeated everywhere. But stay with me while I break it down.
“Tell me something I don’t know” is user research in disguise.
When someone asks for an insight, they’re really asking:
Do you understand me, my world, and the problem I’m trying to solve?
That’s harder than it sounds, especially when the audience is a leader who has lived in that domain for 20+ years. Matching their mental model requires:
Deep curiosity about their context
Asking pointed questions (and learning how to ask them)
Understanding what they consider “useful”
Reverse-engineering their decision process
At its core, my job became applying first principles to their decisions. What really helped was starting here:
What are the 2 to 3 real questions they are trying to answer?
Usually, these start broad and vague.
Then you double-click.
You ask why.
Then why again.
Product folks will recognise this as the “5 Whys” in action.
After enough back and forth, you eventually arrive at a list of 10 to 15 unit level questions. In data terms, these should be straightforward SQL queries, which becomes the ingredients for us to move forward. The insight lives in the relationship between the queries. These connections can be observed in:
Which facts reinforce each other
Which contradict each other
Which matter more than others
Which depend on context or constraints
Which unlock or eliminate certain levers
The list of facts eventually starts behaving like a story.
This structure eventually became a simple but surprisingly powerful mental model I now use for every analytics or decision workflow.
I now call it the Decision Stack and here’s what it looks like:
Each layer forces you to stay grounded:
Intent clarifies what decision is actually on the table.
Levers outline which actions are even possible.
Signals identify what evidence matters.
Units of Evidence convert those signals into query-level facts.
Narrative connects those facts into meaning.
Action collapses the meaning into a recommendation.
This why I often compare analysis to cooking: Unit level facts are the ingredients (SQL queries) and the actionable insight is the dish. The “insight” - is just how you mix, season, and plate the unit level facts.
Cooking is an entirely different art and science when technology enters the kitchen, especially now with LLMs. If you’re curious about how this plays out with structured data, I wrote about my experience “cooking” with tabular data here.
Understanding this was the turning point for me, and once it clicked, the second lesson became obvious.
When users say they want “more insights,” they usually don’t.
They want fewer insights they can actually act on.
In reality:
Most leaders are already overwhelmed by dashboards.
They don’t need more charts; they need clarity.
They want the noise reduced, not increased.
The tricky part?
Users rarely know this.
They think they want “more depth, more detail, more analysis”, until you give it to them and they drown.
This is why the rise of AI has exposed the problem even more.
AI can generate tons of paragraphs and documents in seconds. It’s essentially replicating the lower tier consulting output, which explains the sudden wave of “death of consulting” videos on YouTube.
But the systems that win are the ones that embody a simple principle: Say less, but say something powerful.
A powerful insight doesn’t have to be complicated. Often it’s just pointing to where most of the movement sits.
Imagine a sales team investigating a dip in revenue: they build a 40-slide deck, explore every channel, segment, and product line - only to realise the useful insight was a single line: “Most of the drop is coming from one region; fixing that region fixes the quarter.”
That’s clarity. And you don’t need to claim that region caused the entire slip if the context is more complex; you’re simply showing where the the leverage likely is.
When causality isn’t clear, language helps. Words like likely, suggests, points to, or is concentrated in keep the insight sharp without overstating certainty. You avoid the trap of “correlation equals causation,” while still giving people something they can act on.
Saying less isn’t about dumbing things down.
It’s about stripping away everything that doesn’t move the decision. Building systems that can deliver that consistently is incredibly hard. Productizing this is even harder. Sure, we have powerful models for predicting, recommending, and optimizing. But the real value shows up when a system can produce insights that are sharp, context-aware, and immediately actionable. That’s the kind of clarity people actually move on.
These two principles “empathy in, clarity out” sound basic. But they took me years of mistakes, awkward meetings, and confused clients to fully internalize.
Building analytics systems isn’t really about data.
It’s about people: What they care about, what they ignore, and what helps them move.
If you’ve ever had your work dismissed with a line like “we already knew this,” trust me, you’re not alone.
But buried inside that feedback is the blueprint for building better.
No posts
Comments
Nothing yet. Say the first thing.
Sign in to join the conversation.