Our own product/design team were on a call with a UX expert this week. We were asked “whats your key usage metric?”.
There was a cavernous pause until someone said “perhaps David can answer that”.
It was a humbling moment. Despite being a company that talks about: product management, user journeys, goals, “aha moments” and OKRs – we could not enunciate an answer that should really be a team mantra.
As I opened my mouth to respond, I realized our OMTM (one metric that matters) is too glib and too obvious.
Laughably obvious.
What is our OMTM?
MRR: Monthly recurring revenue and MRR month-on-month growth are the metrics that investors want to see. But that is totally wrong at an execution level.
Many small-to-mid size teams (including us) get pulled in many different directions. It’s the CEO and the Product Manager’s job to keep re-iterating tangible goals that a team can execute on.
Patrick Collins explained how Zip don’t use roadmaps but 90-day OKRs.
To focus product teams, inherit from a larger business metric like MRR:
Breaks down to at least, some macro areas:
- Acquisition of Triallers (marketing team)
- Trialler to Customer Conversion (Product Team, Customer Success)
- Customer Retention (Product Team)
- Plans and billing methods that work for customers (VP Product, VP Sales)
Then a product team would negotiate with the business that: “Trialler to Customer Conversion” can be expressed as a 90-day OKRs. For example:
“Increase Trial to Paid conversions by 10%”
But this may be still too abstract for the product team – they could formulate more granular metrics:
“20% increase of triallers complete and preview their first guide within 1 day”.
We now have a clear answer for “what is your key user activation metric?”
The team runs experiments focussed on hitting this goal and is a mantra for daily sanity checks on tasks.
How Contextual helps
Contextual guides allow you to:
- Target specific users. For example you may have several personas that connect into your App. You can guide each differently.
- Track their interaction with the guide (did they use it or dismiss it)
- Tie the guide to a Goal (your Product Metric).
- Do this without writing code. By having a no-code approach to helping user engagement with your product – you can keep your engineers focussed on features and fixes.
Proxy Metrics
Gibson Biddle, former CPO at Netflix has a 2019 series that is worth reading multiple times. Specifically relating to Proxy Metrics his piece on “How to define a metric to prove or disprove your hypotheses and measure progress”.
He covers how you can map from a higher level business metric to a product level proxy metric.
In the case above, even “Trialler to Customer Conversion” is large and too abstract for a product team, so breaking this down to “20% increase of triallers complete and preview their first guide within 1 day” is making a hypothesis that it “will move the needle” on the more abstract metrics.
I won’t reiterate Gibson’s full epic post but he suggests:
- Is measurable.
- Is moveable.
- Is not an average.
- Correlates to your high-level engagement metric.
- Specifies new v. existing customers.
- Is not gameable.
He also cautions that its not a quick fix: “we made decisions quickly, but isolating the right proxy metric sometimes took six months.”. Keep that in mind, you will be iterating on your metrics and the hypotheses that formed them.
