KPIs are software

It’s easy to think of key performance indicators as a task to be tacked on to the end of a project. Rather, KPIs should be understood as a product like any other, and so:

…they need strategy

The person responsible for a product’s strategy will have specific hypotheses about what numbers they want to move. Key entities and concepts are described, as they will influence everything that follows.

…they need discovery

This is where the PM is responsible for choosing the right KPIs, i.e., building the right thing. Good KPIs clearly map back to strategy, like any feature. A metric that is interesting, but doesn’t map clearly back to strategy, is not a KPI.

…they need functional specs

A KPI needs a functional spec that is good enough for a developer to implement. It will describe concepts that exist in the world (users, profiles, jobs) and will not mention implementation details such as tables or columns.

….they need technical specs

The technical spec describes implementation details, and will illuminate where we need to collect more data or change our data model. (If you’ve ever tried to measure a metric, only to discover that we didn’t structure the data correctly, this will resonate.)

…they have a user experience

This is a big one. If a KPI isn’t widely usable, then it’s a tree falling in a forest. The KPI’s interface needs to drive engagement. It needs a designer.

…they need a schedule

KPI development takes more than zero hours. Plan for it.

…they need engagement

We need to measure how KPIs are used. We’ve built lots of lonely dashboard and forgotten queries.

After building a KPI, we ask: How many uniques are viewing this KPI? How many times a month? How many returning users?