[andraz]

I can't agree more. First you need a product that works at least for some users, then when you are expanding the user base it's time for dashboards.

Dashboard answers the question: Is my product right now working for my users?

Eventually it can also show trends in terms of resource usage, strange peaks, etc. But the primary function of dashboard is answering the question: "are my users getting the service?"

Additional note: dashboard works wonders for getting us - engineers - understand that there are real users out there right now and thus making us want to build even better product.

[viscanti]

This seems pedantic. Of course the product needs to work for some users before you can measure anything about it. Otherwise your dashboard is filled with zeros, which should be obvious because the product doesn't work for anyone (and isn't a product).

Once you've gotten to the MVP stage, you should be tracking the key metrics, and those should be easily viewable in some sort of dashboard. Tracking up-time (or if the service is working) is a small part of what should be measured. When you're just starting off, you need to quickly figure out if your market hypothesis is correct. You can't do that without data, and a dashboard is both easy to build and helps make more informed decisions for everyone involved.

No one is arguing that you should build a dashboard before you have a MVP. Once that happens, you need to be measuring things.

[njx]

Dashboards are not just for "Is my product working for my users?"

They have variety of purposes. For e.g our webapp is an open book, we display live dashboard (https://my.infocaptor.com) of our very app itself because it is meant to be a dashboard platform

The main purpose of dashboards is to keep a birds eye view and take action when something is off.

Don't track metrics where you don't have time or resources to take action against.