How OKRs work at accuRx
Like most organisations, accuRx has developed a way of using OKRs that work best for us, and is slightly different from the textbook. We’re sharing here how we use them as we think it’s interesting and might be useful to others too!??
Setting direction
At accuRx, writing focused OKRs for your team is common, and for Product Teams is a key part of the Product Manager’s responsibilities. We see OKRs as an important way of letting other parts of the organisation know what each team is focusing on, allowing them to flex their goals to identify how to support the best they can. We use this diagram to show how OKRs fit together with a product Vision and Roadmaps in order to give a clear direction of travel (HT @grannellmat for artwork).
7 Week Delivery Cadence
All organisations have their own cadence, whether it be a 2 week scrum cycle, quarterly planning or something else. We’re in the “something else” bucket. We run a 7 week “cycle,” with a full planning week, followed by 6 weeks of “delivery”. There is still plenty of research, design and testing happening within that 6 weeks, but we’ve generally found this is just enough time to build something that works; whether that be an MVP, a redesign, or doing the work necessary for scaling up a product launch nationally. Therefore our OKRs, created during each planning week, are normally for 6 weeks worth of work. However I believe the advice below is applicable for the majority of people setting OKRs.
6 Top tips when writing OKRs
We spend a lot of time reviewing our OKRs and giving feedback to each other to ensure that teams are set up for success; so I thought I would crystallise some of the things we discuss most often into some “Do’s” and “Don’ts”:?
Do
- Be specific on what you’re planning to do and why. Our OKRs outline what functionality we’re building and what user value we will deliver in the process. For our Objective, we generally use the format 'build X SO THAT user benefits Y'. We want to make sure that we are clear what user value we will deliver, and have a good answer to the blunt question of “Who cares?”
- State where you are currently (with respect to your KRs). If we’re planning to improve a metric, we’re clear where we stand currently with respect to that metric. If you don’t do this it’s impossible for everyone else to know how ambitious you’re being and therefore you’ll likely be inundated with questions for more information.?
- Ensure that KRs are milestones on the way to the objective. Key results are there to keep you on track, they are a way of answering the question “How is your team doing?” We want to know that if we hit our KRs, that we’ve definitely hit our objective. In some scenarios Key Results (KRs) might show progress along a single metric: KR1 = 50%, KR2 = 75%, KR3 = 100% and in others it might be different parts of the same journey: KR1 = Activation%, KR2 = Adoption%, KR 3 = Retention%. Either way, we know that just like dominoes, our confidence of hitting our objective will increase as we hit each of our KRs, and once KR3 is complete, we’ve definitely hit our goal. We aim to hit our KRs in order, but of course don’t be too rigid :)
Don’t?
- Try and capture all the work your team is doing. This is the most common trap to fall into and will make your life really hard. Sometimes you might have 3 things you really want to do, so instead of saying what is most important and making a OKR out of it, you will try and squeeze it all together by having a KR per thing. This might make your team happy, but all you’re doing is kicking the can down the road and until your next planning session. By squeezing too much into your OKR, there is a good chance your KRs will end up competing with each other, as they each have different aims - this will make prioritisation impossible. We aim to have one OKR per team, per cycle; it is the most important thing you are working on, not everything you are working on.
- Get caught up in whether you should be hitting 70% of your OKRs. In my experience this discussion is rarely fruitful, as you’ll only know what works for your organisation through actually using OKRs for a few cycles. If like us you’re using OKRs to signal your priorities to the rest of the organisation, and you’re using them to let people know a rough timeline of when you think you’ll be able to hit them, then saying “well we only expect to hit 70% of them” when are they missed, is not going to lead to strong inter departmental relationships.?Of course teams will miss their goals occasionally, you’re asking them to guess how much they can get done in a given amount of time, but when they are missed everyone should have an honest conversation as to why. There could be a whole list of reasons, ranging from “it was far more complex that we hoped” to “a member of our team got sick and missed the cycle”; either way, saying “well we are only meant to hit 70% if we’re being ambitious” is not going to help. We expect teams to hit their objective and all of their KRs, unless they explicitly state that Key Result is going to be a stretch, letting other teams not to count on it. That way other teams can bet on it and prioritise their own work accordingly - after all, OKRs should be a way of aligning teams in an organisation around common goals.
- Force a delivery goal into the format of an OKR. Call a spade a spade, if you already have a solution and you’re going to build it, just say you are! OKRs are designed to talk about the goal, not the work itself, because most likely you don’t know exactly what you plan to build in order to get there. However sometimes you have crystal clarity on what you need to build because you have thousands of customers hammering support each day to tell you. In these cases, just state what you’re planning to build (using a roadmap/prioritised list), you don’t need an OKR.?
Examples?
These are real examples that we don’t believe are either “amazing” or “awful”. We share them as they helped us learn and therefore might be beneficial to others as well. They have not been edited, but we have added explainers to help you get the gist of what is going.
Decent effort
Allow Patient Triage* [PT] responses to be saved to the record SO THAT users don’t have to manually copy & paste from email.
- 100% of PT messages are received via the inbox
- 70% of PT message are saved to record
*Patient Triage allows you to contact your GP via a simple online form. That communication comes into the accuRx inbox, which GP staff interact with and in most cases, save to your medical record. In order to save a communication to a patient’s record, it must first be accurately matched to the correct patient, which is the main technical challenge here.
Could have gone better
Make Patient Triage scalable, reliable & easy to use SO THAT we can achieve our commercial goals.
- Online volume in beta practices accounts for 10% of inbound
- Demonstrate that we can onboard 160 practices in a week
- Product NPS score of 70%
- Securing confirmation of payment for practices in at least 8 CCGs**
- =80% CCGs who are asked to approve payment to accuRx say 'yes'
- A waiting list of 1,300 practices
** CCG stands for Clinical Commission Group.They are responsible for buying software (amongst other things) on behalf of healthcare providers (such a GPs) in the UK.
Feedback?
As everyone does OKRs with their own twist, it might well be that you do things differently and want to tell us about it! That is awesome and just the kind of vigorous debate we love at accuRx, so please let us know your thoughts :)
