What is the difference between a data analyst and a data scientist?

If you’re trying to break into data or you’re building a data team, the “data analyst vs. data scientist” debate can feel like splitting hairs. These jobs overlap more than job postings suggest. Still, the differences matter—especially when you’re deciding what to learn next or whom to hire first. I’ve led and hired for both roles, and the fastest way to waste money is to hire a brilliant data scientist when what you really need is excellent reporting and reliable metrics—or the reverse. Let’s unpack how these roles diverge in goals, skills, outputs, and impact, with real examples, common pitfalls, and practical guidance you can use right away.

Why the distinction matters

• For job seekers: You’ll pick the right learning path, build a relevant portfolio, and avoid getting stuck in a role that doesn’t fit your strengths.

• For managers: You’ll know who to hire first, how to set measurable expectations, and how to structure projects so insights actually drive revenue or savings.

• For teams: You’ll reduce friction. Misaligned expectations (e.g., asking analysts to ship production ML or asking scientists to run daily KPI dashboards) burns time and morale.

A shortcut: analysts help you see what’s happening and why; data scientists help you predict what will happen and recommend what to do next. Both are valuable—but they shine at different points in the decision-making process.

A simple analogy

• Data analyst = skilled financial analyst for the whole business. They reconcile numbers, standardize metrics, turn raw data into dashboards and accessible insights, and answer questions quickly.

• Data scientist = R&D for decisions. They research and build models that learn patterns, make predictions, and power intelligent features (recommendations, churn alerts, risk scoring).

Now let’s go deeper.

What a data analyst actually does

When someone asks, “How many customers did we acquire last week and from which channels?” an analyst can answer accurately and fast. Their craft is reliable metrics, clean datasets, and intuitive storytelling that drives decisions.

Core responsibilities

• Data cleaning and preparation

• Standardize formats (dates, currencies, IDs), handle missing values, fix inconsistent categories (e.g., “US,” “U.S.,” “United States”).

• Join data from different systems—CRM, product analytics, billing—into consistent “truth” tables.

• My rule of thumb: expect 60–80% of analyst work to be data prep. It’s not glamorous, but it’s where accuracy is won.

• SQL-first exploration

• Write efficient queries to slice data, calculate KPIs (conversion rates, retention, LTV), and answer ad-hoc questions.

• Use window functions, CTEs, and case statements to create sturdy, reusable logic.

• Business metrics and definitions

• Define “active user,” “qualified lead,” or “churn” in ways the entire company can agree on. Analysts guard these definitions.

• Set up semantic layers or dbt models so the same calculation is used everywhere.

• Dashboards and reporting

• Build accessible dashboards in tools like Tableau, Power BI, or Looker so teams can self-serve insights.

• Automate recurring reports and add context: benchmarks, previous period comparisons, annotated anomalies.

• Descriptive and diagnostic analytics

• Analyze what happened and why: seasonality, cohort behavior, funnel drop-offs.

• Run A/B test analyses with guardrail metrics. Validate uplift with statistical tests.

• Communication and enablement

• Translate findings into decisions. The right chart beats 20 tables; a crisp recommendation beats ten charts.

Tools they live in

• SQL (Snowflake, BigQuery, Redshift, PostgreSQL)

• BI: Tableau, Power BI, Looker, Metabase, Mode

• Data transformation: dbt, SQL-based ELT

• Scripting for light analysis: Python (pandas), R, or even advanced Excel

• Project management: JIRA/Asana, Confluence for documentation

Typical deliverables

• A trusted KPI dashboard with definitions documented

• A weekly performance report with commentary

• A cleaned dataset or dbt model teams can query

• An analysis write-up answering a clear business question and recommending next steps

A day in the life (sample)

• Morning: Review yesterday’s KPIs for anomalies; alert marketing that paid search CPA spiked due to a mislabeled campaign.

• Midday: Join product analytics (events) with CRM leads to understand which features drive trial-to-paid conversion. Present a 3-slide summary with a recommendation: simplify onboarding screens that correlate with 15% higher conversion.

• Afternoon: Build a cohort retention report and create a Looker Explore so product managers can dig in themselves.

A concrete example: inventory planning

A retail team suspects stockouts are hurting revenue. The analyst:

• Pulls 18 months of SKU-level sales data; tags stockouts and lead times.

