In this World Product Day talk from ProductTank Stockholm coach Roman Pichler shares his thoughts on setting effective product-related goals using OKRs. Plus there’s a bonus talk from Alexander Hipp who shares his learnings from challenger bank N26 and elsewhere on how to set up a team for continuous discovery.
- OKRs can be used to create product-related goals, but choosing the right goal for your product is more important than the specific goal-setting method you use
- Using a goal hierarchy model of cascading linked goals can help
- OKRs have benefits and drawbacks
- Take a collaborative approach and involve the right people in setting goals
Objectives and key results (OKRs) are a method for setting and tracking goals – an objective describes what is to be achieved while key results state how we accomplish the objective and allow us to understand how that objective has been achieved. Roman gives an example: an objective would be to increase engagement and the key results by a certain date show that active daily users increased by 20%, and session length increased by an average of 10%.
Roman then explains how OKRs developed and how, in the 1970s, the late Andy Grove introduced OKRs at Intel in order to align people and manage the company’s growth.
Start by working out what goals are relevant to product people, Roman says. This might depend on who you ask, but Roman has developed the goal hierarchy model of cascading linked goals below to help with this.
This is the first goal. It sits at the top of the hierarchy and means asking people to describe the ultimate purpose or positive change the product should bring about. This is a big goal that covers a five-year plus time period and isn’t measurable.
User and business goals
Next, think about the product’s value proposition and desired business benefits. Meeting these goals should help you progress towards the vision. Roman likes to capture these goals on a product strategy document like a product vision board. These goals are valid for a product lifecycle stage and should be revisited when the stage changes, says Roman.
This describes the desired benefit or outcome the product should create. Product goals should be specific and measurable. Roman likes to capture product goals on a roadmap, and look at them in a timeframe of between two and six months.
These are tactical, execution-focused goals, which are short-term, between one and four weeks.
Here’s an example:
- Vision: Help people to eat healthily.
- User and business goal: Reduce the risk of developing Type 2 Diabetes; create a new revenue source.
- Product goal: Help users to understand their eating habits and acquire an initial user base.
- Sprint goal: Validate that users are willing to share personal information when activating the app.
Product-related goals as OKRs
Roman then runs through how he would capture goals as OKRs in the healthy eating sample goal above.
Objective: Help people to eat healthily (vision).
- Reduce the risk of developing Type 2 Diabetes for males aged 40-55 (user goal).
- Offer an app that measures and records sugar levels in food, analyses eating habits and seamlessly integrates with leading smart scales.
- Create a new revenue source (business goal).
You can then use the business and user goals to create a product goal.
Objective: Help users to better understand their eating habits and acquire an initial user base(product goal).
- Offer an MVP that provides a healthy eating dashboard and integrates with leading smartwatches and fitness devices.
- Launch in Q1.
- Be ranked among the top 15 Diabetes apps six weeks after launch in the Apple app store.
Again you can use the key results above to derive OKRs for the sprint goal
Objective: Validate that users are willing to share personal information when activating the app (sprint goal).
- Have a product increment ready at the end of the sprint that implements user stories a, b, c, d and e, and that fulfills the definition of done.
- Conduct a usability test with six prospective users.
- The test results of at least four people are positive.
Benefits and drawbacks of using OKRs
On the plus side:
- OKRs deliver consistency, a consistent goal-setting method.
- Validation – OKRs encourage us to formulate goals in such a way that we can tell if they’re met.
- Allow you to create goal chains, so that a key result becomes an objective.
- Lack of visualisation. OKRs can be text heavy, and not always easy to process.
- A fool with a tool... Roman thinks that perhaps OKRs have been overhyped, when the issue is about choosing the right goals in product management and empowering product people to set those goals.
Roman says that OKRs can be happily used to create product-related goals, but choosing the right goal for your product is more important than the specific goal-setting method you use. Use OKRs if you find them helpful – if you don’t, why would you want to use them? If you’re forced to use them then there’s something wrong in respect of respect, empowerment, and trust.
You should take a collaborative approach and involve the right people in setting goals to leverage their expertise, create a shared understanding and secure strong support.
Don’t allow powerful stakeholders to dictate goals, and don’t broker weak compromises. If you feel you’re being forced to work towards a predefined set of OKRs then OKRs aren’t the problem, the problem is that you don’t have a choice.
Bonus talk on continuous discovery
In the second World Product Day talk from ProductTank Stockholm, Alexander Hipp looks at the six pillars of continuous product discovery. While delivery practices are well established in most companies, he says, continuous discovery is less well established, and he gives some pointers on how to rectify this, based on his experience at fintech N26.