Data Scientists, You Need To Talk To People (Here’s Why)
Your Job Isn't Just Building The Model.
You can't be an introvert in data science. I know, I know. You pictured this job as headphones on, notebook open, nobody talking to you for eight hours. That's not the job. E-commerce runs on data more than almost any other industry, with every click, every cart, every abandoned checkout logged and measured.
Somewhere behind every one of those numbers is a room full of people who each think they get to decide what "success" means, and they don't agree with each other. Marketing wants click-through. Finance wants margin. Merchandising wants something that makes sense. All of them are looking at the same model. That's not a modeling problem. You can't train your way out of it.
So before you get mad at me in the comments, I know you can be an introvert and still do these things, so yes, Data Science isn't completely incompatible with introversion. But if you're that person who only wants to be headphones on coding and you don't invest in this skill? They're you're gonna have a bad time.
I had to learn this the hard way-across three separate projects, three separate lessons and once you’ve been through all three, you start spotting the pattern everywhere. The first one hit me two weeks after launch, in a meeting I was nowhere near prepared for.
The default you pick without realising you're picking one
First job, first real e-commerce project: build a recommendation engine. The brief was simple. Predict what customers are likely to click. So that's what I optimized for. 94% accuracy. The CEO loved it. Stakeholders signed off.
Two weeks later, it got pulled from production.
Here's what happened. Predicting what someone's likely to click is mostly predicting what they were going to buy anyway. Customer’s looking at running shoes, you recommend socks. Technically correct, also useless. A month in, someone in that meeting asked the only question that actually mattered to the business: had the average order value moved at all. It hadn't.
Nobody had ever told me AOV was the real goal. I'd picked "predict the click" because it was the easiest thing to train a model on and not because anyone had agreed that it was a success. I'd made a decision about whose definition counted, without realizing I was making a decision at all.
Lesson one, and it shows up everywhere in e-commerce, not just recommendations: you default to whichever number is easiest to measure, and quietly call it the obvious one.
image showing an example of a cost per click graph
When two stakeholders both think their definition is the obvious one
Different project, same kind of company. A churn model that flags customers likely to cancel. Retention's whole job is keeping customers, so to them, success is obvious: did the flagged customer stay or go. Lower the cancellation number, you've won.
Finance looks at the exact same model and sees something else. Every customer the model flags gets a retention offer like a discount code, a free month, something with a real line-item cost. So finance's question isn't "did they stay." It's "how much did we spend saving customers who were never going to leave in the first place."
Both teams are right. Both definitions are reasonable for an e-commerce business to care about. And they actively pull against each other and the model that makes retention happiest, by flagging as many possible churners as it can catch, is the same model that makes finance furious, because it's also handing out discounts to a pile of loyal customers who didn't need one.
There was no model fix waiting to solve this. The actual work was getting retention and finance in the same room and asking, out loud, which kind of mistake the business would rather make. Lesson two: it's not that nobody has a definition, it's that two teams have different ones, and both think theirs is the only sensible one.
Image of a finance view, showing retention costs, offers sent for a company
When the definition changes after you've already started
Third scenario. A model gets built against a clear, agreed target. Say, a specific growth KPI the company set at the start of the quarter for the online store. Everyone signs off. Work begins.
Halfway through the quarter, priorities shift. Margin gets squeezed somewhere else in the business, and leadership pivots from "grow orders" to "protect profitability." Nobody tells the data scientist. Why would they? From where leadership sits, this is a strategy update, not a data science update.
Weeks later, the finished model lands on someone's desk, built perfectly against a target nobody's been measured on for a month. It's not wrong. It's not even late. It's just answering a question the business stopped asking.
This one stings more than the others because there's nothing you could have caught upfront. The definition was real, agreed-on, correct, and then it just expired, the way targets quietly do in a fast-moving retail business. Lesson three: the definition of success has a shelf life, and nobody's job is to tell you when it's gone bad.
Image showing profit and loss percentages
The First Model You Build Isn't the One That Matters
Three different e-commerce situations. Three different reasons the definition of success wasn't settled before the work started. None of them were solved by a better model. All three were solved ,or at least made survivable, the same way.
So here's what that actually looks like in practice.
Before you build anything: ask, directly, "what does success look like, and to whom." Not as a formality and as the actual first task. If you get two different answers from two different people, that's not a side conversation to have later, that's the most important finding of the project, and it needs to surface before any code gets written.
When you get a vague answer, or no answer, treat that as information too. Silence usually means nobody's been assigned ownership of the decision which means you either need to escalate and ask who has it, or, carefully, propose a definition yourself and get it confirmed in writing, so it's a shared decision rather than something you quietly chose alone, the way I did with that first recommendation model.
And build in a check-in, even an informal one, partway through longer projects, specifically to ask "is this still the goal." Not because you did anything wrong, but because in a business that moves as fast as e-commerce does, goals shift, and the only person who finds out after the work is finished is usually you.
None of this is on a syllabus anywhere. It's also the actual day-to-day skill that determines whether your work gets used, or quietly shelved, regardless of how good the model underneath it is.
Image of a checklist
The Skill Nobody Teaches Data Scientists
Every one of these three situations looked, from the outside, like a data problem. A model that didn't move the right number, two teams disagreeing, a target that quietly went stale, a decision nobody owned. None of them were fixed by a modeling skill. All three were fixed, or avoided, by the same thing: figuring out, early and explicitly, whose definition of success actually counted here.
That's not a side skill you pick up eventually. For most of the actual job, it's closer to the main skill and the model is just the thing you end up building once that question's been answered.
If you've ever finished something you were proud of and watched it get quietly ignored, it's worth asking, before you blame the model, whether anyone had actually agreed on what "success" meant in the first place.
The best models in the world don't matter if they solve the wrong problem. Before you build, before you measure, before you optimise make sure everyone agrees on what winning actually looks like.
That's where better decisions start.
Our closed beta is now Live. Sign up via the link below and keep being Evil