Every data science course I've taken started with a clean dataset.
Titanic. Iris. House prices. Carefully curated, well-documented, free of ambiguity. The kind of data that exists nowhere in the real world except in academic archives specifically designed to teach algorithms on. I learned a lot from those datasets. I learned nothing from them about why data work actually fails in practice.
That education came from a different direction entirely: sitting inside a sales and marketing operation, watching how decisions actually get made, and slowly realizing that the gap between "we have data" and "we act on data" is not a technical problem. It's a human one.
What I Actually Do
My role on the technical side of Sales & Marketing sits at the intersection of two worlds that rarely talk to each other clearly. On one side: salespeople who know their customers, trust their instincts, and move fast. On the other: data - pipeline reports, conversion rates, lead quality scores, customer behavior patterns - that either confirms what they already believe or challenges it.
My job is to make the data legible. Not to prove a point. Not to win an argument. To put a number in front of someone making a decision and make sure they understand what it means and what to do with it.
That sounds straightforward. It is the hardest problem I've encountered in any technical work I've done.
The First Thing Sales Taught Me: Data Without Context Is Noise
Early on, I ran an analysis on our sales pipeline and surfaced what looked like a clean insight: leads from one particular channel were closing at nearly double the rate of leads from every other source. The numbers were clear. The implication seemed obvious - shift budget toward that channel, pull back from the others.
I presented the finding. A senior salesperson looked at it for about thirty seconds and said: "Those leads are referrals. Of course they close better. You can't buy more referrals by spending more money."
He was right. The number was accurate. The interpretation was wrong. The channel looked like a scalable source because it had a high close rate, but the close rate was high precisely because it wasn't a channel in the traditional sense - it was word-of-mouth, driven by relationship quality, not marketing spend. Doubling down on it would have done nothing.
I had the data. I didn't have the context. And without the context, the data led somewhere actively wrong.
This is the lesson that no dataset teaches you: numbers inherit the assumptions of the system that generated them. A close rate doesn't tell you why those deals closed. A churn rate doesn't tell you what those customers actually wanted. A conversion percentage doesn't tell you what would have happened if you'd tried something different. The number is the outcome of a process, and understanding the number requires understanding the process - which lives in the heads of the people closest to it, not in the spreadsheet.
The Second Thing: Most Dashboards Are Built for the Person Who Built Them
I spent time building sales reports and dashboards - tracking pipeline health, stage progression, deal velocity, forecasted revenue. I built them the way a data-oriented person builds things: comprehensive, accurate, with as much information as I could surface.
Nobody used them the way I expected.
Salespeople would open a dashboard, look at their number, and close it. The nuance I'd built in - the trend lines, the cohort comparisons, the leading indicators - went unread. Not because the salespeople were unsophisticated. Because they were busy, operating on instinct honed from hundreds of customer conversations, and the dashboards were designed to answer questions they weren't asking.
This forced me to rebuild from a different starting point. Not "what data do I have?" but "what decision does this person need to make in the next 24 hours, and what single number would change how they make it?"
The dashboard that got used was half the size of the original. It had one metric per role, updated daily, with a simple directional indicator - up, down, flat - and a single line of context explaining the change. It took less time to build and more time to think through. The thinking was about the people reading it, not the data going into it.
The insight this produced: most data work fails not because the analysis is wrong but because it's delivered in a format that doesn't connect to how the recipient makes decisions. A correct finding that sits unread in a dashboard has no business value. A slightly less precise finding that changes tomorrow's call strategy is worth infinitely more.
The Third Thing: The Most Important Data Is the Data Nobody Thought to Collect
In every structured data system I've worked with, there's a version of the same problem: the CRM tracks what happened, not why it happened. Deal closed: recorded. Deal lost: recorded. Why the deal was lost - the actual reason, the conversation that went wrong, the competitor that came in lower, the decision-maker who changed at the client - that lives in a salesperson's memory, in a call recording nobody listened to, in a follow-up email that was never tagged.
The most valuable data in a sales operation is unstructured, qualitative, and systematically ignored by every BI tool designed to work with it.
This is where I started spending more attention - not on the structured pipeline data, which was well-tracked, but on the patterns in the unstructured signals. What language did customers use when they were about to churn? What early indicators appeared in discovery calls with deals that went on to close quickly versus deals that stalled? What did customers say they wanted that was different from what they ended up buying?
Pulling signal from that kind of data is harder than running a conversion funnel. It doesn't fit neatly into a dataframe. But it's where the actual intelligence about customer behavior lives, and it's almost entirely untapped in most organizations.
What This Changes About How I Approach Data Work
I approach every data problem now with a question that I never asked before working in sales: Who has to act on this, and what does acting look like for them?
That question changes what you build. It changes what you measure. It changes how you present findings. A data product built for a CFO looks nothing like a data product built for a field sales rep, even if the underlying data is identical. The CFO needs trends and forecasts and variance analysis. The sales rep needs to know which deal to call first tomorrow morning.
Understanding the decision-maker before you open the data file is not a soft skill that sits adjacent to technical data work. It's part of the technical work. You can't build a useful model without knowing what "useful" means to the person who has to act on the output. You can't design a meaningful metric without knowing what decision it's supposed to inform.
Most data curricula teach you to answer questions. Sales taught me to figure out which questions are worth asking.
Why This Combination Is Rare and Why It Matters
There is a well-documented disconnect between data teams and the business functions they serve. Data people often complain that their work isn't used. Business people often complain that data people don't understand the business. Both complaints are usually valid, and both point to the same underlying gap: the two sides don't share enough context to communicate effectively.
The person who has sat on both sides of that gap - who has built the models and also watched how business decisions actually get made, who understands the data pipeline and also the decision pipeline - is unusually positioned to close it.
That's what the Sales & Marketing experience gave me. Not a line on a resume. A different way of seeing what data work is for.
The goal was never the model. The goal was always the decision.