One of the critical skills that a product manager must possess is the ability to define what the success of their product will look like. As the ultimate owner of a product, PMs are responsible for ensuring the success of their product and also communicating what that success (or lack thereof) will look like to the organization as whole.

In order to do this, PMs must define certain metrics prior to launching a product or feature, that they will monitor and analyze over the lifetime of the product. These metrics are critical for a few reasons, namely:

1. They are the metrics which PMs will rigorously optimize for in future product enhancements and iterations
2. As they are used to judge the ultimate success of any product or feature, it is on this basis that future funding and resource allocation may be given, or taken away.

Not only do PMs have to define the metrics, but they also have to project the actual numbers that they would like to hit with every metric they track. This is a somewhat nebulous exercise so in order to do so effectively, PMs must posses a deep knowledge and understanding of their space and competitive landscape, a clear view of differentiated features in their product, and past experience that could be pertinent to the upcoming product or feature launch.

The metrics that I have used to define success with my products are called KPIs or Key Performance Indicators. When I define KPI’s and forecast my numbers, I like to keep three principles in mind that help shape effective metrics.

KPIs must be Simple

Software products are complicated and the number of interactions your users can have with your product are vast. As a result, the metrics that you could hypothetically track are also vast and could become quite complicated.

When defining KPIs however, I like to think about the singular, core problem that my feature or product is trying to solve for users, and zero in on simple metrics the help me understand whether or not we are solving that problem.

I launched an application called Rhapsody SongMatch early last year. It allowed people to identify any song currently playing out loud much like Shazam. It also had discovery features that would allow users to explore similar artists, similar tracks, and editorial posts for matched songs and artists.

While I was interested in how much users were interacting with the discovery features, the core problem we were trying to solve was to help users identify the one song that was currently playing. As a result, I focused my KPIs around the singular interaction of matching a track. A few specific KPIs were match attempts per user and successful match rate.