Your Strategy Is Lying to Your Dashboard

Your dashboard isn't lying to you.

Your strategy is lying to your dashboard.

Most metrics tell you what's happening. They don't tell you whether what's happening is good enough to survive. Those are different questions. Almost every dashboard I've seen in the last decade confuses them.

I built a feature once where the metrics looked too clean. The engagement curve was smooth in a way that real usage almost never is — no spikes, no dropoffs, no friction. The vibes were off. I sensed it and tracked it green anyway. The feature churned into irrelevance over the next two quarters while we reported steady progress the whole way. I now name the survival question before I pick the metric. Always.

That's not a data problem. It's a definition problem.

The dashboard reflects what your strategy declared.

Before any number lands in a dashboard, someone made a decision. Someone chose a metric. Someone set a target. Someone decided what red means and what green means. Every one of those decisions reflects what leadership believed mattered when the system was built.

The dashboard doesn't reveal whether that belief was right. It reports progress against it.

This matters because teams stop questioning the belief. They optimize for the metric. They hit the targets. They keep the green lights on. And the zombie products — the features nobody uses, the initiatives nobody champions, the products that have quietly stopped mattering — stay green until something breaks.

When a product director at Ally Financial told me his team struggled with "what someone thinks is priority vs actual priority," he wasn't describing a communication failure. He was describing a structural one. The dashboard showed leadership's declared reality. It couldn't surface the actual one.

Priority is declared. It is rarely derived from what the signals are actually saying.

RAG is the symptom.

Red/Amber/Green status boards are nearly universal in enterprise product organizations. They're also nearly useless as survival tools.

RAG measures confidence in delivery. It tells you whether you're on track to hit the commitment you made. It does not tell you whether the commitment was worth making. It does not tell you whether users still care. It does not tell you whether the maintenance cost has quietly exceeded the value delivered.

A product can be green on every RAG metric and still be a zombie. You're on schedule to ship something nobody will use. You're on budget to maintain something that's keeping two engineers from working on anything that matters.

I've watched this pattern play out in SaaS product teams, fintech organizations, and government agencies alike — anywhere RAG reporting is gospel. The teams understand intuitively that the dashboard is performing something. They know the green lights feel wrong. They just don't have language for what's missing.

What's missing is a survival signal.

An activity metric and a survival signal answer different questions.

Most metrics answer: Are we doing what we said we'd do?

A survival signal answers: Is this still worth doing?

You can tell them apart with three questions. For any metric on your dashboard:

Does it tell you whether customers still need this? Not whether they're using it the way you hoped. Whether they need it to exist at all. Usage rates, churn on the specific workflow, direct feedback — signals of necessity, not signals of habit.

Does it tell you whether the team can sustain it? The carrying cost: maintenance burden, engineering capacity consumed, the ratio of KTLO work to new investment. A product that's technically "active" but quietly consuming 30% of an engineer's week is a product with a survival problem.

Does it tell you whether leadership would fund it if you pitched it fresh? Not whether it has a champion. Whether it would survive a clean-slate conversation about what deserves to exist.

If a metric can't answer any of those three questions, it's an activity metric. Useful for execution management. Not useful for survival decisions.

The fix isn't a better dashboard.

Here's where most teams go wrong. They see a dashboard that isn't helping them make survival decisions. They go looking for better metrics. More granular data. A new analytics platform. More visibility into user behavior.

That's not wrong. But it won't fix the problem.

You can't measure survival if nobody has agreed what survival looks like for this product.

Before you pick a metric, answer one question: what is the minimum condition under which this product earns its place on the roadmap? Not the best case. Not the expected case. The floor. The threshold below which you would stop.

That answer — agreed on, explicit, named before the work starts — is where survival metrics come from. Not from a better tool. From a cleaner question.

Teams that can answer it make better decisions with the same data they already have. Teams that can't will keep building better dashboards and still not know what's dying.

Your dashboard isn't lying to you. Your strategy is lying to your dashboard.

Most orgs have never explicitly asked what survival looks like for each product they maintain. That's not a metrics gap. It's a clarity gap — and it's the most expensive one on your roadmap.

Whether you're the VP setting the dashboard up or the PM trying to read it honestly, the question is the same: what would a survival signal look like for the thing you're responsible for? Can you name it?

This week's prompt

Pick one product or feature your team is currently maintaining. Open your dashboard for it.

For each metric you can see, ask: does this tell me whether this product is still earning its place? Or does it tell me whether we're doing what we said we'd do?

If you can't find a single survival signal in your current view, that's the finding. Not a data problem. A clarity problem.

What's on your dashboard that you know isn't a survival signal? Reply and tell me what you find.