The First Conversation Is Never About Data
When I walk into a new client engagement, I am not thinking about data sources or pipeline architecture. I am trying to figure out three things the client does not know I am assessing.
The First Conversation Is Never About Data
When I walk into a new client engagement, I ask them to walk me through their process.
Not their data. Their process.
How does a transaction flow through the business? How do they track performance today? What does the Monday morning meeting look like, and who is in the room?
This surprises people. They expect me to ask about data sources, system access, or reporting requirements. Instead I want to understand how the business actually works before I touch a single table.
There is a reason for that. And it has nothing to do with being thorough.
What I Am Actually Trying to Figure Out
Underneath those early questions, I am assessing three things. The client does not realise I am doing this, but the answers determine almost everything about how the engagement will go.
First: where are decisions being made on gut feel versus actual data?
Most organisations think they are more data-driven than they are. Someone will say "we track everything" and then you start pulling on threads and find out the revenue number comes from a spreadsheet one person maintains manually, the spreadsheet has not been audited in two years, and three different people have slightly different versions of it saved locally.
That gap between what they think is data-driven and what actually is, that is where the real work lives. If you do not find it early, you will build something that solves the wrong problem.
Second: who is the real decision maker, versus who they told me is the decision maker?
The person who booked the engagement is not always the person the work needs to serve. Sometimes the CEO says they want a dashboard, but the person who actually needs it is the operations manager who is drowning in manual reporting every week. Sometimes the data request came from the finance team but the person who will kill the project if they do not like it is in a completely different department.
If I build for the wrong person, the work does not get used. It is that simple. I have seen good data work sit untouched because it landed in the wrong hands.
Third: what is their tolerance for being told uncomfortable things?
This one matters more than most people in data are willing to admit.
Some clients genuinely want insights even when the numbers are bad. They want to know if a product line is underperforming, if a team is not hitting targets, if a decision they made six months ago turned out to be wrong. These engagements are the best ones because the data is actually allowed to do its job.
Other clients want a dashboard that confirms what they already believe. They have a narrative in their heads and they want the data to support it. When the numbers tell a different story, the response is to question the data rather than the narrative.
I need to know which one I am dealing with, early. Because it changes how I frame findings, how I present numbers that do not look good, and how much political care I need to build into the delivery.
I learned this the hard way. Early in my career I presented analysis that contradicted what the leadership team wanted to hear. I presented it clearly, accurately, and without enough care for how it would land. The numbers were right. The delivery was wrong. It taught me that being technically correct is not enough. You have to understand the room.
Why This Matters for the Data Work
Once I understand those three things, the actual technical decisions become much clearer.
What data sources are worth connecting? Depends on where the real decisions are being made, not where they are supposed to be made.
What metrics should we define first? Depends on who the real decision maker is and what they actually care about.
How should I present findings that might be uncomfortable? Depends entirely on the tolerance conversation I had in week one.
The technical part of analytics work is genuinely the easier part. Most experienced analytics engineers can model data, write clean SQL, build a dbt pipeline, and ship a dashboard. The skill that separates good work from great work is understanding the business and the people well enough that the output actually changes something.
A dashboard that confirms what someone already believed has zero value. A dashboard that changes a decision, even a small one, is worth everything.
That starts with the first conversation. And the first conversation is never about data.
Newsletter
Enjoyed this?
I write occasionally about data, AI, and building things that actually work. No noise, just signal.
Questions or thoughts? nithinprasad93@gmail.com