Lessons Learned in Product Okrs

OKRs can be done brilliantly and can become counterproductive bureaucracy. The difference isn’t in the framework itself - it’s in how teams implement and use it. The first time I ran OKRs for a product team, we hit every common pitfall. Here’s what I learned.

Why Most Teams Get OKRs Wrong

Confusing Objectives with Tasks

The most common mistake: writing task lists and calling them objectives. “Launch new feature” isn’t an objective - it’s an output. “Reduce customer acquisition cost by improving conversion” is an objective. The difference matters enormously.

At Google, objectives answer “what do we want to accomplish?” Key results answer “how will we know we succeeded?” If your objectives read like a project plan, you’re doing it wrong.

I learned this painfully when our team’s OKRs were essentially a roadmap with measurements attached. We hit every key result but didn’t move the metrics that mattered. We’d optimised for completing tasks, not creating outcomes. That quarter taught me that well-crafted OKRs fundamentally change what you focus on.

Making Key Results Too Easy

OKRs are meant to be aspirational. If you’re consistently hitting 100%, you’re not stretching. Google aims for 60-70% achievement - that’s considered success. Consistently hitting everything suggests you’re sandbagging.

But this is culturally hard, especially in organisations that punish missed targets. At one company, we tried ambitious OKRs and got dinged in performance reviews for “only” hitting 65%. The next quarter, everyone made their OKRs easier to hit. We’d optimised for looking good rather than achieving ambitious goals.

The lesson: OKRs only work if leadership genuinely embraces stretch goals and doesn’t penalise teams for ambitious failures. Without that cultural foundation, OKRs devolve into complicated KPIs.

The Anatomy of Good Product OKRs

Objectives Should Inspire

A good objective is aspirational and clear. It should be obvious why it matters and inspire the team to achieve it. “Become the best product for remote teams” is vague but directional. “Improve our NPS from 42 to 60” is measurable but uninspiring.

“Make payments invisible” or “Become the backbone of internet commerce.” These paint a clear picture whilst leaving room for creative approaches to achieve them.

When crafting objectives for my team, I now test them by asking: does this make it clear what success looks like? Does it inspire effort? Will it guide daily decisions? If not, I iterate until it does.

Key Results Must Be Measurable

If you can’t objectively determine whether you hit a key result, it’s not a good key result. “Improve user experience” is too vague. “Increase average session time from 8 to 12 minutes” is specific and measurable.

Don’t leave room for interpretation. Either you hit the number or you didn’t. This clarity eliminates debates about whether you “sort of” achieved something.

The challenge is choosing the right metrics. At one company, we optimised for signup numbers and hit our key result spectacularly. But retention plummeted because we’d prioritised volume over quality. The key result was measurable but measured the wrong thing.

Balancing Input and Output Metrics

This is subtle but crucial. Output metrics measure business results (revenue, retention, NPS). Input metrics measure activities that should drive those outputs (feature launches, user research sessions, experiments run).

Good OKRs primarily use output metrics. If all your key results are inputs (“Ship 3 features” or “Run 10 experiments”), you’re measuring effort rather than impact. But pure output metrics can be frustrating when you’re working on long-term bets that won’t show results immediately.

I’ve found a balance: mostly output metrics with selective input metrics for strategic initiatives where outcome measurement is delayed. The key is being honest about which is which and why each belongs in your OKRs.

Common Pitfalls I’ve Encountered

Too Many OKRs

Teams try to capture everything they’re doing in OKRs. You end up with 7 objectives and 4 key results each. Nobody can remember them, let alone focus on them.

I think ideally product teams typically have 3-5 objectives per quarter with 2-4 key results each. This constraint forces prioritisation. If something doesn’t fit, maybe it shouldn’t be a priority.

If the team can’t recite the objectives from memory, we have too many. The exercise of cutting down to what truly matters is valuable in itself - it forces clarity about what we’re really optimising for.

Treating OKRs as Commitments

OKRs are not commitments. Commitments are things you’re confident you’ll deliver. OKRs should be ambitious enough that you’re uncertain you’ll achieve them. Confusing the two leads to conservative goal-setting and missed opportunities.

Amazon distinguishes between one-way and two-way doors. Two-way doors (reversible decisions) can be made quickly with less certainty. Product OKRs should mostly be two-way doors—ambitious bets you can adjust if they’re not working.

When I started separating “commitments we must deliver” from “ambitious outcomes we’re striving for,” it transformed team dynamics. Suddenly people felt permission to aim high without fear of failure for missing stretch goals.

