The first question the retention lead asked me was not about accuracy. It was: who does something differently on Monday because of this? I had spent five weeks on a churn model and I did not have a good answer. That model was quietly switched off about two months later.

That question is the closest thing to a real definition of the job I have found. A data scientist is not the person who builds the most accurate model. A data scientist is the person who turns an uncertain business question into a decision somebody can act on, using data, and who can say honestly how much to trust the answer. Everything else in this series is in service of that.

Daily work of a data scientist

Strip away the tooling and a data scientist does four things in a loop. You take a vague business question and turn it into something measurable. You find and interrogate the data that might answer it. You build an estimate, usually a model, meaning a mathematical rule fitted to past data that produces a number for a case it has not seen. Then you communicate the answer together with its uncertainty, and you argue for a decision.

The second and fourth steps take most of the calendar. Every experienced practitioner I know says some version of the same thing: the modelling is the short part. Finding out that the customer table has three different definitions of active, or that the sales team stopped logging a field in March, is the long part. Published duty lists back this up. Bureau of Labor Statistics guidance describes the role as determining which data are available and useful, collecting and categorising it, creating and validating algorithms and models, and making business recommendations to stakeholders. Two of those five are about the data rather than the maths, and one is about persuasion.

Here is the distinction that matters most and gets missed most often. An analyst is usually asked a question that has a correct answer sitting in the data: how many customers cancelled last quarter, and which plan did they come from. A data scientist is usually asked a question where no correct answer exists yet, only an estimate with error bars: which customers will cancel next quarter, and are we confident enough to spend money on stopping them. Once your output becomes a probability rather than a count, the job changes. You now have to defend a number that could be wrong, which is a different professional skill from reporting a number that is simply true.

Four roles that keep getting confused

Job adverts blur these constantly, and on a small team one person genuinely wears two or three of the hats. That does not make the distinction useless. It makes it more important, because if you cannot tell which part of the work you are being hired for, you will prepare for the wrong interview and be unhappy in the job you get.

Think of the four roles as sitting on a line that runs from explaining the past to shipping something that runs by itself. Analysts sit at one end, machine learning engineers near the other, the research scientist off to the side inventing the methods everyone else uses.

A working sketch, not a rulebook. Titles vary by company, and the boundaries move.

What the labour numbers actually show

Career advice about data science tends to arrive either as hype or as a claim that the field is finished. Published statistics are more useful than either. The U.S. Bureau of Labor Statistics tracks data scientists as occupation code 15-2051, and the figures below are from its most recent Occupational Outlook Handbook entry, last modified in August 2025.

Source: U.S. Bureau of Labor Statistics, Occupational Outlook Handbook, Data Scientists. Figures are United States only.

Two things in that table deserve more attention than the headline. Start with the spread. A gap of about 131,000 dollars separates the tenth percentile from the ninetieth, which is enormous for a single occupation code. Data science is not one job with one salary band, it is a family of jobs whose value depends heavily on the industry and on whether your work reaches production. Second comes the entry requirement: a bachelor degree is listed as typical, with some employers preferring a master or doctorate. A PhD is common in the field but it is not the gate people assume it is.

How one question moves through a team

Role definitions become concrete when you follow a single request. Take the one this series will build on for the next twenty nine parts: too many subscribers are cancelling, can we predict who and do something about it. Watch where it goes.

flowchart TD
  Q[Too many subscribers cancel] --> F{Is the question measurable}
  F -->|No| R[Data scientist reframes it]
  R --> F
  F -->|Yes| D{Is usable data available}
  D -->|No| DE[Data engineer builds the pipeline]
  DE --> D
  D -->|Yes| A[Analyst sizes the problem]
  A --> M[Data scientist fits and validates a model]
  M --> V{Does it beat the current rule}
  V -->|No| R
  V -->|Yes| E[ML engineer deploys and monitors]
  E --> B[Retention team acts on scores]

The step people skip is the analyst step in the middle. Before anyone fits a model, somebody should establish how many customers actually cancel, what the current process already catches, and what a saved customer is worth. That is exactly the work covered in exploratory data analysis, and skipping it is how teams end up with an accurate model that beats nothing. If the business already has a rule that flags cancellations reasonably well, your model has to beat that rule, not beat random guessing.

Notice also that the diagram loops back to reframing twice. That is honest. A first attempt that fails validation usually means the question was wrong, not that the algorithm was wrong. Beginners reach for a fancier model when validation disappoints. Experienced practitioners go back to the question and the features.

Parts of the job that tutorials skip

