Stop 14 · Build Your PM PortfolioProjects · 3/7

Root-Cause: Diagnose a Metric Drop

Part of the Product Management Roadmap

In short

"Orders dropped 15% yesterday" is the kind of message that ruins a PM's morning. This project shows you can calmly find the real cause instead of guessing.

A hypothetical (or real, if you have access to data) scenario where a key metric dropped — showing your analytical process for isolating the actual cause, not just guessing.

The purple blob examines a wilting potted plant with a magnifying glass.

Think of it like this

The wilting plant

Your plant is wilting. You don't buy a new one. You check one thing at a time: is the soil dry, did it lose sunlight, is the pot too small, are there pests? Each check rules something out. Soon only one cause is left.

Watch it happen

Breaking down a 15% drop in orders

Orders -15%
Internal
External
Tracking bug
New release
Holiday/season
Competitor offer
Android 5.2 only

1/5Start by confirming the drop is real and how big it is, compared with the same day last week.

The big ideas

What you need to know

Is the data right?

Always rule out tracking or dashboard bugs first. Many "drops" are broken data.

Segment everything

Split by platform, city, version, new vs returning. Real causes usually hide in one slice.

What changed?

List releases, experiments, prices and outside events around the date.

Write it up clearly

Present hypotheses, how you tested each, what you ruled out, and the fix.

See it in code

Walk through the code

sql
1SELECT2  DATE(placed_at) AS day,3  platform,4  app_version,5  COUNT(*) AS orders6FROM orders7WHERE placed_at >= CURRENT_DATE - INTERVAL '14 days'8GROUP BY day, platform, app_version9ORDER BY day, platform;

1/3Count orders per day, broken down by platform and app version.

A segmenting query in PostgreSQL. Splitting daily orders by platform and app version often reveals that a drop sits in one slice.

Save yourself the pain

Common mistakes

Oops

Jumping to "users are bored" without checking data.

Do this instead

Rule out tracking bugs and recent changes before guessing at user behaviour.

Oops

Looking only at the overall number.

Do this instead

Segment. A total can hide a huge drop in one city or platform.

Your mission

First milestone: the hypothesis tree

~30 min

Quick check

A metric drops overnight. What should you check first?

Go deeper

  1. 1Construct a believable scenario: which metric dropped, by how much, over what period.
  2. 2List the possible causes (a shipped bug, a competitor move, seasonality, a segment shift) and how you'd rule each in or out.
  3. 3Present your diagnosis process, not just a conclusion — the reasoning is the point.

More projects at this stop

Stuck on this topic? Ask an Insider

Get 1:1 guidance from people who've walked this exact path — on the InsideEdge app.

Download
InsideEdge