Your First 30/60/90 Days as a New Business Analyst

Day 3. You're still figuring out which Slack channels matter when DM number 14 lands: "quick pull, can you grab MRR by segment by EOD?" You haven't even gotten Looker access yet. Your laptop has been live for 19 hours.

You open the wiki. The previous BA left 47 dashboards. Twelve of them are broken. The remaining 35 have names like revenue_FINAL_v3_use_this_one. Three teams (Finance, RevOps, the CEO's chief of staff) each tell you, in confidence, that their revenue number is the real one. Two of those numbers don't even agree to within 8%.

This is the job. Not the job description, the actual job. And if you're not careful, the next 90 days will go exactly the same way the last BA's did: drowning in ad-hoc requests, never shipping anything of your own, and quietly burning out around month four.

Most BAs lose their first quarter to the Slack queue. This is how you don't.

Why a 30/60/90 Matters Specifically for BAs

Engineers get a 30/60/90 because their work has clear boundaries: tickets, PRs, on-call rotations. PMs get one because their stakeholders have stand-ups. BAs often skip it, because the work feels like it doesn't have edges.

That's exactly the problem.

Without a written plan, you become a SQL vending machine. Someone DMs a question, you write a query, paste the answer, move on. Repeat 80 times a week. At day 90 your manager asks what you've shipped and you say, "I closed 312 ad-hoc requests." That's not a thing of your own. That's a Jira queue with a heartbeat.

The job is insight, not pulls. The 30/60/90 is how you buy back the time to do the actual job. It's a contract you write with yourself (and quietly with your manager) that says: for the first month I'm not promising deliverables. For the second I'm shipping one thing that compounds. For the third I'm owning a metric.

If you can't get your manager to sign off on that arc, that's information too. It tells you the role is "ticket-closer," not "analyst," and you should renegotiate or update your résumé before month two.

Days 1-30: Audit & Learn (Don't Ship, Don't Promise)

The first month has one rule: no new dashboards, no new reports, no commitments past "I'll get back to you Tuesday." You're in receive mode.

Inventory every dashboard, report, and recurring extract

Open Looker (or Tableau, or Mode, or whatever your team uses). Export the full asset list. Tag each one in a spreadsheet:

A typical mid-size SaaS company has somewhere between 40 and 200 BI assets, and 30-50% will land in stale or broken. That's not laziness from your predecessor. That's just what happens when nobody is paid to maintain a BI estate.

Draft the kill list (don't send it yet)

By day 21, you should have a written list of 15-25 dashboards to deprecate. Don't send the memo on day 21. Sit on it. You don't have credibility to delete things yet, and a kill memo from a 3-week-old hire reads as either reckless or naive.

Save the draft. You'll send it day 35, after you've shipped one thing and built some standing.

Schema deep-dive

Find the data engineering team. Buy them coffee. Ask them to walk you through:

• The 5-7 core tables that 80% of analytics queries touch (usually users, accounts, subscriptions, events, opportunities, plus 1-2 domain-specific ones)
• Where the dbt models live, who owns each, and which ones are actively maintained vs. abandoned
• Every revenue definition variant in the warehouse (we'll come back to this; it's bad)
• The "do not query directly" tables (raw event firehoses, tables locked for compliance, anything that pages the on-call)

Take notes. Real notes, in a doc your future self can search. By day 30 you should be able to answer "where does ARR live?" without asking anyone.

1:1s with the top 5 ad-hoc requesters

Pull the last 90 days of requests from the previous BA's queue (Slack history, Jira, wherever they lived). Rank by volume. The top 5 requesters generated 60-70% of the load. Book 30 minutes with each.

The question is not "what reports do you want?" That gets you a wishlist of 14 dashboards. The question is: what decision are you actually making with this data?

You'll find that 3 of the top 5 requesters are using analytics to answer the same underlying question ("are we hitting the number?") with different framing. That's a consolidation opportunity. The other 2 are doing real, distinct work and deserve their own thing.

Set up a request intake

Even a Notion form beats DMs. The form needs three fields: what decision are you making, when do you need it, and what would "good enough" look like. That third field kills 40% of requests on the spot, because the requester realizes they don't actually know.

Tell people about the form gently in week 4. Don't enforce it yet. Day 31 is when it has teeth.

Days 31-60: Ship 1 High-Leverage Thing + Set the SLA

Month two is where you start getting paid. You've earned the right to make moves. Use it.

Pick ONE dashboard that replaces 5+ ad-hoc pulls

Look at your requester research. Find the dashboard-shaped hole in the world that, if filled, would silence the most DMs. For most B2B SaaS BAs in their first year, it's some version of:

• A unified pipeline + revenue dashboard with consistent definitions across Sales, CS, and Finance
• A churn-and-expansion view segmented by ICP
• A product-usage-to-revenue bridge for the PLG motion

Pick one. Ship it. Get one exec to use it in one meeting. That's the bar. Not "rolled out company-wide." Used, once, in a real decision context. If the CRO pulls it up in the Monday forecast call, you've won month two.

Publish the ad-hoc SLA

Send this in writing, to the channel, on day 35:

Ad-hoc analytics SLA

• Triage within 24h: I'll respond, scope it, and tell you if it's a 20-min pull, a 2-day project, or something we should build a dashboard for.
• 72h delivery for scoped pulls under 4 hours of work.
• Anything bigger goes through the intake form and gets prioritized weekly.
• Drive-by DMs without context will be redirected to the form.

People will hate this for 10 days. Then they'll love it, because the requests that come back have actual decisions attached and the answers stick.

Start deprecating the kill list

Send the memo. Give a 2-week notice ("these dashboards will be archived on May 14th unless someone claims ownership"). Two or three will get claimed, and that's fine. Hand them off. The rest, archive. Don't delete in the warehouse, just unpublish from the BI tool. You can always restore.

By day 60 you should have killed 12-20 assets and the BI tool should feel meaningfully less polluted.

Pick your time-to-insight baseline

Before day 60 ends, lock in a baseline measurement of how long it takes a stakeholder request to go from "asked" to "answered with a decision attached." Track median, not mean — one weeklong project skews the average and tells you nothing.

Three flavors that work:

• Median request close time: from intake submission to "decision recorded" (in days)
• Decisions backed by data: percentage of leadership decisions in the last 30 days that referenced an analytics output (sample 10, ask)
• Dashboard-to-pull ratio: how many self-serve dashboard views happened per ad-hoc pull request

Pick one. Measure it now. Write the number down. You'll need it on day 90.

Days 61-90: Own the Metric, Present the Report

Month three is when you stop being "the new BA" and become "the analyst who owns time-to-insight." That shift, internally, is what unlocks the next role.

Drive time-to-insight down

You measured it on day 60. Now move it. The levers are unglamorous:

• Dashboard the top 3 recurring questions so they stop being requests
• Build 2-3 query templates the team can self-serve from
• Push back politely on "quick pulls" that are actually scope-creep ("this is a project, let's intake it")
• Pair-analyze with one stakeholder per week so they learn the schema

A reasonable target for month three: drop median request close time by 30-40%, or move dashboard-to-pull ratio from whatever the baseline was up by 50%. Both are achievable if you've done months one and two right.

Build the 90-day report deck

Day 85, write a 7-slide deck for your manager and skip-level. Not a wall-of-text doc. A deck. Slides:

1. What I inherited: 47 dashboards, 14 versions of revenue, ad-hoc backlog of 23, no SLA
2. What I killed: deprecation list with view counts (the receipts matter)
3. What I shipped: the one high-leverage dashboard, with the exec who's using it named
4. The SLA: published date, adoption rate, current state of intake queue
5. Time-to-insight: baseline number on day 60, current number on day 90, the delta
6. Schema cleanup wins: the canonical revenue definition (next section), any other consolidations
7. Next 90 days: 1-2 quarterly OKRs you're proposing to own

The deck should take 15 minutes to walk through. If it takes 30, cut.

Lock in 1-2 quarterly OKRs you actually own

By the end of the meeting, your manager should agree to one or two outcomes you're accountable for next quarter. Examples that work:

• "Reduce median time-to-insight from 6 days to 2 days by end of Q3"
• "Migrate the 3 highest-traffic ad-hoc reports to self-serve dashboards"
• "Establish canonical metric definitions for revenue, ARR, and net retention; deprecate all variants"

What you want to avoid: "support the team with analytics." That's not an OKR, that's a job description, and at review time it gives your manager nothing concrete to defend.

The "Looker Has 14 Versions of Revenue" Reality

Somewhere in month one, you discovered the warehouse has 14 different definitions of revenue. Booked, billed, collected, recognized (GAAP), recognized (internal), MRR-converted, ARR-converted, ARR-net-churn, gross retention, net retention, ARR-with-rampdeals, expansion-only, new-logo-only, and one column literally named revenue_FINAL.

You cannot fix this in week one. You probably can't fix it in your first quarter. But you can start, and starting is the difference between a BA and a Senior BA.

The non-political playbook:

1. Pick a steward, not a winner. Don't side with Finance or RevOps. Get one person from each (plus you) to agree to be the standards committee. Three people. Meet for 45 minutes.
2. Propose ONE canonical definition for the most-fought-over metric (usually ARR or net retention). Write the SQL. Show what number it produces for last quarter. Compare to each team's current number.
3. Get sign-off in writing. Slack thread is fine. The point is later, when someone challenges the number, you can link to it.
4. Deprecate the rest in dbt. Mark old models as deprecated, give a 30-day window, then remove. Other teams' dashboards will break. Send the warning, hold the line.
5. Repeat for the next metric next quarter. This is a 12-month cleanup, not a sprint.

The trap is trying to canonicalize 14 metrics in month two. You'll start a turf war, lose, and burn the political capital you need for everything else. One metric per quarter. Slow and signed-off beats fast and reverted.

Common Traps to Avoid

A few patterns that sink new BAs in the first 90 days:

• Saying yes to every pull. You feel helpful. You're not. You're training the org to bypass the intake form. By month three the SLA has rotted and you're back to vending-machine status.
• Rebuilding before understanding. It's tempting to nuke the previous BA's work and start clean. Don't. Half of it is load-bearing in ways that aren't obvious. Audit first, kill second, build third.
• Ignoring the data engineering team. They own your input data. If you build a dashboard on a table they're about to deprecate, you'll learn at exactly the worst moment. Buy the coffee.
• No written SLA. Verbal SLAs are not SLAs. They're vibes. Vibes do not survive a Q3 push.
• Taking sides in the metric wars. If RevOps and Finance disagree on revenue, your job is to convene the standards conversation, not to declare a winner. Picking a side gets you one ally and one enemy. Convening gets you two allies.

At Day 90, You Should Be Measured on Decisions Enabled

If your manager opens your day-90 review and asks "how many queries did you run," you've got the wrong manager (or the wrong framing of the role) and you need to fix one of those.

The right framing: how many decisions did your work enable, how much faster did the org get to those decisions, and what compounding asset (a dashboard, an SLA, a canonical metric) did you leave behind that the next quarter benefits from?

That's the difference between a BA and a vending machine. The vending machine closes tickets. The BA changes how the company sees itself. Day 90 is where that distinction starts to show in your calendar — fewer ad-hoc DMs, more "can you join the planning meeting, we want your read."

When that invite shows up, you're past the onboarding and into the actual job. Now build the next 90.

Learn More

• Business Analyst Job Description Template
• How to Run an Ad-Hoc Request Intake That Doesn't Drown You
• Canonicalizing Metric Definitions Across Teams
• Time-to-Insight: The BA Metric That Actually Matters