All Writing
๐Ÿ“Š Data & DecisionsDeep DiveJuly 20264 min read

I Built 12 Dashboards in Two Years. Teams Ignored 9 of Them.

At Finvestfx, I spent weeks building a beautiful client health dashboard with 15 metrics and custom filters. Usage after week one? Three people. Turns out, dashboards fail when you treat them like feature dumps instead of decision tools.

I used to think a good dashboard just needed the right metrics. Get the data clean, add some filters, make it look nice, ship it. Done.

Then I'd check usage two weeks later and find maybe 2-3 people looking at it. The rest of the team was still asking me for the same data over Slack.

This happened at Finvestfx with a client health dashboard I was really proud of. I had built this whole thing with 15 metrics, segmentation by client size, custom date ranges, the works. Took me three weeks between specs, backend work, and iterations. First week after launch, three people used it. By week four, just me.

The problem wasn't the data. The problem was I had built a dashboard, not a decision.

Start with the decision, not the data

At Sonic Linker, we needed to track how our AI embedding features were performing. I made a different call this time. Instead of asking "what metrics should we track," I asked the team: "what decision are you trying to make this week?"

The answer was simple. We needed to know if users who engaged with AI features stuck around longer than those who didn't. That's it. One question.

So I built a dashboard with exactly two views. Retention curves split by AI feature usage (yes/no), and a cohort table showing week-over-week changes. No fancy filters. No 10 different breakdowns. Just the thing that answered the question.

Usage? Daily. Because people actually needed it to make a call on whether to double down on AI or pull back.

The difference was brutal. I had gone from 15 metrics nobody looked at to 2 metrics everyone relied on. The shift wasn't in the data quality. It was in knowing what the dashboard was *for*.

Make the insight impossible to miss

Here's what I learned building analytics at Sonic Linker with zero budget and no data engineer: if someone has to think for more than 10 seconds to understand what they're looking at, they won't use it.

I used to build dashboards where the insight was hidden in the third filter or required you to compare two charts. That's lazy product thinking. The whole point of a dashboard is to surface the answer, not make people hunt for it.

At Finvestfx, I rebuilt our client pipeline dashboard around this. Instead of showing "number of active deals" and making people calculate conversion rates in their head, I just put the headline number at the top: "You're on track to close 8 deals this month (target: 10)." Red if behind, green if ahead.

Below that, one chart showing which stage was the bottleneck. That's it.

Our sales team started checking it every morning. Not because I added more data, but because I made the decision obvious. They could see in 5 seconds if they needed to push harder or if they were fine.

Kill metrics that don't change behavior

This is the hardest part. You'll want to add metrics because they're interesting or because someone asked for them once. Don't.

I had a metric at Finvestfx tracking "average response time to client queries." Sounds useful, right? Except nobody ever did anything with it. It sat there, updating every day, and zero decisions changed because of it.

I removed it. No one noticed.

Now I have a rule: if a metric hasn't caused someone to take action in the last two weeks, it's gone. Dashboards are not museums. They're tools. Tools that don't get used are clutter.

At Sonic Linker, I shipped our first analytics setup in 48 hours. It had four metrics. That's it. People kept asking for more. I kept asking back: "What would you do differently if you had that number?" Half the time, they couldn't answer. So we didn't add it.

The dashboards that survived weren't the ones with the most data. They were the ones where every metric connected directly to a decision someone had to make that week.

The test that actually matters

Here's how I know if a dashboard works now. I don't check page views or session time. I check Slack.

If people are referencing the dashboard in conversation without me prompting them, it's working. If they're sharing screenshots in standups or using it to back up a debate about priorities, it's working.

If I'm still getting pinged with "hey, can you pull the numbers on X," the dashboard failed. Because that means the thing I built didn't actually make their life easier.

The dashboards teams actually use aren't the prettiest ones or the ones with the most features. They're the ones that answer a specific question faster than any other method. That's it. Build for that, and people will keep coming back.