You’ve identified a problem to solve. You’ve collaborated with your team and stakeholders to come up with a set of well-written objective and key result statements as your goals. You set off to run your early product discovery efforts. Within the first couple of sprints you start to get a sense that something’s not right.
OKRs are assumptions
They are based on the best information you have at the moment
- You are assuming certain customer behavior changes will happen if you build and design the right set of features
- As much as your solution hypotheses can be wrong, sometimes it’s the goals that you’re targeting that are wrong
This is a feature of OKRs, not a bug
More frequent and transparent check-ins
- Stakeholders can offer suggestions, direction, and insight from their broader perspective about ways the team can keep trying to hit their goals
- If the evidence overwhelmingly challenges the validity of either our objective or our key results then they must change
Having the tough conversation
Approaching your stakeholders with a request to change your goals can be a daunting task, if not a terrifying conversation for some teams. To maximize the chances of success, approach the conversation in the following ways:
- It should never be a surprise. The onus is on you and your team to continuously share learnings, decisions, and risks with your stakeholders.
- Bring the proof – a well-designed presentation of the data you are using to make the request and suggest alternatives
- Know the cost of not changing course – know how much more work is at risk if you maintain the current trajectory
