30 60 90 Day Plan for Data Analyst: Week-by-Week Roadmap and Example

10 min read ยท 2026-10-25

A 30 60 90 day plan for data analyst roles splits your first three months into three goals: learn the data and the business by day 30, deliver trusted work by day 60, and own a domain by day 90. Each stage ends with something your manager can check, such as a KPI you rebuilt that matches the official number, or a report you now run on your own.

Most templates stop at learn the tools and meet the team. This one goes further. It lists the access you need in week one, the people to meet and what to ask them, quick wins that suit an analyst, a filled-in example for a product analyst, the metrics to report at each checkpoint, and how to present the plan to your manager or in a final-round interview.

The roadmap at a glance

Goal: By day 90, you run at least one recurring report on your own, your numbers match the official ones, and one analysis you led has fed a business decision. Duration: 90 days (13 weeks)

  1. Access, people and context (Week 1)

    Get every login you need and understand what the business cares about this quarter.

    • Request access to the data warehouse, the BI tool (Tableau, Power BI or Looker), the Git repo for SQL or dbt models, and the queue for data requests.
    • Read the last two quarterly business reviews, the current OKRs and the three dashboards leadership opens most.
    • Book 30-minute intro meetings with your manager, your data engineering contact and your main business stakeholders.
    • Agree with your manager on what success at day 30, 60 and 90 looks like, and write it down.

    Milestone: All access works, intro meetings are booked, and a one-page note of success criteria is confirmed by your manager.

  2. Learn the data and the metrics (Weeks 2-4)

    Understand where the core numbers come from and prove you can reproduce them.

    • Map the main tables behind revenue, active users or orders, and note their grain, refresh time and owner.
    • Rebuild one core KPI in SQL from raw tables and reconcile it with the official dashboard until the numbers match or you can explain the gap.
    • Start a data notes doc with metric definitions, known data quality issues and who to ask about what.
    • Shadow two or three incoming requests with a teammate before you take them on alone.
    • Fix one small thing you find, such as a broken filter or a mislabeled chart.

    Milestone: Day 30: one core KPI rebuilt and reconciled, a data notes doc shared with the team, and your first small fix shipped.

  3. First deliverables and quick wins (Weeks 5-8)

    Take over recurring work and deliver your first analysis from question to answer.

    • Take ownership of one recurring report or dashboard, including its refresh checks and the questions stakeholders ask about it.
    • Automate one manual report that someone still builds by hand in Excel each week.
    • Handle ad hoc requests from intake to answer, writing down the question, the definition used and the caveats.
    • Deliver one scoped analysis, such as why trial conversion dropped last month, with a clear recommendation.
    • Ask two stakeholders for feedback on how clear and useful your work is.

    Milestone: Day 60: one recurring report has run under your name for four weeks without corrections, one manual report is automated, and one analysis is delivered.

  4. Own a domain (Weeks 9-12)

    Become the go-to analyst for one area and connect your work to a decision.

    • Agree with your manager on one domain you own, such as onboarding, pricing or the sales funnel.
    • Build or clean up the main dashboard for that domain, with definitions written on the dashboard itself.
    • Run a deeper analysis or a test readout that leads to a decision, and present it to the domain lead.
    • Propose one data quality or tracking fix to the data engineering team, with the business impact spelled out.

    Milestone: You are the named analyst for one domain, its main dashboard carries written definitions, and your analysis has been presented to the person who makes the call.

  5. Review and next-quarter plan (Week 13)

    Show what you delivered and agree on what you own next.

    • Collect your results: reports owned, requests closed, turnaround time and decisions your work fed.
    • List the open data issues you found and who owns each fix.
    • Draft next quarter's goals with one stretch goal, such as a forecasting model or a self-serve dashboard.

    Milestone: Day 90: a one-page review approved by your manager, with next quarter's goals agreed.

Your first-week checklist

Week one decides how fast you ramp up. Access requests often take days to clear, so file them on day one, before you know exactly what you need. Ask for read access broadly and write access only where your team works.

Use the waiting time to read, not to build. You want to know which numbers leadership watches, which dashboards people trust, and which ones they quietly ignore.

  • Laptop set up with your SQL client, Python or R environment, and Git.
  • Access to the warehouse, the BI tool, the dbt or SQL repo, the data request queue (Jira or similar) and the team's Confluence or Notion space.
  • Read the data team's onboarding docs, the metric definitions page if one exists, and the last few incident notes.
  • Open the five most viewed dashboards and write down every metric you cannot define yet.
  • Join the team's request channel and read the last month of questions.
  • Book your intro meetings for weeks 1 and 2.

People to meet and what to ask them

An analyst is only as useful as the questions they answer, so most of your first meetings should be with the people who ask the questions. Keep each one to 30 minutes and ask the same core questions so you can compare answers.

Close every meeting with one question: what is one number you do not trust today? The answers give you a ready-made list of quick wins and show you where the data has gaps.

  • Your manager: what a great first quarter looks like, which stakeholders matter most, and what you should not touch yet.
  • Data or analytics engineer: how data flows from source systems to the warehouse, the refresh schedules and the known weak spots.
  • Product manager or business lead you support: the decisions they face this quarter and the questions they cannot answer today.
  • Finance partner: how revenue and other official numbers are defined, so your figures match theirs.
  • Another analyst on the team: the unwritten rules, the tables to avoid and how requests really get prioritized.
  • A frontline user, such as a sales ops or support lead: which reports they actually use and which ones they rebuild in Excel.

Quick wins that fit a data analyst

A good quick win is small, visible and safe. It saves someone time or removes a doubt about a number, and it does not require you to change a model other teams depend on.