Online courses optimise for the satisfying part: a clean dataset, a model, an accuracy score. Working practice has three components that almost never appear in a course, and they decide whether you are any good.

The first is problem framing. Somebody says improve retention. You have to convert that into a target you can measure, a population you can define, a time window, and a threshold for action. Get this wrong and every downstream step is wasted, no matter how careful the maths. Part 3 of my analyst series on thinking in data is the best preparation for this, and it applies unchanged here.

The second is scepticism about your own results. A model that looks excellent on the first try is usually broken. Something in your input data is carrying information it would not have at prediction time, which is called leakage, and it is the single most common way a data science project fails silently. We spend a whole part on it later, because it deserves one. Third comes communication, which is not a soft extra. If the retention lead does not understand what a probability of 0.8 means for her budget, your model does not exist as far as the business is concerned.

Where a beginner should actually start

If you are starting cold, the sequence that works is not the sequence the field advertises. Most roadmaps put neural networks first, because that is what sounds like the future. What actually gets people hired is this order: get fluent with data manipulation, then statistics, then a small number of well understood models, then production skills.

There is a practical reason for that order beyond the pedagogy. In an interview you will be asked to explain a decision you made on a messy dataset far more often than you will be asked to derive backpropagation. A candidate who can say clearly why they chose recall over precision for a fraud problem, and what that cost the business, reads as employable. A candidate who can name six architectures but cannot explain why their validation score was optimistic does not.

This series follows that order deliberately. Phase one covers the working setup and data handling. Phase two covers statistics and the core models, which is where most of the employable skill sits. Phase three moves into deep learning and the specialised areas. Phase four is production and MLOps, meaning the practices for running models reliably over time. Phase five is architect level: designing the platform, controlling the cost, and owning the risk. You do not need the later phases to get a first job, but you do need them to stop being junior.

Generative AI and what it has not changed

This is the question I get most often now, so let me answer it directly rather than hedge. Language models already handle the parts that were never the hard parts. It can write the boilerplate to load a file, remind you of the syntax for a join, produce a first pass at a chart, and draft the skeleton of a training script. If your value was typing those things from memory, that value has fallen.

What has not moved is judgement about context that lives outside the data. A model cannot know that your company changed its definition of an active user in March, that the marketing team ran an unlogged promotion in one region, or that the cost of a false positive in your fraud system is a furious customer rather than a rounding error. Those facts decide whether an analysis is right or worthless, and they live in conversations, not in tables.

There is a second effect that gets less attention. Generative tools have made it much cheaper to produce something that looks like a finished analysis. That raises the value of being able to check one. A colleague hands you a notebook with a 0.93 score and a confident summary. Can you find the leak in it? That skill is scarcer than it was two years ago, not more common, because fewer people now build the intuition the slow way.

My working view: use these tools daily, and treat everything they produce as a draft from a fast colleague who has never seen your business and will not tell you when it is guessing. That is roughly the right mental model, and it is also how I would describe a talented intern. You would not ship an intern output unreviewed, and the same rule applies here.

Learn the analyst foundation first, then add the modelling

My recommendation for this part, stated plainly: do not begin with machine learning. Begin by being able to pull, clean and describe a dataset without help, and by being able to explain what you found to somebody who does not care about your tools. If you can already do that, you are ready for the modelling work and it will come quickly. If you cannot, machine learning will paper over the gap for a while and then fail you in an interview or, worse, in production.

Concretely, that means SQL you can write without looking things up, comfort with a dataframe, and enough statistics to know when a difference is real. Those are covered in the Data Analyst Series, particularly pandas essentials and the statistics an analyst actually uses. This series assumes them from Part 3 onward.

Part 2 takes the loop sketched in the flowchart above and walks it end to end as a lifecycle, from the first conversation with a stakeholder through to the day a model gets retired. That lifecycle is the map for the rest of the thirty parts, and it is worth reading before you write any code.

References

• Data Scientists, Occupational Outlook Handbook, U.S. Bureau of Labor Statistics
• Computer and Information Research Scientists, Occupational Outlook Handbook, U.S. Bureau of Labor Statistics
• Data Scientists 15-2051.00, O*NET OnLine

About The Author

Dr. Pranay Jha

Dr. Pranay Jha is a Cloud and AI Consultant with 18+ years of experience in hybrid cloud, virtualization, and enterprise infrastructure transformation. He specializes in VMware technologies, multi-cloud strategy, and Generative AI solutions. He holds a PhD in Computer Applications with research focused on Cloud and AI, has published multiple research papers, and has been a VMware vExpert since 2016 and a VMUG Community Leader.

See author's posts