OKRs when your products are still in alpha
How to implement successful OKRs for development teams
If you are reading this, you’re probably part of a startup that’s tipped to be the next unicorn. You’re in a rockstar development team, the company has a clear vision and a detailed roadmap to make a once-in-a-generation product. Your team just needs to sit down and make the thing.
However, you are questioning your management’s OKR [1] approach, as you already have your hands full with your roadmap and milestones for the next three months. It’s beginning to feel like OKRs is just an extra layer of reporting, a distraction to avoid until your product has measurable customer metrics.
But what if I told you there are benefits of using OKRs when the product is still in alpha?
OKRs isn’t a management exercise. It’s a framework to align the company’s priorities and focus on achieving these together. This means your entire company is pursuing the same north star and makes decision making easier when working with other teams. It ensures everyone is working towards a common goal, and the right decisions will be the ones taking you to that goal.
Within our own team at tb.lx, a corporate startup developing sustainable transportation solutions, it gives developers a clear vision of what their work is going towards. Well-defined OKRs connect what they’re doing now to the bigger picture and the future of the company.
By making the goals strategically difficult, everyone will push themselves and think of ideas that go beyond “business as usual” to meet the company’s targets.
Furthermore, making every goal’s progress visible makes it clear to everyone if the company is on track to meeting its objectives. If something needs support, it becomes immediately evident, and the company can take action accordingly.
Why would you want to delay all of these collective benefits just because it would be easier to measure results in the future?
Crafting meaningful development OKRs before having your first customer
If your goal is to release a product, try thinking about the following questions before moving into making formal OKRS.
- What do you want the customer to be able to do at release?
- What does that successful product need to do to achieve that?
- What technical specification does it need to excel at this task?
- What will you observe if your objective was a blinding success?
Now build your OKRs around this frame, the Objective being what you want to have accomplished in three months. Then dig into KRs, the measurable, concrete numbers that tell you if you’re making the impact you want. It is true, without customers, you don’t know how well your product is addressing their needs. So, here are three things you can do if you are in this boat;
1) Fight to get customer feedback. Really try to convince your stakeholders to get real customer input into the product. Release an alpha to close customers so you can track what new features do to their behaviour, or get permission to run live demo’s with your customers and workshop your new features with them;
2) Measure technical specifications the product would need for a customer to objectively love your product. These can be benchmarked values comparing to your competitors or from your own research. Then tailor your product to meet these needs;
3) Milestone metrics. You know exactly what needs to be made, so put a date on it and track your progress in a way that is visible to the company. When crafting this, try making it so that you’re solving a customer problem or enabling a new activity — for instance, instead of naming it “release XOO v3”, rephrase it to “Give our customers a place to manage their fleet”.
As you’re making these OKRS, avoid the following common pitfalls:
1) Be careful not to let this OKR just turn into a detailed product roadmap for the next three months;
2) Don’t allow milestone metrics to become the norm. Think deeply about which customer metrics really matter, and this should be implemented wherever possible.
Half-hearted OKRs won’t get you anywhere
I’m assuming that you’re on board with OKRs now. However, we still haven’t addressed the issue that it is difficult to create metrics that evaluate customer impact when you don’t have a big customer base using your product yet. A common pitfall is then to make half-hearted OKRs.
[Attention! This is an example of doing it wrong] For example, to meet your product deadline, your team decides it just needs to ship better code faster. Using relatively objective and quantifiable metrics of improvement will help the company. For example:
Objective: Outstanding code development speed
Key results:
- Improve sprint velocity from 25 -> 35;
- Release 25 new features;
- Reduce code complexity in half as measured by Halsteads complexity measure.
On the surface, these look great. However, there is a glaring issue. Is your company’s focus for the quarter to become a code factory and operationally more efficient? NO. Your focus is to release a meaningful product, and your OKRs should reflect that. It should make your priorities clear to your team and those around you, otherwise, it doesn’t add value.
An example of “Good enough” OKRs while your products are in Alpha
Objective: Developers on our platform can stream live data from their trucks so that they can access to value adding analytics from a trucks trip
Key results:
- The platform can give a ML-based driver score to a trip which is tested on 20 truck drivers;
- A truck can stream live data into our architecture by March 31st;
- The service has an uptime of 99.9%.
KR1: This is an example of a “good enough” metric for a feature before you can objectively measure the impact it has on your customer. It is a commitment to continuously getting customer feedback on your product and gives some indication that you’re building something your customer wants.
KR 2: This is an example of a milestone metric. Though It might not be giving the customer value yet, it clearly states what the developers are working to achieve this quarter. By writing down this milestone, it acts as an unmoving focal point for the development team to rally behind. It also lets the other employees in the company see how progress towards this vital building block is going.
KR3: This is an example of you knowing what your customers value but not knowing where to set your target. Your team deems it sufficient to be the market leader in reliability and so you target 99.9%
Conclusions
I may not have given you a list of perfect examples to copy, and I also haven’t given you something that’s exactly aligned with OKRs as done by Google. But I hope to have given you a practical middle ground that will meaningfully bridge you over until you can truly measure what matters.
Kudos to our CTO, Nuno Carvalho, for inspiring me to write this post. We butted heads a lot during the latest OKR cycle, and his logic really forced me to think hard on how to make OKRs work for tb.lx’s unique situation as a corporate startup.
Footnotes
[1] OKRs: Objectives and Key Results (KR), is a goal setting tool which defines a company objective and uses quantative metrics to measure progress towards meeting this goal. It’s simple to know but complex to nail and I recommend reading more here
Dillan Patel is doing the Daimler INspire Program, and worked as a Product Trainee at tb.lx in Lisbon, Portugal.