• Builds a simple forecast of expected demand by week and region.

• Quantifies lost revenue when items went out of stock.

• Recommends reorder points for top 100 SKUs.

• Publishes a dashboard with alerts when inventory dips below threshold.

Result: even a modest 15% reduction in stockouts on top SKUs can directly add hundreds of thousands in monthly revenue for a mid-size retailer. No machine learning required—just clean data and operational follow-through.

What a data scientist actually does

When the question shifts from “What happened?” to “Who will churn next month—and what should we do about it?” you’re in data scientist territory. They build predictive models and intelligent systems that adapt as new data arrives.

Core responsibilities

• Problem framing and experimental design

• Translate business goals into predictive tasks: classification (churn vs. not), regression (predict lifetime value), ranking (recommend top products).

• Define success metrics: AUC, lift, RMSE—and more importantly, business KPIs like churn reduction or increased revenue per user.

• Feature engineering and data wrangling

• Create signals the model can learn from: rolling aggregates, recency/frequency (RFM), interaction features, text embeddings.

• Work with structured data, unstructured text, images, event logs, and graph data.

• Model training and selection

• Try baselines first (logistic regression) before complex models (gradient boosting, neural networks).

• Tune hyperparameters, run cross-validation, avoid leakage, and maintain hold-out sets.

• Evaluation and validation

• Check calibration, precision/recall at different thresholds, fairness metrics, and sensitivity analysis.

• Design online experiments (A/B or interleaving) for model impact.

• Deployment and MLOps

• Package models for inference via APIs, batch scoring pipelines, or embedding in BI tools.

• Monitor drift, data quality, latency, and re-training schedules. Alert when performance degrades.

• Advanced analytics

• NLP (topic modeling, sentiment, summarization), computer vision (classification, detection), time-series forecasting, causal inference.

Tools they live in

• Python (pandas, scikit-learn, XGBoost, LightGBM), R for some teams

• Deep learning: PyTorch, TensorFlow

• NLP: spaCy, Hugging Face Transformers

• Data: Spark, Dask, DuckDB for big data or local exploration

• Experimentation: MLflow, Weights & Biases

• MLOps: Docker, Kubernetes, Airflow, feature stores, model registries

• Cloud: AWS (SageMaker), GCP (Vertex AI), Azure ML

Typical deliverables

• A trained model with documented performance and assumptions

• A feature set and pipeline ready for production scoring

• An experiment plan and results analysis showing business impact

• A service or batch process that integrates predictions into workflows

A day in the life (sample)

• Morning: Audit yesterday’s prediction drift; retrain a model whose AUC fell 3% due to a pricing change altering customer behavior.

• Midday: Build a minimal XGBoost model to forecast next-week demand, beating the naive baseline by 25% MAPE.

• Afternoon: Collaborate with engineering to deploy a new recommendation API with a 100ms latency budget; set up inference logging for post-deployment evaluation.

A concrete example: churn prediction

A subscription SaaS company wants to reduce churn.

• Define the target: “Churn within 30 days.”

• Build features: days since last login, support tickets, downgrade events, seat utilization, billing issues, NPS, tenure.

• Train and validate: start with logistic regression; move to gradient boosting if it meaningfully improves precision@top-deciles.

• Operationalize: score all active users weekly; send the top 10% at-risk to a customer success queue with recommended actions.

• Measure impact: CSM outreach reduces churn in targeted cohort by 18%, net retention lifts by 3–5 points.

This isn’t magic; it’s focused signal engineering, careful validation, and tight integration with frontline teams.

Same data, different outputs: a side-by-side project

Imagine you have user-level product analytics, subscription data, and support tickets. How each role uses it:

• Analyst deliverables

• Self-serve funnels (signup → activation → upgrade).

• Cohort retention dashboard (weekly, monthly, feature-level).

• Support tickets volume by category; response time trends; links to churn.

• Executive summary: “Users who complete feature X within 7 days retain 12% better at 90 days.”

• Scientist deliverables

• A propensity score for each user: “likelihood to churn in 30 days.”

• Uplift modeling to target users who are not just likely to churn, but likely to be saved by intervention.

• A prescriptive policy: choose outreach channel and incentive by user segment.

Both outputs are valuable; the key is sequencing. Analysts set the stage with truth and clarity. Scientists turn that clarity into foresight and leverage.

