The set of tool categories every PM interacts with, each answering a different kind of product question. Mapping them prevents the common mistake of using the wrong tool for the question.
▸ Try the interactive toolThe PM analytics stack is the set of tool categories every PM interacts with, each answering a different kind of product question. The point of mapping them is practical: understanding which tool answers which question prevents the common mistake of reaching for the wrong tool — trying to answer a 'why' question with a dashboard, or a 'what happened' question with session replay.
The categories span the journey from raw data to decision: product analytics (events, funnels, retention — the 'what'), session replay / qualitative (watching real usage — the 'why'), BI / dashboards (monitoring known metrics), data warehouse + SQL (ad-hoc deep questions), experimentation platforms (causal tests), customer feedback / VoC (sentiment), and CRM / revenue tools. The skill isn't mastering all of them — it's knowing the type of question each answers, so you go to the right place rather than forcing one tool to do another's job.
Product analytics — what happened (events, funnels) · Session replay / qual — why · BI / dashboards — monitor known metrics · Warehouse + SQL — ad-hoc deep questions · Experimentation — causal · VoC / feedback — sentiment.
PMs routinely use the wrong category for the question — hunting for 'why' in a dashboard, or 'what happened' in a survey — and get frustrated that the tool can't answer what it was never meant to.
| The shortcut | What it costs | What it gives you instead |
|---|---|---|
| Wrong tool for the question | Asking a dashboard 'why' or analytics for sentiment. | Mapping tools to question types sends you to the right one. |
| Forcing one tool everywhere | Trying to do everything in one category badly. | Each category answers its own kind of question well. |
| Missing the right capability | Not knowing a category exists for your question. | The map reveals which tool can actually answer it. |
| Confusing what and why | Treating analytics' 'what' as if it explained 'why'. | Separating product analytics from qualitative tools clarifies it. |
Learn the seven-or-so categories and the question-type each addresses — 'what happened' (product analytics), 'why' (session replay, qual), 'how's the known metric' (dashboards), and so on.
Frame the question first, then choose the category that answers that type of question. Going tool-first leads to forcing the wrong instrument onto the job.
Resist hunting for 'why' in a dashboard or 'what happened' in a survey. When you hit a tool's limit, switch categories rather than forcing it.
Real questions often need several: analytics finds the 'what' (a drop-off), session replay reveals the 'why', an experiment validates the fix. The stack works together.
You don't need mastery of all categories — just enough fluency to know which answers which question, and enough depth in the ones you use most (often SQL, Tool 22).
A PM, puzzled by a sudden metric change, spent hours in the BI dashboard slicing the number every way — trying to find why it had moved. The dashboard could show that it moved and break it down, but it fundamentally couldn't answer 'why'; that wasn't the category's job.
Mapping the stack made the path obvious: the dashboard answers 'how's the known metric doing,' product analytics answers 'what happened in the funnel,' but 'why did users behave differently' needed session replay and qualitative research. Switching to the right category answered in minutes what hours in the wrong tool couldn't — because the question and the tool finally matched.
The deliverable is a working map of which tool category answers which type of question — so you start from the question and pick correctly.
| Question | Tool category |
|---|---|
| What happened? (funnels, retention) | Product analytics |
| Why did users do that? | Session replay, qualitative |
| How's our known metric? | BI / dashboards |
| An ad-hoc deep data question | Warehouse + SQL |
| Did the change cause it? | Experimentation platform |
| How do users feel? | VoC / feedback |
The analytics stack is less about tools than about questions. Each category answers a distinct type of question, and the recurring PM mistake is forcing one to answer another's — most often hunting for 'why' in tools that only show 'what'.
The what-versus-why distinction is the most consequential one to internalise, because it recurs everywhere in this module. Product analytics, dashboards, and warehouses all answer variations of 'what happened' and 'how much' — they're powerful and they're silent on causation and motivation. 'Why' lives in a different category entirely: session replay, qualitative research, customer feedback. A PM who confuses the two burns hours trying to extract 'why' from a dashboard that structurally cannot provide it. The mature use of the stack is to start from the question, route it to the category built to answer that type, and combine categories for complete answers — analytics to find the drop, qualitative to explain it, experimentation to validate the fix. Fluency in the map matters more than mastery of every tool.
Dashboards don't answer 'why.' Match the question type to the category.
Forcing your favourite tool onto every question. Start from the question.
Analytics shows what happened, not why. Use qualitative tools for why.
You need fluency in the map, depth only in the tools you use most.
The warehouse+SQL category gets its own treatment (Tool 22) — the most empowering for PMs.
The BI/dashboard category is detailed in Tool 23.
The map operationalises 'analytics shows what, not why' (Tool 12, Module 3 Tool 09).
Every metric and method in Module 5 lives in one of these categories.
AI is now woven through the analytics stack itself — most tools have AI features — and it changes how a PM works across them.
The judgment that stays yours: AI makes every layer faster to query but doesn't change the core skill: knowing which tool answers which question. It also can't supply causation or motivation — a confident AI summary of 'what happened' is still silent on 'why'.
Take three questions: 'how many users completed onboarding last week?', 'why are users abandoning at step 3?', 'did our new flow cause the change?' Assign each to the right tool category.
Notice that they need three different categories — and what goes wrong if you ask the 'why' one in a dashboard.
If the 'why' question needs session replay or qualitative tools rather than the dashboard, you've internalised the map's core lesson: match the question type to the tool built for it.