Data Scientist

When a company has exactly one person handling data, almost every question that reaches them is about the past. How many people signed up last month, which plan sold best, how many support tickets came in on Tuesday. All of those are answered by counting rows that already exist.

The approach stops working the moment a question points forward. In a Pagedeck meeting, Grace asked whether the company could tell in advance which teams were likely to cancel next quarter, and nobody could answer. There was a list of accounts that had already churned, but those people were gone. Which of the remaining accounts were at risk was not a number anyone could look up. Someone suggested that teams logging in less often were probably the risky ones, but plenty of quiet teams kept paying every month, so picking by that rule put about half the list in the wrong bucket.

The data scientist role exists to fill that gap. Instead of counting, it estimates. You take two years of accounts that churned and accounts that stayed, lay their records side by side, and look for the signals that showed up before people left. Rather than a human proposing one rule at a time, thirty or so recorded behaviors get compared at once, and the numbers say which combination actually separated the two groups.

Most days start by rewriting the question that came in so that it can be calculated at all. The work runs through five steps.

1. Turn the question into a prediction problem. "Teams that look like they might cancel" doesn't compute, so it becomes something like "the probability this account ends its subscription within the next 90 days," with the event and the window both pinned down. Choosing 30 days instead of 90 changes everything that follows.
2. Gather the raw material. Usually that means pulling the account-level table an analytics engineer has already assembled, and building whatever columns are missing. This is where you line up dozens of values that describe a single account: last login date, documents created last month, teammates invited, tickets filed.
3. Clean the values. Decide what to do with rows that have blanks, and drop rows with too little history to judge — an account that signed up yesterday has nothing to learn from. This step takes more hours than most people outside the role expect.
4. Build a model and measure how often it's right. Machine learning finds the rules from past records, but the period used for training and the period used for scoring have to stay separate: learn from 2024, then grade against what actually happened in the first half of 2025. If 68 of the 100 accounts flagged as at risk really did leave, that 68 percent is the model's score.
5. Hand the result over in a usable shape. Sometimes that's a weekly file of at-risk accounts. If the score needs to appear inside the product itself, it goes to an ML engineer who puts it into the service.

Prediction isn't the whole job. Close to half the time goes to explanation: deciding whether this month's rise in cancellations is a real shift or the usual month-to-month noise, or whether a 1.4 percent gap from an experiment is large enough to call a difference at all.

The role sits in the middle of a chain, with two positions feeding it and several taking its output.

Upstream are the people who supply the material. A data engineer builds the paths that carry scattered records into one place, and the analytics engineer turns those records into tidy account-level tables. When either position is missing, the first few weeks of any project get spent hunting down data instead of modeling it.

Alongside sits the data analyst. They look at the same tables but answer a different kind of question. The analyst answers where churn rose last quarter; the scientist asks what pushed it up in that segment and how confident anyone can be about the answer.

Downstream are the people who act on the output. Mia reads the at-risk list and decides which in-product message to show and when. Sofia takes the same list and picks which accounts to call first. What gets handed over is never just a probability — it has to include why an account scored the way it did. Without a reason, Sofia has no idea what to say when someone picks up the phone.

"That's a correlation, so I wouldn't call it the cause yet. We'd need an experiment to confirm it."

The two numbers moved together, but nothing so far shows one caused the other.

"The model is right about 68 percent of the time, so rather than acting on the whole list, start with the top 100 accounts."

The performance has limits, so narrow the scope where it gets used.

"With a sample of 180, this gap could be noise. Let's collect two more weeks."

There's a visible difference, but not enough data to treat it as a conclusion.

At Pagedeck the role shows up in quarterly planning. When Mia says she wants to know why paid conversion dropped last quarter, the first move is to split the question: did the conversion rate itself fall, or did the mix of incoming traffic change? If the answer turns out to be that paid-ad signups doubled while that channel has always converted at a third the usual rate, then the next task isn't redesigning the upgrade screen — it's a conversation with Ravi about where the ad budget is going.

The output of this role rarely makes the decision. It narrows the set of options worth considering.

The most common misreading is that the job is building models all day. The title sounds like a lab, and the public examples are nearly all about models, so the impression is understandable. In practice most of the hours go into the steps before modeling: finding usable data, handling missing values, reconciling two tables that define a user differently. Hire without knowing this and the new person spends their first month discovering there's no usable data, while the team that hired them wonders why nothing has shipped.

The second misreading is that a prediction hands you a decision. A probability looks like an answer, which makes the assumption easy to fall into. But "72 percent chance this account leaves" says nothing about what to do. Whether to offer a discount, assign a success manager, or leave it alone depends on cost and staffing, and those belong to the people who know both. Skip that distinction and discount codes go out automatically to everyone the model flags, including accounts that were never going to leave, which trims revenue for no reason.