The Data Science Workflow

Real data science work follows a loop, not a straight line: ask a question, get the data, clean it, explore it, maybe model it, then explain what you found — and often loop back to an earlier step once you learn something new.

Ask a question worth asking

Every project starts with a question specific enough to be answerable: not "how's the business doing?" but "did the March pricing change reduce signups, and if so, for which customer segment?" A vague question produces a vague, unusable answer no matter how good the analysis afterward is.

Collect the data

Pull together whatever data actually bears on the question — a database export, an API, a spreadsheet someone's been keeping by hand. It's common to realize partway through that the data you have can't actually answer the question you asked, which sends you back to the first step with a sharper question.

Clean it

Real-world data is never ready to use as-is: missing values, duplicate records, dates stored three different ways across three different sources. This step is covered in depth in the next lesson, and it's usually the single most time-consuming part of the whole process.

Explore it

Before building anything, look at the data directly — summary statistics, distributions, obvious outliers. This is where you catch the "wait, why does this column have a maximum age of 999?" problems before they quietly corrupt everything downstream.

Model it (sometimes)

Not every question needs a machine learning model — plenty are fully answered by a well-chosen chart and some careful statistics. When a model genuinely is the right tool, it comes after exploration, never before it.

Communicate the result

An analysis nobody understands or acts on didn't accomplish anything. The final step is translating whatever you found back into the original question, in language the person who asked it can actually use.

It's a loop, not a line: exploring the data often reveals that your original question needs refining, or that you're missing a crucial piece of data — sending you back a step or two. Treating this as a strict one-way pipeline is one of the most common ways real projects go wrong.