1
Understand the Business
Stakeholders, process, and the decision at stake.
2
Explore the Data
Shape, quality, and what's actually measurable.
3
Identify Root Causes
Why it's happening, not just what's wrong.
4
Design KPIs
Metrics that would change a decision.
5
Recommend Improvements
Specific, prioritized, ownable.
6
Estimate Business Impact
A defensible, assumption-labeled number.
In Detail
// WHAT EACH STEP ACTUALLY MEANS

01 Understand the Business

Before opening any dataset, I map out who is affected by the problem, what process generates the data, and what decision would actually change if the analysis went one way or another. Skipping this step is the fastest way to produce a technically correct analysis that nobody uses.

  • Who are the stakeholders, and what do they each need from this?
  • What's the process, end to end, that produces this data?
  • What decision is on the table — and who makes it?

02 Explore the Data

Structure, volume, missingness, and distribution — before any modeling. This is where I find out whether the data can actually answer the business question, or whether the real finding is about the data itself.

  • Field-by-field profiling: types, ranges, nulls
  • Class balance across categories, priorities, teams
  • Data quality gaps that could bias any downstream KPI

03 Identify Root Causes

Correlation and segmentation, used to explain rather than just describe. I look for where a metric should vary — by priority, by team, by category — and diagnose what it means when it doesn't.

  • Compare outcomes across the dimensions that should matter
  • Distinguish a process failure from a data-capture failure
  • Separate what happened from why it happened

04 Design KPIs

A KPI only earns its place if it would change what someone does next. I design a small set of metrics tied directly to the root causes found in step 3, not a generic dashboard checklist.

  • Each KPI maps to a specific root cause or decision
  • Defined with an explicit target, not just a trend line
  • Built to be monitored on a cadence someone will actually keep

05 Recommend Improvements

Recommendations are specific enough to assign to someone: a process change, a system rule, a policy. Vague advice like "improve communication" doesn't appear here.

  • Prioritized by effort vs. expected impact
  • Each tied to an owner and a KPI it should move
  • Sequenced — what to fix first, and why

06 Estimate Business Impact

A number, with the assumptions behind it stated plainly. I'd rather show a transparent estimate with clear assumptions than a polished figure with hidden ones.

  • Baseline vs. projected state, side by side
  • Assumptions labeled explicitly, not buried
  • Sensitivity noted where the estimate is assumption-heavy