You Can't Set a Target Without a Baseline: Instrumenting Before You Commit

A target without a baseline is a guess wearing a business suit. If you don't know today's activation rate, "increase activation to 40%" is unfalsifiable — you can't tell if 40% is ambitious, trivial, or already true. Baselining means measuring the current state, with a documented method, before you commit to any number.

Quick answer: Baseline first, target second. Instrument the metric, confirm the number is trustworthy, and document it — only then does a target become a real commitment instead of a hopeful guess.

Why a Target Without a Baseline Is Theater, Not Rigor

A target set without a baseline isn't rigorous goal-setting — it's a performance of rigor. The number looks precise ("increase activation to 40%"), the format looks like a proper OKR, but nobody can verify whether it represents progress, stagnation, or regression, because nobody measured where you started.

This is the same failure mode covered in our piece on killing goal theater in the quarterly cycle: a goal that looks rigorous but can't actually be graded. A baseline-free target fails the same test. You can hit "40%" and have no idea if that's a win.

W. Edwards Deming's old dictum — often paraphrased as "in God we trust, all others must bring data" — is really an instrumentation argument: an opinion about a target is worthless without a documented number to check it against.

Andy Grove's original formulation of OKRs, laid out in High Output Management, insisted that a Key Result be a number you can check against reality, not a description of effort. Checking against reality requires two numbers, not one: where you are, and where you're aiming.

Gallup's long-running workplace research is a related data point: across years of employee-engagement surveys, roughly only a third of employees strongly agree they know what's expected of them at work. A target with no baseline compounds that same clarity problem at the goal level — nobody can say with confidence whether the team is ahead, behind, or exactly on pace.

Three tells that a target is theater:

• The number was picked because it "sounds ambitious," not because anyone traced it back to a current figure.
• Nobody in the room can answer "what is it today?" without hedging ("I think it's around...").
• The metric definition itself shifts between planning and review — a different denominator, a different event, a different tool.

If your team can't answer "what's the number today, and how do we know?" in under a minute, you're not ready to set the target — you're ready to start the instrumentation work covered in our advanced OKRs guide.

The Pre-Cycle Instrumentation Checklist

Before any target goes into a planning doc, run the metric through a five-step check: define it precisely, confirm the data exists, confirm the data is trustworthy, calculate the current value, and document how you'll keep measuring it. Skip any step and the "baseline" is decorative.

Treat this as a gate, not a formality. A metric that fails step 2 or 3 isn't ready to anchor a Key Result yet — it needs an instrumentation project first, which is exactly the interim move covered further down.

A few implementation notes worth calling out:

1. Pick the window deliberately. Trailing 30 days is a reasonable default for activation-style metrics, but seasonal products need a longer window to avoid a baseline that's really just last month's anomaly.
2. Segment before you baseline, not after. A single blended number can hide that new-user activation is 55% on desktop and 12% on mobile — the target you'd set for each is completely different.
3. Name a data owner. Someone specific — not "the data team" — who can re-run the number on demand and explain a swing if one shows up mid-cycle.

There's a trust dividend to doing this work up front, too. A baseline that survives a five-step check is one nobody can credibly relitigate mid-cycle — exactly the kind of dispute that derails a review meeting when the underlying number was never nailed down to begin with.

Case Walkthrough: The Activation Rate Nobody Could Actually Report

Here's the pattern that plays out constantly in planning cycles: a team proposes "increase activation to 40%" as a Key Result, someone asks "what's it at today?", and the room goes quiet. That silence is the most useful five seconds of the entire planning meeting.

Say a product team defines activation as "a new signup completes the core setup action within 7 days." The number gets used casually all quarter — in decks, in standups — but nobody can point to where it's computed. That's the moment to stop and instrument before committing to anything.

What typically surfaces once someone actually goes looking:

• Three different dashboards report activation, and they disagree by 8-15 percentage points.
• The setup_completed event fires twice for a chunk of users because of a client-side retry bug, inflating the true rate.
• "Signup" itself isn't clearly defined — does it include invited teammates, or only self-serve signups?
• Nobody has pulled the number for over two months; the figure everyone's citing is stale.

Untangling this is the same diagnostic discipline as customer research — you're asking what the user is actually doing and why, not what you assume they're doing. A team stuck here often benefits from the same rigor used in Jobs to Be Done analysis: define the job precisely, define the moment of progress precisely, then measure against that definition, not a vague proxy.

Once the team fixes the double-count and agrees on a single definition, the "real" baseline often turns out meaningfully different from the number people were casually quoting — sometimes higher, sometimes lower.

Resolving it usually takes a short, unglamorous meeting: data, engineering, and the PM agree on one definition, write it down somewhere durable, and treat any future disagreement as a documentation bug, not a debate to reopen every quarter.

The number you had in your head before instrumenting wasn't a baseline. It was a rumor.

When the Data Doesn't Exist Yet: Make "Establish the Baseline" a Legitimate Key Result

