[MicahWedemeyer]

At any given time, there are a near infinite number of things your business "needs" to do: add a dashboard, A/B test your landing pages, test your database backups, fix your security holes, improve your customer service, add more metrics tracking, etc, etc. The list goes on and on.

A big part of running your business involves looking at this list and picking the ones that make sense for your business, not what the blog-post-du-jour is telling you.

[jakejake]

Those are all good things but to me there's only one thing on your list that can instantly end just about any company with no way to recover. That's not having working backups. I would always put that one first!

[drcube]

I'd argue that having a well illustrated overview of your whole company helps you prioritize this list.

So put business and technological metrics on that dashboard. And then you can decide whether you should be focusing most on customer support, A/B testing, or that network bottleneck.

[MicahWedemeyer]

I won't disagree, but my main point is that everything has a cost. These blog posts often present what your business "needs" to do in a context-free manner.

If you are sitting on your thumbs looking for something to do, then definitely add a dashboard. If you're like me and have a backlog a mile long, maybe a dashboard isn't the best way to spend your time.

[roc]

> "maybe a dashboard isn't the best way to spend your time."

The point of the dashboard is that when you have one, you have actual accessible data from which you can plausibly determine what is the best use of your time.

e.g. If you can see that conversions are already coming in faster than the database is scaling then you know that you need to solve the scaling problem before you worry about A/B testing. Or vice-versa. You don't need to guess (as much).

[moe]

That's a rather simplistic view and a slippery slope.

Spending time on a pretty dashboard is one of the easiest ways to get drawn into vanity metrics and fapalytics.

Proper monitoring is important, but that usually means completely different things for different departments.

The CEO doesn't need to see database performance charts because he can't make sense of them anyway. Likewise the admin doesn't need to see conversion charts because they are not relevant to his work.

Trying to squeeze unrelated data into a common dashboard often leads to false correlations and entire herds of shaved yaks.

You provided a nice example for a false correlation yourself: The conversion-rate almost never relates to database performance in any meaningful way.

[TimGebhardt]

What about a small organization or a one-man e-commerce company where database performance affects conversions, and you're the one-and-only tech-guy?

[roc]

This was exactly my point.

Small shops have limited tech resources. Database scaling and implementing A/B testing suites can and have competed for those resources.

[pcopley]

I think the biggest benefit to the dashboard is (compared to something like A/B testing) it is much less iterative, so with the exception of adding another graph here or there, when it's "done" it's done. If you have the dashboard at all, it continues being useful. I've never heard anyone say, "Finally! We're done with our A/B testing! On to the next to do item..."

[billpatrianakos]

I think it can be argued that a dashboard isnt as great as this post makes it sound. The implication is that there's one person or one team looking at the dash and making sure things are running smoothly. Instead you can break up that big dashboard into a series of smaller ones each being watched over by the specific team for which each dash applies to. If your company's teams all work well together then the suits can focus on business and everyone else works together to keep things working arguably more efficiently. It's like have decentralization of responsibility instead of a top down system where one person/group is charged with knowing what's going on everywhere at once.