Skill comparison without the buzzwords

• Strategy and problem framing

• Analyst: Translate business questions into metrics and analyses. Decide what to measure and how to define it.

• Scientist: Translate business goals into prediction or decision problems with measurable impact.

• Statistics

• Analyst: Descriptive stats, sampling, hypothesis tests, A/B testing, confidence intervals.

• Scientist: The above plus predictive modeling, validation, bias/variance trade-offs, causal methods, Bayesian techniques for some teams.

• Programming

• Analyst: SQL first; some Python/R for data wrangling or light modeling; Excel as needed.

• Scientist: Python/R as primary; strong software engineering practices for reproducibility and deployment.

• Data scope

• Analyst: Primarily structured tables from transactional systems and events.

• Scientist: Structured and unstructured (text, images, audio), time series, graphs.

• Outputs

• Analyst: Dashboards, reports, cleaned datasets, metric definitions, A/B analyses.

• Scientist: Models, APIs, batch scoring pipelines, experiment results, feature stores.

• Stakeholders

• Analyst: Business teams across marketing, product, ops, finance.

• Scientist: Product managers, engineers, analytics leadership; sometimes risk/compliance.

Project lifecycle differences

• Analyst lifecycle

• Intake: clarify the question and decision.

• Data prep: pull and join sources; document definitions.

• Analysis: descriptive trends, segment slicing, hypothesis tests.

• Visualization: clear charts with context.

• Recommendation: what to do, trade-offs, and next steps.

• Enablement: dashboards and training for self-serve.

• Scientist lifecycle (CRISP-DM with production twists)

• Business understanding: define outcome and success metrics.

• Data understanding: explore distributions, leakage risks, missingness patterns.

• Feature engineering: aggregate behaviors, encode text, scale and normalize as needed.

• Modeling: baselines → advanced; cross-validation; hyperparameter tuning.

• Evaluation: offline metrics and decision thresholds tied to costs/benefits.

• Deployment: containerize, integrate, monitor; plan retraining cadence.

• Experimentation: A/B test to confirm actual business lift.

Real-world impacts you can measure

• Self-serve dashboards

• Impact: less ad-hoc querying, faster decisions. On teams I’ve supported, well-designed BI reduced ad-hoc requests by 30–50%.

• Pitfall: dashboards with 30 charts and no clear takeaways get ignored.

• Forecasting and inventory

• Impact: 10–30% reduction in stockouts and up to 5–10% reduction in overstock with improved demand forecasts and reorder policies.

• Pitfall: pushing a complex model into a supply chain that can’t act on it. Better to deliver a simple, explainable policy first.

• Personalization and recommendations

• Impact: 5–20% lift in click-through or conversion in e-commerce and media when recommendations are tuned and placement is thoughtful.

• Pitfall: ignoring cold-start users or lacking feedback loops; model degrades quietly.

• Churn prevention

• Impact: 10–25% reduction in churn within targeted cohorts when interventions are timely and cost-effective.

• Pitfall: treating all at-risk users the same; you end up offering discounts to users who would have stayed anyway.

Hiring: who to hire first and how to write the job description

If you’re early-stage or your data is a mess, start with an analyst. If you already have consistent metrics and a BI layer but want predictive or automated decisions, bring in a scientist.

Signs you need an analyst

• Teams argue about “true” numbers.

• Executives ask for a weekly KPI pack and it takes days to compile.

• You have plenty of data but limited insight or self-serve access.

• Ad-hoc questions pile up and decisions stall.

What the job description should emphasize:

• SQL mastery, BI tools, metric definitions, strong communication.

• Experience joining messy data across systems.

• Portfolio: dashboards, analyses with business outcomes.

Signs you need a data scientist

• You have a relatively reliable warehouse and clear metrics.

• You’re ready to implement predictions or personalization into products or processes.

• You can integrate models into systems with engineering support.

What the job description should emphasize:

• Clear examples of productionized models and measurable impact.

• Strong Python and scikit-learn/boosting; basic deep learning if needed.

• Experimentation and MLOps familiarity, not just notebooks.

Avoid the unicorn posting. If your JD asks for expert-level deep learning, dashboarding, data engineering, and stakeholder management in one person, you’ll either overpay or hire someone spread too thin to be effective.

Career paths: moving between roles and leveling up

