When to Build a KPI Dashboard for Your SaaS Startup?

As a first-time founder and CEO of a SaaS startup, I made the mistake to only trust my gut and some qualitative feedback coming from our first users to take decisions in the early life of Gmelius.

Most product-centric founders do this very same error and postpone the development of an internal dashboard for their metrics. This article intends to explain why you should not delay the collection of your data, and introduces the architecture that now powers our own KPI dashboard.

During the first 7 months of Gmelius' life, we did not have access to any metrics besides the usual suspects, i.e., Google Analytics and Stripe. There were 3 wrong reasons for that.

1. We Were Growing Fast

When everything goes well, you don't feel the need nor the urgency to get a detailed view of what's going on within your solution. And indeed, why bother since it looks like you already took the good decisions. This is a vicious circle which reinforces the idea that you should only trust your "gut" and creates a bias towards a specific type of qualitative data.

Now and very interestingly, your users may say things that don't correspond at all with the actual use of the product. One of the numerous things I learned in the early months of Gmelius is that you should always prioritize your quantitative data over any other source of information when taking a product-related decision.

Those data will help you discern patterns in terms of usage, identify pain points (e.g., on-boarding, UX), and will make possible to measure the effects of every change you make within your product -- something which is impossible to achieve with qualitative feedback.

2. We Were Not Planning to Raise Funds in the Short-Term

Another common misconception among neophyte founders is that a KPI (Key Performance Indicators) dashboard is only necessary when you start your first fundraising campaign and thus talk with potential investors.

The origin of this belief comes from the fact that most of the literature about startup metrics has been written by investors, and not founders.

Quite unfortunately, this led to a situation where we think - as CEOs - that we only need to know by heart a few key metrics (e.g., MRR, churn rate, LTV/CAC, etc.) in order to "sell" our companies to investors.

Of course, this is very wrong since those figures are only snapshots of a company at a very specific point in time. KPIs should not be seen as static numbers but as ways to measure the effects of your past choices on the current and future performance of your startup. Whenever you present your solution to an investor, ensure to detail your decision process and show (if you can) your company's dashboard explaining why you decided to focus on specific metrics.

3. We Already Had Too Much on Our Plates

Growing a [SaaS] startup is extremely challenging. You need to transform an idea into a product hundreds of thousands of people will be ready to use (and hopefully pay for) with scarce resources, both in terms of human and financial capital.

As founder, the most important daily task is to prioritize the items on the company's to-do list. Unfortunately, there is an inevitable trade-off between developing more features or building a framework for your own metrics, and the latter is rarely preferred over the former.

Postponing the inclusion of metrics within your product - and thus the access to tangible data about its use - may lead to wrong choices in terms of features' prioritization. As a startup, it's vital to identify a demand and match it as soon as possible in order to survive. If you don't have the means to observe and measure how your first users behave, you will endanger or slow down the path to market fit.

Probability to reach Product / Market Fit = KPI + MVP

To summarize, there are no good excuses to delay the creation of a KPI dashboard! The first weeks and months of a startup are so crucial you cannot leave the destiny of your company to luck or your gut.

Now, developing your own architecture to view and play with important metrics will take some time. Of course, there exist 3rd-party tools that can make your life easier but they all have their Pros ans Cons you should be aware of beforehand.

Subscription Metrics

Those are services which will offer nice dashboards and relevant unit economics about your revenues by processing data coming from your Stripe account for instance. Examples of such tools are Baremetrics, ChartMogul or ProfitWell.

Pros

1. Easy to set up and use

Cons

1. Limited view due to the focus on paid subscriptions
2. Quickly expensive

Besides the price, their main disadvantage is that they don't offer a global view of how your users behave within your product, making difficult to understand what impacts your revenues, e.g., which features convert more.

Usage Metrics

To get a better visibility about the usage of your product (e.g., build a table about the retention of your users, identify what mechanisms lead to a conversion), you can sign up for solutions such as Mixpanel, Amplitude or Firebase (mobile app) which all offer product analytics.

Pros

1. Powerful analytics

Cons

1. Difficult or impossible to export your data
2. Expensive

Here, the main problem is that you cannot retrieve your data, making difficult the switch to your own structure when your company is at a more advanced stage.

Having tried a few of the above services, we came to the conclusion it was a smarter move to develop our own dashboard for Gmelius. That's what we did using Stitch to regroup all our different sources of data, Google BigQuery to store them, and Metabase to power our internal KPI dashboard. This architecture offers a cost-effective, easy to maintain, and complete view of our different metrics. Part 2 of this series of posts will detail it.