A team building an AI-spend tool shipped a dashboard first. The testers' reaction, verbatim:
"started with dashboards, not alerts; testers said 'cool' and never opened it again."
"Cool" is the worst review you can get. It means the person understood what you built, was mildly impressed, and had no reason to return. It is indistinguishable from praise until you check the retention curve.
They pivoted to push-first budget-threshold alerts. Then: "usage dropped 30% in one beta team the week after shipping budget threshold alerts."
Read that carefully, because it looks like a failure and is the opposite. The product measures AI spend. The 30% that dropped was the customer's spend, because the alerts made them act. That is the product working. The dashboard version could not do that, not because the numbers were missing, but because nobody was looking at them.
A dashboard requires the user to remember you. That is the whole flaw in one sentence.
You are asking someone to independently decide, on some unprompted Tuesday, to open your thing and look at numbers. Competing for that decision are their inbox, their actual job, and every other tab. You will lose, and you will lose quietly, because dashboard abandonment produces no complaint. They do not churn angrily. They just stop.
A push inverts it. You decide when the user needs to know something, and you go to them. The bar is now "is this worth interrupting someone for," which is a much healthier design question than "what could we display."
Not "what data do we have." Ask: what single event is worth interrupting someone for?
If you cannot name one, that is the finding. It means your product observes but does not have a moment of consequence, and no amount of charting will manufacture one.
If you can name one, that event is your product. The dashboard is supporting material for the times someone wants to dig in after the alert.
The same lesson shows up as an onboarding rule: find the exact screen where new users drop, and fix that, instead of shipping more features. Founders skip this constantly because diagnosing a drop-off is unglamorous and shipping a feature feels like progress.
There is a nice variant for products sitting on invisible data: surface it by pushing it out. One team parsed users' own coding-agent session transcripts and emailed them a Spotify-Wrapped-style report card. The data existed the whole time. Nobody was going to go look at it.
If your product's home screen is a dashboard, treat that as the leading hypothesis for your activation problem, not a neutral design choice. Name the one event worth an interruption. Send that. Keep the dashboard for the people who want to dig in after they already care. I packaged this and the rest of the diagnosis as an MIT Claude Code plugin: five questions, one failure mode, ranked moves with a source URL each, plus the eleven growth tactics that failed adversarial re-checking. It is at why-isnt-it-selling.