If a metric genuinely can't be measured today, the honest move isn't to guess at a target anyway — it's to make instrumentation itself the quarter's Key Result. "Establish and report weekly activation rate by end of Q3" is a real, gradable KR, even though it contains no target number yet.

This isn't a lesser goal. Locke and Latham's decades of goal-setting research, starting with their 1990 synthesis A Theory of Goal Setting and Task Performance, found that specific, measurable goals paired with clear feedback on current performance consistently outperform vague or "do your best" goals — and feedback on current performance is exactly what a missing baseline denies you.

How to write the interim KR well:

1. State the exact deliverable — a dashboard, a query, a weekly report — something checkable, not "improve visibility."
2. Include the metric definition as part of the KR itself, not a separate document nobody reads.
3. Set a deadline inside the current cycle, not "ongoing" — an open-ended instrumentation task never finishes.
4. Assign a named owner who reports the resulting number to the group, so the baseline becomes common knowledge, not one person's private query.

This is also where the difference between outcomes and outputs gets tested for real. Shipping a dashboard is an output; a trustworthy number the team can act on is the outcome. Our piece on the outcome vs. output distinction in OKRs covers this trap in more depth — an instrumentation KR is only honest if it's judged on whether the team got a trustworthy number, not on whether a chart got shipped.

Setting the Target Once You Actually Have a Baseline

Once the baseline is real, setting the target is a judgment call informed by data, not a data problem in itself. Look at the trend before the point-in-time number, check what comparable products have achieved, and set a target that's ambitious relative to your starting point — not a round number that sounded good in the room.

A few sources of signal worth triangulating, rather than picking one and treating it as gospel:

• Historical trend. Has the metric been flat, rising, or declining over the last two to three cycles? A target of "+15 points" means something very different against a flat trend than against a metric already climbing on its own.
• Segment ceilings. If desktop activation is already at 55%, your realistic target ceiling there differs from mobile at 12% — don't average them into one company-wide number.
• External benchmarks, held loosely. Public activation ranges published by product analytics vendors and communities such as Amplitude, Mixpanel, and Reforge are useful sanity checks, not targets to copy — your funnel, definition, and user base won't match theirs exactly.
• Where users actually get stuck. Mapping the customer journey from signup to the activation moment often shows the target isn't really about the top-line number — it's about one specific drop-off point depressing the whole metric.

Once you've set an ambitious-but-real target, the harder discipline is making sure it doesn't get diluted as it moves down the org. A baseline anchored at the top level should still mean something when a team's OKRs get derived from it — which is the exact failure mode covered in cascading OKRs without the waterfall effect: sub-teams restating the parent goal instead of owning a baseline and target of their own.

Two Ways to Get the Target Wrong Even With a Good Baseline

A solid baseline doesn't automatically produce a good target — teams still manage to get it wrong in two opposite directions, both worth naming before you finalize a number.

• Sandbagging. Picking a target barely above the baseline so the team is all but guaranteed to "win," which quietly defeats the point of setting a goal at all.
• Reach for its own sake. Doubling a metric because a stretch target sounds motivating, with no trend or segment evidence that the ceiling is anywhere near that high.

Both failure modes are baseline-adjacent, not baseline-caused — which is exactly why baselining is necessary but not sufficient. It removes the guessing about where you start; it doesn't remove the judgment call about how far is real.

How Prodinja Surfaces a Missing Baseline Before It Becomes a Commitment

The instrumentation discipline above is easy to state and easy to skip under deadline pressure. That's exactly why it helps to have it built into the structure you plan with, rather than left to memory.

In Prodinja's Outcome entity, every Key Result carries two required fields: a starting value and a target threshold. Leaving the starting value blank is designed to be visibly incomplete, so a target with no baseline can't quietly pass as done.

That same Outcome record is what a Spec Studio readiness gate checks before a goal moves from draft to committed — a structural nudge toward doing the instrumentation work first, not a claim that the tool measures your product for you.

Key Takeaways

• A target without a baseline is unfalsifiable — you can't tell if hitting the number represents real progress or an accident of an unmeasured starting point.
• Run every metric through a five-step gate before it anchors a Key Result: define it, confirm the data exists, confirm it's trustworthy, calculate the current value, and document how you'll keep measuring it.
• Segment before you baseline. A blended number can hide wildly different realities across platforms, cohorts, or channels.
• When data doesn't exist yet, instrumentation itself is a legitimate interim Key Result — "establish and report the baseline by week 4" is honest, gradable work, not a lesser goal.
• Judge an instrumentation KR on trust, not delivery — a dashboard nobody believes isn't a finished outcome, it's an unfinished one with a UI.
• Set targets from trend and segment data, not a round number that sounds ambitious — external benchmarks are a sanity check, never a target to copy wholesale.
• A missing baseline should be structurally visible, whether that's a blank field in your planning tool or a standing agenda item nobody can skip past.