Project success criteria in the form of OKRs (Objectives and Key Results) should be the driving force behind your project and product direction. They boldly state where you’re going and they give you metrics to judge when you’ve arrived.
Project success criteria should be fail-by-default. To succeed in an OKR you shouldn’t be able to sit on your ass and play defense.
Objectives like “don’t release any new bugs” make terrible OKRs. A guaranteed way to achieve that objective is to stop releasing software. But despite “no new bugs” making an awful OKR, it’s still an important measure of business health. It’s worth keeping an eye on.
There are plenty of metrics like bugs released (a proxy for code quality) which are important to watch but don’t fit well in OKRs. Rather than trying to wedge them into a container where they don’t belong, consider adding a second tool to your toolkit — KPIs (key performance indicators).
If OKRs give your teams direction, KPIs make sure nothing is going off of the rails. Practically any metric — site uptime, conversion rates, user retention — can be used as a KPI. KPIs are a metric that’s important to watch, but not something you’re trying to change right now.
Keeping track of relevant KPIs will help you uncover problems as they emerge. If you decide a KPI is out of line enough to justify investing in a fix, then it simply becomes part of an OKR. The passive KPI “Conversion rate — 5%” becomes the active objective “Double conversion rate by September”.
In a nutshell: Use KPIs to keep an eye on things. Use OKRs when you want to make a change.