Companies and products suffer when there is a lack of clarity and agreement around which metrics matter. Capturing and reporting on more metrics isn't always better. Measuring too many metrics at once creates a lack of focus which translates to weaker products.
The One Metric That Matters (OMTM) is a minimalist approach that helps achieve this goal. OMTM is a mindset and guideline more than a rule. In practice, focusing on a single metric may be too restrictive to result in actionable data but this approach can be modified in a couple of useful ways. One is to identify a single metric for each facet of a product. Another is to focus on a single metric for a day, a week, or a month and optimize performance based on that single metric over that period of time.
Some typically software product metrics might include:
Monthly Active Users
Daily Active Users
Average Session Time
Average Revenue per User (ARPU)
Customer Lifetime Value
As well as metrics that answer questions about feature usage:
How often is each feature being used?
What feature sets tend to be used by the same people?
How long are users spending on each feature?
Where do users get stuck and abandon the product?
Which features are your engaged users using most?
Who abandons the product and who keeps using it?
Are there seasonal trends in usage?
The primary purpose of the OMTM is to ensure the team has focus. Similarly, it's also necessary to keep data dashboards simple. Report only those metrics that help the organization achieve its product goals. Ask, "Will these metrics help the team arrive at an actionable decision?" Be sure to keep the focus on the product and avoid tracking metrics that fall outside your control and responsibility (such as sales or marketing metrics)
Don't wait to identify your KPIs. Start measuring metrics at the launch of your product. This means defining your key metrics well in advance of a product launch. Some metrics may not be measurable if you haven't built a specific reporting mechanism into the product from the start.
Metrics are just a starting point. They identify what is happening with the product. but analysis is required to figure out WHY something is happening so that the right improvements can be implemented.