Your First 30/60/90 Days as a New Data Scientist

It's 9:47am on day three. You've barely figured out which Slack channels matter. Your coffee is still hot. A message slides in from someone you met once during onboarding: "hey, can you take a look at the churn model? it's been off for a while."

Congratulations. You just inherited 18 months of someone else's decisions. Two prior owners, no documentation worth reading, a feature set that nobody fully understands, and a CFO who is six weeks into asking when "the AI investment" will pay back. The model hasn't been retrained since August. You haven't even gotten your laptop fully provisioned yet.

This is the actual day-three experience for most new data scientists in B2B SaaS, and the temptation is brutal: ship something fast, anything, to look like you're earning your seat. Don't. The first 90 days are when you set the narrative for whether leadership sees you as a revenue lever or as the next line item to cut when the board asks where headcount is bloated. And data science roles get cut faster than any other technical function when the business value story is fuzzy.

Here's a 90-day plan that doesn't require heroics, doesn't depend on you being a genius, and doesn't end with you owning someone else's broken churn model as your KPI.

Why Audit Beats Build (And Why Most New DS Hires Get This Wrong)

The single biggest mistake a new data scientist makes is shipping a new model in week two to look productive. It feels great. It also means you now own a thing you don't yet understand the business context for, you've signaled to stakeholders that "shipping models" is your value proposition (it isn't), and you've skipped the only window you'll ever have to ask dumb questions without judgment.

You get exactly one honeymoon period. Spend it listening, not building. The good news is that listening produces tangible artifacts (an audit memo, a stakeholder map, a data warehouse cheat sheet) that look just as productive to your manager as a half-baked model would, and they don't generate technical debt.

Days 1–30: Audit and Listen

The first 30 days have one goal: build a defensible map of what exists, what's broken, and what people actually want. No new models. No "quick experiments." No promises.

Inventory Every Model in Production

Make a spreadsheet. One row per model that runs anywhere: production, scheduled notebook, that thing in Airflow nobody admits is a model. For each one, fill in three columns:

Performance vs. claimed performance. What does the model card or last quarterly review say it does (AUC, precision at top decile, MAPE, whatever)? What does it actually do on the last 90 days of data? You will find at least one model where the gap is embarrassing. The churn model is usually the worst offender. Drift of 15-25% on key features is normal in B2B SaaS where customer mix shifts every quarter.
Fairness and drift. Is the input distribution still close to what the model was trained on? For tabular models, a quick Population Stability Index (PSI) check on the top five features usually tells you everything. PSI above 0.25 means the model is operating outside its training distribution and the predictions are noise dressed up as signal.
Actual business value. Who uses the output? What decision does it drive? What would happen if the model returned a constant value tomorrow? If the answer is "honestly, probably nothing," write that down. You'll need it later.

Three to five models is normal. Eight or more means somebody was building to look busy and you've inherited a graveyard.

Sit in Five Stakeholder Syncs

Not five conversations. Five recurring syncs you join as a silent observer for the first two or three meetings before you start contributing. Pick one each from:

Sales ops (forecast accuracy, pipeline coverage, lead scoring complaints)
Customer success (churn signals, expansion plays, NPS-to-revenue links)
Product (feature adoption, activation, what they're A/B testing badly)
Finance (revenue forecasting, unit economics, the CFO's actual model of the business)
Engineering / data platform (warehouse costs, pipeline reliability, what's on fire)

You're listening for two things: which decisions are being made on gut feel that could be made on data, and which decisions are being made on data that's actually wrong. The second one is more common than people admit. Sales ops running pipeline forecasts off a Salesforce report that double-counts renewals is a top-five greatest hit at most B2B SaaS companies.

Learn Where the Lies Live in the Warehouse

Every data warehouse has a layer of small, awful truths. Columns renamed three times. Soft-deleted rows that the BI tool quietly includes. Timezone bugs that make Mondays in Singapore show up as Sundays. A revenue_usd field that's pre-discount in one table and post-discount in the table next to it.

Spend a week with whoever owns the analytics layer. Bring a notebook. Ask them: "What do you wish people knew before they queried this table?" You'll get more value from that one question than from three weeks of reading dbt docs.

By day 30 you should have: an audit spreadsheet, notes from five stakeholder syncs, a one-page "data warehouse gotchas" doc, and zero new models in flight.

Days 31–60: Kill, Ship, Propose

Now you start producing visible work. Three deliverables, in this order.

Kill One Broken Model — Publicly, with a Memo

This sounds career-limiting. It's the opposite. Killing a broken model is the single highest-leverage thing you can do as a new DS, because:

It frees up compute, headcount attention, and stakeholder bandwidth.
It demonstrates that you have judgment, not just throughput.
It establishes that "ship a model" is not a virtue if the model is wrong.

Pick the worst offender from your audit. The classic candidate is the churn model that's been retrained twice in 18 months, has 22% feature drift, drives no actual retention play (CS reps ignore the score), and costs $400/month in compute. Write a one-page memo: what the model claimed, what it actually did, what it cost, what decision it was supposed to drive, what you propose to replace it with (often: "a simple cohort report, refreshed weekly").

Ship the memo to your manager and the original stakeholder. Let them respond. Nine times out of ten they'll say "yeah, we stopped looking at it months ago." Now it's gone with a paper trail, and you've shown leadership that you'll cut your own work when the work isn't earning its keep.

A short template that works:

Memo: Retiring the [model name] model
Author: [you]
Date: [date]

What it does today: [one sentence]
What it claimed when launched: [metric and value]
What it actually does on the last 90 days: [metric and value]
Compute cost: [$/month]
Decisions it drives: [list — be honest if the answer is "none"]
Recommendation: Retire by [date]. Replace with [simpler thing or nothing].
Risk if we don't retire: [continued maintenance + false-confidence in stale predictions]

That's it. One page. No appendices.

Ship One Quick-Win Analysis a Stakeholder Actually Asked For

Go back to your stakeholder sync notes. Find the smallest, most concrete request, the one the person mentioned in passing, with a clear decision attached. Not "we should use AI for X." Something like: "I wish I knew which onboarding step is causing the most drop-off in the first 14 days."

Do that one. Slack-friendly write-up. Three charts maximum. Recommendation in the first paragraph. Loop in the person who asked, plus their manager. You're not trying to win a Kaggle competition. You're proving you can convert a real question into a real answer in under ten working days.

Propose a 6-Month ML Roadmap Tied to 2-3 Business Metrics

By day 60 you should have enough context to draft a roadmap. Two to three business metrics, max. For each one, a 1-2 sentence hypothesis, a model or analysis approach, an effort estimate (small / medium / large), and most importantly, a kill criterion (what would make you stop work on this).

Kill criteria are what separates a roadmap from a wishlist. "If by week 8 the baseline lift is under 5%, we stop and reallocate" is a roadmap line. "Build a churn model" is not.

Share the roadmap with the exec who hired you. Get pushback. Revise. The goal is for them to be able to describe your next two quarters in one sentence to anyone in the C-suite.

Days 61–90: Own One Metric, Present, and Plan H2

The final 30 days are about transitioning from "the new DS" to "the person who owns X."

Own One Business Metric Tied to a Model

Critical phrasing here: you own the metric, not the model. If you own "the churn model," you've inherited someone else's identity and you'll be judged on a thing you didn't design. If you own "12-month logo retention in the SMB segment," you can use whatever combination of model, analysis, and operational change moves the number.

Pick one. Just one. It should be:

A metric finance and the exec team already track (don't invent a new one)
Within your sphere of influence (a model touches it, but so does CS workflow, pricing, and product)
Measurable in 60-90 day windows, not 12 months

Common good picks for a new DS in B2B SaaS: SMB churn rate, lead-to-opp conversion, free-trial-to-paid conversion, expansion revenue per CSM. Common bad picks: total revenue (too many inputs, you'll never get credit), NPS (too noisy), "model accuracy" (not a business metric).

Present a 90-Day Report to the Exec Who Hired You

15-minute meeting. Five-slide deck. The structure that works:

What I found. The audit, in one chart (models retired, models healthy, models on watch).
What I shipped. The quick-win analysis, the kill memo, the metric I now own.
What I learned about the business. The two or three things that surprised you (data quality issues, decisions that aren't being made on data, requests that keep coming up).
The roadmap. Your 6-month plan, with kill criteria.
What I need. Headcount, infra, stakeholder access, decisions.

Slide five is the most important and the most often skipped. If you can't articulate what you need to be successful in the next 90 days, the exec will assume you don't need anything, and then they'll wonder in month six why progress stalled.

Propose an H2 ML Plan with Headcount, Infra, and Kill Criteria

This is the roadmap from day 60, now sharpened with three months of context. Three things go in the H2 plan that weren't in the original roadmap:

Headcount math. "To execute this plan I need X engineering days and Y data engineering days per quarter. Today I have Z. Here's the gap." Be specific. ML engineers are expensive. Data engineering capacity is the bottleneck on 60% of DS work in most B2B SaaS shops, and saying that out loud early protects you from being blamed for delivery problems that aren't yours.
Infra needs. Feature store? Experiment tracking? A managed inference platform? List them with rough costs. The CFO would rather see a $30K/year line item now than a $30K/year surprise in Q3.
Kill criteria, refreshed. Six months of work always reveals which bets were wrong. Codify when you'll stop, not just when you'll start.

The Conversation Where the CFO Asks About ROI

This conversation is coming. Probably in week 5 or 6. It usually sounds like: "So when do we start seeing returns on the AI investment?"

The wrong answers: "It's a long-term investment." "AI takes time." "We're still in the experimentation phase." All of these are true. None of them work. The CFO is asking a legitimate question and deserves a legitimate answer.

The answer that works:

"Right now I'm in audit mode. I've found two models that are costing us about $X/month and driving no decisions, and I'm retiring those by end of month. By day 90 I'll own the SMB churn metric and have a roadmap with two or three bets, each tied to a business metric you already track, each with a kill criterion. The honest answer to 'when do we see returns' is: by end of Q3 if I'm right, and we'll know early enough to redirect if I'm wrong."

That's the framing. Concrete near-term actions, one metric you'll own, a date, and a plan to fail fast if the bets don't pan out. CFOs respond well to kill criteria because they've never heard a data scientist mention them before.

Common Pitfalls That Will Quietly Sink the First 90 Days

A few traps that catch even experienced DS hires:

Building in week two to "look productive." You will inherit blame for that model forever. Resist.
Saying yes to "an AI" requests without scoping the actual decision. When a VP says "can we use AI for [vague thing]?", the right answer is "what decision would you make differently with the output?" If they can't answer, the project doesn't exist yet. Don't volunteer to build it anyway. (Scoping vague AI requests goes deeper here.)
Inheriting the broken churn model as your KPI. The model is a tool. Retention is the metric. Own the metric.
Ignoring the data engineering tax. 60% of your time in the first year will go to data plumbing: fixing pipelines, debugging joins, validating that the warehouse number matches the BI tool number. Budget for it. Don't pretend it'll be 20%.

Measuring Success at Day 90

The honest test of a successful first 90 days is not "did you ship a model." It's:

You can name the top three business metrics and which models touch each one
One broken model is dead, with a paper trail
One quick-win analysis shipped and got credit from the requester
You own one metric, not five
The exec who hired you can describe your roadmap in one sentence

If those five things are true on day 91, you're set up for a strong year. The data scientists who burn out by month nine almost always built a new model in month one and spent the next eight months defending it.

Data Scientist Playbooks