A rant on OKRs and how to overcome common fails

Most people in product organizations know or claim to be familiar with the concept of OKRs (Objectives and Key Results), however why are they often poorly written or even hated? Either too vague, leaving room for misinterpretation or missing true impact, becoming irrelevant. I believe one of the main reason is that crafting well written ambitious measurable goals is not that easy. Additionally, OKRs force teams to make success explicit, and people often mistakenly associate the success or failure of a product initiative with personal success or failure, leading them to keep goals intentionally vague. I see them more as an ambitious and motivating target to aim for, which set the bar high.

If you don’t yet have so much experience working with the OKR framework, it might require a few iteration cycles to reach a good quality, but no worries even in bigger famous big tech companies OKR aren’t always perfect. In my current company it took quite some time to get everyone onboarded and fluent in using OKRs, especially crafting a collaborative top-down-bottom-up process and getting all departments embracing the OKR culture and language (if you are curious about how to set OKR for UX work read also this article I wrote: Making UX work measurable using OKRs otherwise stay here for juicy OKR pitfalls 😄).

Here some risks and errors I’ve done myself, heard from peers in the field or noticed, which you may encounter in formulating OKRs.

Common fails in defining OKRs

• Vague Objectives: e.g., “Enhance user experience” = unclear what success looks like and for which user and product.
• Unmeasurable Goals: Objectives or key results without clear metrics or deadlines.
• Disconnected from Impact: Teams may successfully achieve their OKRs on paper while failing to create meaningful value for users or the business (typical in output-focused OKR).
• Output-Focused Key Results: e.g., “Launch new onboarding screen” instead of measuring user impact.
• Vanity metrics in Key results: e.g., “Increase page views by 50%” or “Reach 10,000 app downloads” without tracking whether users are actually engaged, converting, retained, or achieving value from the product.
• Lack of conversations around impact and measurable results: a lot of time is spent on defining goals, but nobody is tracking data or monitoring them and discussing results after the product is launched.

What is the advantage of well crafted clear goals?

I often hear people in disbelief of the value of OKR, or managers fed-up with the OKR framework and process effort. Most of the time it’s because of how they’re experienced in reality. If the extra work is generating an outcome nobody uses, the why behind them isn’t clear, leadership isn’t engaged, goals are too many and used as a top-down imposed control on performance, nobody is going to be excited about setting goals like that.

Well-crafted goals (like strong OKRs) force teams to define what success actually looks like — not just activity, but measurable impact. Without that clarity, teams default to vague intentions, misaligned priorities, or outputs that don’t move the business.

They also create a shared language across functions. When goals are specific and measurable, Product, Design, Marketing, Engineering, Data, and Business teams can align on the same outcomes instead of optimizing locally or interpreting priorities differently.

Good goals enable better decision-making. Teams can prioritize, say “no” more confidently, and evaluate trade-offs based on impact, instead of opinion. Poorly defined goals, on the other hand, lead to constant re-prioritization and unclear ownership.

Best practices in crafting and aligning OKRs

To master OKRs do this:

• Focus on outcomes, not outputs or tasks
• Strive to make key results quantifiable
• Link objectives to user and business goals
• Keep the number manageable: 3–4 product or business, 1–2 ops-related OKRs
• work on the collaboratively incorporating feedbacks
• Shape a process including rituals to draft, craft, finalize, share and monitor OKRs
• Track progress weekly or monthly and revisit or adjust quarterly

OKR common fails and best practices

Ensure OKRs are outcome-focused and measurable

Define OKRs around the change you want to see for users and the business, not just the work being delivered. Strong OKRs use measurable indicators such as task success rate, conversion, retention, adoption, revenue impact, support ticket reduction, or customer satisfaction metrics like HaTS (Happiness Tracking Surveys). For example, instead of “Redesign the onboarding flow,” use “Increase onboarding completion from 62% to 80%” or “Reduce first-week churn by 15%.” Similarly, rather than “Launch a new analytics dashboard,” define success as “Increase weekly active usage of reporting features from 30% to 50% among logged in users.” Avoid vague objectives like “improve usage” or “enhance platform performance” unless they are tied to clear, observable business or user outcomes.

Use UX research and business metrics to validate assumptions and prioritize a set of goals

Use UX research and business metrics to identify the most valuable problems before defining OKRs. Qualitative insights uncover unmet user needs, while quantitative data helps assess scale, impact, priority, and urgency. This keeps teams focused on real user and business outcomes rather than assumptions or stakeholder opinions. Outcomes-driven OKRs should describe the change you want users to experience, such as reducing friction, increasing confidence, or improving decision-making efficiency.

Keep the number of OKR manageable

One of the core principles repeated across OKR literature — from Measure What Matters to Radical Focus — is that OKRs are fundamentally a prioritization framework, not a task management system. This is why most experts recommend limiting OKRs to roughly 3–5 objectives per cycle, typically over a quarterly period. The reason is simple: if teams try to solve too many problems at the same time, focus becomes fragmented. Energy gets spread across competing initiatives, and teams rarely have enough time to experiment, learn, iterate, and refine solutions until meaningful impact starts to appear. Teams that overload themselves with objectives tend to fall back into a delivery-factory: shipping many initiatives quickly, but without enough depth to validate whether any of them actually moved the needle for users or the business.

Collaboration between product managers, UX, engineers, data, marketing, and business stakeholders

Effective OKRs are rarely created in isolation, that’s why I suggest to craft OKR in a cross-functional collaborative process that reflect shared priorities, rather than siloed efforts. This builds alignment and ownership from day one. What I’ve seen in my company is that making the process collaborative and transparent helps surface risks and conflicting priorities very quickly. As soon as early OKR drafts are placed on a Miro board, discussions naturally emerge around the goals we are trying to achieve, the assumptions behind them, and the trade-offs between initiatives. It also pushes teams to ask strategic questions to management early on and identify dependencies between teams before execution starts, instead of discovering blockers halfway through the quarter and risking not achieving meaningful results.

In our case, we also decided to work with a two-layer OKR structure: one set of OKRs at company level and another at team level. This allows multiple teams to contribute to shared company objectives while still defining own measurable outcomes and initiatives that they can control. It creates much better visibility into how each team’s efforts and metrics influence the higher-level KPIs selected at company level, making alignment and accountability clearer across the organization.

2-layers-OKRs: company and team level

Tracking Progress and Communicating Impact

Track OKRs continuously, not just at the end of the quarter. One of the most common failure patterns in OKR practice is treating them as a static reporting exercise instead of a living decision-making framework. Use analytics platforms such as Google Analytics, Mixpanel, Amplitude, Tableau, or Contentsquare together with UX and customer feedback signals like SEQ, CSAT, or HaTS surveys to create regular visibility on progress. Short review cadences (weekly or biweekly within the team and monthly at company level) help teams spot stalled or declining metrics, reassess assumptions, and adapt before problems become expensive.

When reporting on product and UX results, translate them in terms of business impact. Rather than reporting that “a new feature was launched,” show how the solution reduced churn, increased conversion, shortened completion time, lowered support requests, or improved retention. Strong OKR cultures connect everyday product and design decisions to strategic outcomes, making teams feel their daily work counts for the company and the customers, ultimately influencing employees motivation and retention.

If you craft and maintain OKRs aligned with cross-functional partners, they become more than a measurement tool: they drive clarity, foster collaboration, and position product and UX work as a strategic force in delivering value.