Set and Forget

The worst OKR implementations: write them in January, check in December, discover you forgot about them. OKRs need regular review to remain relevant.

Review OKRs weekly, bi-weekly. Not formal meetings - just a quick check: are we making progress? Do these still make sense? Should we pivot? This frequent calibration keeps OKRs alive rather than letting them gather dust.

Usually, I run lightweight weekly check-ins and more substantial monthly reviews. The weekly cadence keeps OKRs top of mind. The monthly reviews create space to honestly assess whether we’re on track and whether the goals still make sense given what we’ve learned.

Making OKRs Work in Practice

Cascading Without Micromanaging

There’s tension between company-level OKRs cascading down and teams having autonomy to define their own. Overly prescriptive cascading kills ownership. No alignment creates chaos.

The approach that’s worked: company leadership sets high-level objectives. Teams craft their own objectives and key results that contribute to company goals whilst addressing their specific context. Leadership reviews for alignment but doesn’t dictate specific OKRs.

Connecting OKRs to Daily Work

OKRs fail when they feel disconnected from what people actually do. The best implementations make it obvious how daily decisions connect to OKRs.

I’ve started every sprint planning by explicitly linking stories to OKRs. “This feature supports our objective to improve retention by addressing the top churn reason.” If we can’t draw that connection, we question whether we should be working on it.

This practice forces ongoing prioritisation based on what matters most. Features that seemed important suddenly feel less urgent when you realise they don’t contribute to any OKR. That’s valuable signal.

Learning from Misses

When you miss an OKR, the question isn’t “who’s fault is it?” but “what did we learn?” Were the goals too ambitious? Did our strategy not work? Did external factors change? What would we do differently?

The retrospective after missing OKRs is often more valuable than hitting them. It forces honest conversation about what works and what doesn’t in a way that success rarely does.

I’ve learned to celebrate ambitious failures as much as conservative successes. A team that aimed for 100% improvement and achieved 60% probably learned more and accomplished more than a team that aimed for 20% and hit 25%.

Adapting OKRs to Your Context

Startup vs. Enterprise

Early-stage startups need flexibility. OKRs might change monthly as you learn what works. Rigid quarterly planning doesn’t fit that reality.

At early-stage companies, I’ve used OKRs as direction-setting rather than rigid frameworks. They guide prioritisation but adjust quickly based on learnings. As companies mature, more structure makes sense.

The key is matching rigour to context. Don’t force a framework designed for mature companies onto a startup finding product-market fit. Adapt the principles to your reality.

Remote and Hybrid Teams

Remote teams benefit enormously from clear OKRs because they provide alignment without constant synchronous communication. But they require overcommunication to stay top of mind.

I’ve found remote teams need more frequent, explicit check-ins on OKRs than co-located teams where alignment happens more naturally through casual conversation.

Key Takeaways

• Focus on outcomes, not outputs: OKRs should measure impact, not task completion. “Launch feature X” is an output. “Reduce churn by 20%” is an outcome.
• Make them ambitious but honest: Aim for 60-70% achievement. If you’re consistently hitting 100%, you’re not stretching. But stretch goals only work in cultures that don’t punish ambitious failures.
• Less is more: Limit yourself to 3-5 objectives with 2-4 key results each. If you can’t remember them, you have too many.
• Review regularly and adapt: Weekly check-ins keep OKRs alive. Monthly reviews create space to pivot based on learnings. Quarterly is too infrequent to stay relevant.
• Separate OKRs from commitments: Use OKRs for ambitious goals. Track commitments separately. Confusing the two leads to sandbagging or missed obligations.

Final Thoughts

OKRs are deceptively simple in concept and surprisingly hard in practice. The framework itself is straightforward. The challenge is cultural: creating an environment where stretch goals are celebrated, honest conversation about progress is normal, and outcomes matter more than optics.

I’ve learned that OKRs are a forcing function for the conversations teams should already be having. What are we trying to achieve? How will we know we succeeded? Are we making progress? Should we adjust course?

When implemented well, OKRs provide clarity, alignment, and focus. When done poorly, they’re bureaucratic overhead that distracts from real work. The difference comes down to whether you treat them as a tool for better decision-making or as a compliance exercise.

The best OKR implementations I’ve seen feel lightweight. Teams reference them naturally in daily conversation. They guide prioritisation without constraining creativity. They create alignment without killing autonomy. That’s the goal worth striving for.

Have questions or thoughts? Get in touch - I’d love to hear from you!