Pick one or two, not five. Tell your manager before you start, so you do not fix something another analyst is already rewriting.

  • Write clear definitions for three metrics people argue about, and put them where people will see them, such as in the dashboard description.
  • Automate a weekly Excel report with a scheduled query or a BI subscription.
  • Fix a broken or slow dashboard that a stakeholder flagged in your intro meeting.
  • Clear a backlog of small ad hoc requests and log each answer so the next person can reuse it.
  • Add a simple data freshness check to a report that sometimes shows stale numbers.

Example: a filled-in plan for a product analyst

Here is how the plan could look for a product analyst joining a subscription app, reporting to the head of analytics and supporting the growth product manager.

Notice that each checkpoint names a deliverable and the person who confirms it. That is what makes the plan checkable instead of a list of intentions.

  • Week 1: access to BigQuery, Looker and the dbt repo; intro meetings with the growth PM, the analytics engineer and the finance partner. Owner: you. Confirmed by: head of analytics.
  • Day 30: monthly active subscribers rebuilt in SQL and reconciled with the finance number; data notes doc shared; a broken cohort filter fixed. Confirmed by: analytics engineer and finance partner.
  • Day 60: owner of the weekly growth report; trial funnel report automated; analysis of last month's drop in trial-to-paid conversion delivered with two recommendations. Confirmed by: growth PM.
  • Day 90: named analyst for onboarding; onboarding dashboard rebuilt with definitions; readout of an onboarding A/B test presented, with a ship or stop recommendation the PM acted on. Confirmed by: head of analytics in the 90-day review.

Metrics to report at each checkpoint

Your manager needs evidence, not a list of meetings. Pick a few measures you can count yourself and report the same ones at day 30, 60 and 90 so the trend shows.

Avoid counting dashboards built. Ten dashboards nobody opens are worth less than one the leadership team reviews every Monday.

  • Reconciliation: core KPIs you rebuilt that match the official numbers, or have a written explanation for the gap.
  • Turnaround time: median days from request to answer, taken from the request queue.
  • Reliability: weeks your recurring reports ran on time without corrections.
  • Usage: views of the dashboards you own, from the BI tool's usage data.
  • Impact: decisions that used your analysis, one line each: question, finding, decision.
  • Documentation: metrics in your domain that have a written definition.

How to present the plan to your manager or in an interview

In week one, show your manager a one-page version: three columns for days 30, 60 and 90, each with two or three goals, one deliverable and how you will measure it. Ask them to cross out what does not matter and add what is missing. That edited page becomes your agreement for the quarter.

In an interview, tailor the plan to the company. Use what you learned from the job post and earlier rounds: their BI tool, their main product, the metrics they mentioned. Say what you would learn first, which quick win you would look for and what you would own by day 90. Keep it to two or three minutes and invite them to correct your assumptions, since you have not seen their data yet.

At each checkpoint, send a short written update before the meeting: what you delivered, the metrics above, what is blocked and what you need. It keeps the review about decisions instead of status.

How to adapt it

At a startup with no data team, you may be the first analyst. Spend more of the first month on tracking and data quality: check which events are logged, set up a basic warehouse with help from an engineer, and agree on five core metrics with the founders before you build any dashboard.

At a large company, access and governance take longer. Plan time for access approvals, data handling training and change review for shared models. Your quick wins will lean toward documentation and reconciliation rather than new pipelines.

Seniority changes the third month. A junior analyst can focus on reliability and clean, well-documented requests. A senior analyst should own a domain by day 60 and add mentoring and one cross-team initiative, such as a shared metrics layer, by day 90.

Common mistakes to avoid

  • Building dashboards in week two before you understand the metric definitions leads to numbers that clash with finance, so reconcile one core KPI first.
  • Saying yes to every ad hoc request buries you in small tasks, so route requests through the team's queue and agree on priorities with your manager.
  • Answering the question as asked instead of the decision behind it produces correct but useless work, so ask what decision the answer will feed before you write any SQL.
  • Keeping what you learn in your head means you rediscover the same data quirks every month, so log definitions and issues in a shared doc as you go.
  • Waiting until day 90 to show results leaves your manager guessing, so send a short written update at day 30 and day 60.
  • Rewriting a shared model on your own breaks other teams' reports, so propose the change to the data engineering team and test it before release.

Frequently asked questions

What should a data analyst do in the first 30 days?

Get access to every tool, meet the people who ask for data, and learn where the core numbers come from. Aim to rebuild one key metric in SQL and match it to the official number. Ship one small fix so people see you can deliver.

How do I write a 30-60-90 day plan for a data analyst interview?

Build one page with three columns: learn, contribute and own. Fill it with details from the company, such as its BI tool, its products and the metrics mentioned in earlier interviews. Name one quick win and one domain you would aim to own, and say which assumptions you would check first.

What metrics should a data analyst track in the first 90 days?

Track reconciliation of core KPIs, request turnaround time, reliability of recurring reports, usage of the dashboards you own and the decisions your analysis fed. Report the same measures at each checkpoint so your manager sees the trend.

How is a 30-60-90 day plan different for a senior data analyst?

A senior analyst ramps up on the same basics but should own a domain sooner, often by day 60. By day 90 they usually also lead a cross-team initiative, set standards such as metric definitions or review practices, and mentor junior analysts.

What quick wins can a new data analyst deliver?

Good quick wins are small and visible: automating a weekly Excel report, fixing a broken dashboard, writing clear definitions for disputed metrics or adding a freshness check to a report. Agree on them with your manager so you do not duplicate someone else's work.

Generate this roadmap with AI