Many analysts become data scientists—if that’s the path you want. Others move into analytics engineering or product analytics leadership. If you’re moving from analyst to scientist, here’s a practical roadmap I’ve seen work.

Analyst → Scientist roadmap (6–12 months of focused effort)

• Solidify Python for data science

• pandas, numpy for wrangling; scikit-learn for modeling; matplotlib/seaborn/plotly for visualization.

• Build 3–4 end-to-end projects on realistic datasets, not toy ones.

• Learn modeling fundamentals

• Train/test splits, cross-validation, regularization, bias/variance, evaluation metrics aligned to the problem (precision/recall for imbalanced classes, calibration for risk scoring).

• Start with regression/logistic regression; move to tree-based methods (XGBoost/LightGBM). Use deep learning only when it genuinely helps.

• Practice MLOps basics

• Package a model with FastAPI; create a batch scoring pipeline with Airflow; log experiments with MLflow; containerize with Docker.

• Do at least one deployment

• Host a simple API or a batch job that runs on a schedule. Measure latency, reliability, and model performance drift.

• Study two specializations relevant to your target industry

• Example: time-series forecasting for retail; NLP for support ticket triage; recommender systems for media or e-commerce.

• Build a narrative portfolio

• Each project should state the business problem, the baseline, the model, the decision, and the measured impact (even if simulated).

Scientist → Analytics leadership or principal IC

• Deepen business acumen: run prioritization; work with PMs on roadmaps.

• Mentor and establish modeling standards and review processes.

• Lead experiment design for high-stakes decisions.

• Advocate for data quality and governance; partner with data engineering.

Compensation snapshot (US rough ranges, vary by location and company stage)

• Data analyst: roughly $70k–$130k base, with higher end in major tech hubs.

• Senior analyst/analytics engineer: $110k–$160k.

• Data scientist: $110k–$180k base, senior up to $220k+.

• Note: total comp can be higher with bonuses and equity, especially at larger tech companies.

Tools and ecosystem: where they overlap and diverge

• Shared foundations

• SQL is universal. Both roles benefit from dbt for repeatable transforms and version control for code and queries.

• Documentation and data catalogs (e.g., DataHub, Atlan, Collibra) help everyone.

• Analyst-leaning stack

• BI: Tableau, Looker, Power BI

• ELT: Fivetran/Stitch + dbt

• Warehouses: BigQuery, Snowflake, Redshift

• Lightweight Python/R for statistics

• Scientist-leaning stack

• Modeling: scikit-learn, XGBoost, PyTorch

• Experiment tracking: MLflow, Weights & Biases

• Orchestration: Airflow, Prefect

• Serving: FastAPI, Flask, SageMaker/Vertex AI

• Feature stores and model registries for governance

If you’re building from scratch, keep it simple: adopt one warehouse, one BI tool, and one modeling stack. Tool sprawl creates debt faster than it creates value.

Data types and complexity

• Analysts mostly wrangle structured data: transactions, events, users, orders.

• Scientists often add:

• Text: customer feedback, tickets, reviews (NLP).

• Time series: sensor data, demand, financial prices.

• Images or audio: vision/speech problems.

• Graphs: fraud rings, social networks, related-item graphs.

Pro tip: a well-structured event schema (userid, timestamp, eventtype, properties) is a gift for both roles. It unlocks behavioral features, funnel analyses, and reliable longitudinal measurement.

KPIs: how each role is measured

• Analyst success metrics

• Adoption of dashboards (views, time on dashboard), reduction in ad-hoc requests.

• Decision speed: less time from question to action.

• Data quality: fewer discrepancies, fewer “Which number is right?” debates.

• Business outcomes tied to analyses: revenue lift from a pricing recommendation, cost savings from process changes.

• Scientist success metrics

• Business lift in experiments: incremental revenue, reduced churn, improved engagement.

• Model reliability: latency, uptime, drift response time.

• Responsible AI practices: fairness checks, documentation, alignment with compliance.

• Reusability: features and pipelines that accelerate future work.

Common misconceptions that slow teams down

• “A data scientist can handle all our analytics.”

• Reality: Predictive modeling doesn’t replace metrics, definitions, and BI. Without strong analytics, model impact is hard to measure and trust.

• “Machine learning is always better.”

• Reality: Start with the simplest solution that works. Plenty of high-ROI wins come from rule-based or regression models with great features.

