OKR case study exercise for product managers

The scenario

You have just joined a developer productivity tooling company as Senior Product Director, in the first week of a new quarter, and your predecessor left behind a set of OKRs approved in a rush right before they quit. The company runs at $1.2 million in monthly recurring revenue across three product teams, and two problems are already visible: activation rate dropped from 42 percent to 31 percent last quarter, and two enterprise accounts churned citing missing collaboration features, one of which sales has already promised a major prospect will ship by end of quarter.

What you inherited is not really a set of OKRs so much as a list. The three company objectives read like slogans: making the company the best tool on the market, shipping what customers keep asking for, growing revenue and expanding into new markets. The eight key results underneath them are a mix of real outcomes and disguised tasks: hiring three engineers by a date, running a fixed number of customer interviews, completing a documentation overhaul, alongside genuine outcome metrics like increasing revenue and improving churn. And two teams, Onboarding and Core Product, have each independently submitted the same two engineers as their top priority for the quarter, for two different, genuinely important reasons.

The CEO expects a clean OKR framework presented at the all-hands in five days.

What you are asked to do

The exercise moves through five connected steps:

• Classify each of the three objectives and eight key results as good, fixable, or bad, with a one line reason for each, distinguishing a real outcome from an output disguised as one.
• Rewrite all three objectives so each is qualitative and directional rather than a metric, specific enough that someone could actually argue against it, and achievable within one quarter, while keeping the intent of the original.
• Write two strong key results for each rewritten objective, each with a stated baseline, a target, and a deadline, with no tasks or outputs allowed, only things that change in the world.
• Resolve the conflict between the Onboarding and Core Product teams over the same two engineers, make the call, and specify how the team that loses the resource should adjust its quarter's OKRs.
• Design a weekly check-in and a monthly review, specifying who attends, the format, what gets reported, and what decision actually gets made in each one.

What a strong answer covers

The exercise's own objectives are what a strong submission has to satisfy:

• Does the classification of the inherited OKRs correctly separate a genuine outcome, like a churn or revenue target, from a task or output dressed up as one, like a documentation project or a hiring count?
• Do the rewritten objectives keep the original intent while becoming specific enough that a reasonable person could disagree with them, rather than staying as unfalsifiable slogans?
• Does every new key result include a real baseline, target, and deadline, with tasks correctly excluded even when they sound productive?
• Does the resource conflict resolution name a clear decision and specify exactly how the losing team's OKRs change as a result, rather than leaving that team's quarter undefined?
• Do both review rituals name a specific audience, format, and the actual decision each one produces, so that neither one could exist without producing something actionable?

Skills this exercise practises

Telling a real outcome apart from a task that only looks like progress. Rewriting a vague company objective into something specific enough to hold people accountable to. Resolving a real resource conflict between two legitimate priorities and communicating the trade-off to the team that loses. Designing a review process that produces an actual decision instead of a status update nobody acts on. These map onto the bootcamp's own curriculum on objective crafting, key results that measure progress, and common OKR failure modes. For the broader leadership context this kind of quarter-level trade-off sits inside, the product leadership case study exercise from Head of Product covers a comparable week of high-stakes calls. For the metric discipline behind picking a real outcome in the first place, see north star metric examples, and for prioritizing what gets the resourcing once the OKRs are set, the RICE prioritization framework.

Which bootcamp this comes from

This exercise is the practical challenge from How to Design OKRs, a one week, two live session bootcamp on Builders Camp covering objective crafting, key results that measure progress, initiatives versus outcomes, and cadence and scoring. Completing the practical challenge counts toward the bootcamp's completion requirement and its certificate, alongside the certification quiz.

Builders Camp runs this bootcamp both live and self-paced, included with the Builders Camp Membership alongside every other bootcamp, track, and masterclass.