• “We’ll hire one ‘full-stack’ unicorn.”

• Reality: You’ll burn them out. Split responsibilities: analysts/analytics engineers on data modeling and BI, scientists on modeling and experimentation.

• “Dashboards will fix our data culture.”

• Reality: Dashboards are only as useful as the decisions they drive. Tie each dashboard to a decision cadence (weekly ops, monthly product review).

• “If we just get a model into production, value will follow.”

• Reality: Value arrives when the business process changes. Integrate predictions into workflows, train users, and set SLAs for action.

Governance, ethics, and risk

It’s easy to assume models are unbiased because math feels objective. That’s not how it works.

• Data lineage and provenance

• Track where each field comes from; log schema versions; document assumptions.

• Privacy and compliance

• Minimize personal data; anonymize where possible; respect regional laws (GDPR/CCPA). Create deletion workflows.

• Fairness checks

• Evaluate model performance across sensitive groups where appropriate. If you can’t measure fairness, you can’t claim you’re fair.

• Human-in-the-loop systems

• For high-stakes decisions (loans, healthcare), keep human oversight and explanations.

• Monitoring

• Watch for distribution shifts and sudden drops in performance. Automate alerts before a model causes harm.

Collaboration patterns that work

• Data contracts between engineering and data

• Define required fields, schemas, and change management. Prevent breaking changes that ripple across analytics and models.

• Analytics engineering as a bridge

• Build clean, reusable datasets with dbt. This frees analysts and scientists from constant rework.

• Feature reuse

• Maintain a lightweight feature store or at least shared feature code. Stop re-implementing the same rolling aggregates five times.

• Experimentation culture

• Decide in advance what success looks like, and run controlled tests. Analysts handle instrumentation and guardrails; scientists design treatment logic and evaluate lift.

• Documentation as a product

• Maintain metric definitions, data dictionaries, model cards, and experiment logs. If it’s not documented, it isn’t real.

Step-by-step: from business question to trusted answer (analyst)

Let’s say your CEO asks, “Why did revenue dip 7% last month?”

• Clarify scope

• Is this net revenue? Which regions? Which products? Subscription or one-time?

• Sanity checks

• Reconcile totals across warehouse tables, billing exports, and BI outputs. Confirm there were no schema changes.

• Decompose revenue

• Price x volume, by segment. Product mix, promotion effects, discounts, refunds.

• Segment and compare

• New vs. existing customers, traffic channels, cohorts, regions, device type.

• Identify drivers

• Use contribution analysis. Which segments explain most of the decline?

• Validate with external signals

• Inventory outages? Payment gateway issues? A competitor promotion?

• Communicate clearly

• “70% of decline came from Region A due to a misconfigured promotion code removing free shipping. Fixing the rule and re-running the promo should recover 3–4% next month.”

• Automate

• Add a recurring health check dashboard and anomaly alerts for the affected metrics.

Step-by-step: from question to production model (scientist)

Suppose product wants “personalized recommendations on the product page.”

• Frame the objective

• Optimize for click-through? Add-to-cart? Purchase? Decide and collect labels.

• Baselines

• Start with popularity by category and simple collaborative filtering. Measure lift.

• Data prep

• Build user and item embeddings from interactions; handle cold start with content-based features (metadata, text).

• Train and validate

• Compare matrix factorization, gradient-boosted ranking, and neural recommenders. Optimize for NDCG or MAP.

• Bias and diversity

• Ensure recommendations don’t narrow choices excessively; add diversification constraints.

• Deployment

• Expose a low-latency API; cache results; log impressions and clicks for retraining data.

• Experimentation

• A/B test against the baseline. Track CTR, conversion, and average order value. Watch for long-term effects (e.g., catalog exposure).

• Iterate

• Improve cold-start strategies, tune re-ranking with business rules, and update retraining cadence.

What the job market says

• Demand is strong for both roles. The U.S. Bureau of Labor Statistics projects data scientist roles to grow around 35% from 2022 to 2032—much faster than average. Related analyst roles (e.g., market research, operations research) also show double-digit growth.

• Trend: hybrid roles are becoming common—analytics engineers who sit between data engineering and analysis, and ML engineers who sit between data science and software.

• Companies increasingly value analysts who can build scalable data models (dbt) and scientists who can ship models (MLOps). Pure analysis or pure research roles exist but are less common in small to mid-size companies.

Common mistakes and how to avoid them

• Mistake: Skipping metric alignment

• Fix: Create a metric dictionary. Have finance sign off. Use these definitions everywhere.

• Mistake: Building models on unstable features

• Fix: Choose features derived from robust sources with change management. Add schema checks and alerts.

• Mistake: Optimizing offline metrics that don’t match business goals

• Fix: Tie evaluation to decision thresholds and costs. Precision@k may matter more than AUC.

• Mistake: Ignoring deployment and process change

• Fix: Design the last mile at the start. Who acts on predictions? How fast? Through which tools?

• Mistake: Overfitting the resume—not the business

• Fix: Hire for what you need in the next 12–18 months. If you won’t deploy deep learning, don’t make it a hard requirement.

• Mistake: Dashboard overload

• Fix: Each dashboard should answer one key question and map to a decision cadence. Archive anything not used.

• Mistake: Treating analysts as “reporting only”

• Fix: Involve analysts early in strategy. They surface counterintuitive patterns that shape product and marketing moves.

Building a small but mighty data function

If you have a small team, here’s a pragmatic sequence I’ve seen work:

• Data engineering/stack basics

• Get a reliable warehouse (BigQuery/Snowflake), ETL (Fivetran/Stitch), and dbt for transformations.

• Analyst hire

• Define core metrics and build a few high-impact dashboards. Cut ad-hoc chaos and establish trust in the numbers.

• Analytics engineering

• Harden data models, standardize logic, add tests. Make your warehouse a product people can rely on.

• Data scientist hire

• Tackle one high-leverage model with a clear operational path (churn risk, lead scoring, recommendations). Prove ROI in 60–90 days with a baseline and a clean A/B test.

• MLOps/ML engineering support

• Once models matter, you’ll need reliability. Invest in monitoring, registries, and deployment pipelines.

Learning projects that actually impress

• Analyst portfolio ideas

• Build an executive KPI dashboard with drill-downs and clear definitions. Use a public dataset (e.g., NYC taxi data, a retail sales dataset).

• Run a full A/B test analysis on simulated experiment data. Show your hypothesis, sample size calculation, and decision.

• Create a dbt project that models events into a clean star schema; include tests and documentation.

• Scientist portfolio ideas

• Churn prediction with a realistic pipeline: feature engineering, model selection, calibration, and a simulated intervention analysis.

• Product recommendations using implicit feedback and a re-ranking layer. Host a simple API that serves recommendations.

• NLP on support tickets: classify categories, summarize with a transformer, and estimate impact on resolution time.

Each project should read like a case study: problem, constraints, approach, results, and what you’d do next with more time or data.

When roles blend—and how to protect focus

Lots of companies post “data scientist” roles that are 70% dashboarding. Others hire an “analyst” but expect ML in three months. Blended roles can work if you’re explicit:

• Allocate time: 60/40 split and protect the modeling block from ad-hoc pings.

• Define outcomes: two dashboards shipped per quarter plus one model experiment with a go/no-go decision.

• Provide growth paths: analysts who handle light modeling can evolve toward data science, and scientists can mentor while focusing on one or two production models.

Quick decision guide for managers

• If your team spends hours arguing about KPI definitions, hire an analyst.

• If your product would benefit from predictions embedded in workflows, hire a data scientist (and ensure you have engineering support).

• If you have both needs but one headcount, bias toward an excellent analyst or analytics engineer first. Reliable data multiplies the value of everything that follows.

Practical checklist: are you ready for data science?

• Do you have a warehouse with the key data sources modeled and documented?

• Can you compute your core metrics the same way everywhere?

• Do you have a target variable and a way to measure impact post-deployment?

• Can engineering integrate a model into the product or process?

• Is there a feedback loop to retrain and monitor?

If you answer no to two or more, invest in analytics first.

Final thoughts

Analysts and data scientists are partners, not rivals. Analysts give the organization a shared, accurate view of reality and the tools to explore it. Data scientists take that reality and build systems that anticipate what comes next and help you act faster and smarter. The magic happens when these roles are sequenced thoughtfully, supported by good data engineering, and measured by the business outcomes they enable. If you hire and develop for clarity, not buzzwords, you’ll avoid the most expensive mistake in data: shipping beautiful work that never changes a decision.