Open almost any product spec and you’ll find a success metric. “Increase checkout conversion to 6%.” “Keep p95 latency under 300ms.” “Get activation to 40% of new signups.” Someone wrote that number down because it mattered.
Now ask the harder question: what’s the value today?
Nobody in the spec knows. The number lives in PostHog, or GA4, or a dashboard someone built once. The spec says the target; the analytics tool says the reality; and the two never talk to each other. So the metric in your product definition is an aspiration frozen at the moment it was typed — a goal with no feedback loop.
This is one of the quietest forms of product drift. Not the spec diverging from the code, but the spec diverging from results. And it’s why so many “success metrics” in product docs are decoration: they’re declared, never measured against, and quietly forgotten.
Why metrics rot in isolation
A metric is only useful as a comparison. “6% conversion” means nothing on its own — it means something next to “we’re at 4.2%.” The target and the actual are two halves of the same fact, and product tools have historically owned only the first half.
So teams do the manual dance. Someone pulls the number from the analytics tool. They paste it into a slide, or a Notion table, or they say it out loud in a review. By the time anyone looks again, it’s stale. The metric in the spec and the metric in reality drift apart, and the spec slowly stops being trusted as a description of how the product is actually doing.
The deeper problem is that the metric isn’t connected to anything. It’s a string of text near a feature. It doesn’t know which analytics query produces it, so it can’t refresh itself, and nobody can see at a glance whether the feature it measures is on track or off track.
What changes when the spec reads its own number
In a structured product model, a Metric isn’t a line of prose — it’s a node, linked to the Feature it measures, with a unit, a target, and a direction (up is good, or down is good). That structure is exactly what’s missing from a metric buried in a doc, and it’s exactly what makes a live binding possible.
So we made Metric nodes live. You connect an analytics provider, point a Metric at a real query, and the model reads the current value — on the node itself and on a metrics dashboard — compared against its target. A Feature’s success metric now reads:
Checkout Conversion Rate — 4.2% vs a 6% target. Off track.
That single line does something a static spec never could. It collapses the gap between intention and reality into one place. The person reviewing the feature doesn’t have to go find the number; the number found them. And because the metric is a node connected to a feature, “off track” isn’t an isolated stat — it’s attached to the thing you’d actually change.
This is the first time real-world data flows into the product graph rather than out of it. The spec stops being a document you maintain and starts being a dashboard that tells you something.
Observations are not facts
There’s a design decision underneath this that’s worth being explicit about, because it’s easy to get wrong.
Specor is built on an event-sourced model: every change to your product definition is a semantic event, recorded forever, diffable and reversible. That immutable history is the canonical truth of what your product is and how it changed.
A live metric value is not that. It’s an external observation that changes every hour. If you wrote each reading into the event log, you’d pollute your product’s history with millions of “the number is now 4.21… now 4.19…” events — noise drowning the signal of actual product decisions.
So we draw a hard line. The binding — “this Metric reads from this PostHog insight” — is a real, versioned change, part of your history like any other field. The values are cached observations: fetched on demand, refreshed in the background, kept briefly for a sparkline, and never written to the event log. The spec remembers the decision to track a number. It treats the number itself as what it is — a live reading, not a permanent fact.
It’s the same instinct that makes the rest of the model trustworthy: be deliberate about what counts as history.
Different sources, one picture
Real teams don’t get all their numbers from one tool. Conversion lives in PostHog; acquisition lives in GA4; revenue lives somewhere else entirely. So the integration is provider-agnostic by design: each Metric carries its own binding, and you can connect more than one provider to the same workspace.
One feature’s metric can read from PostHog while the next reads from Google Analytics 4 — and they sit side by side on the same dashboard, each compared to its own target, each flagged on- or off-track. The product model becomes the one place that unifies “what we’re trying to achieve” with “where we actually are,” regardless of which tool measures it.
Credentials are handled the way third-party secrets should be: encrypted per workspace, set by an admin, never returned, never logged. A live value never costs an AI credit — binding is manual and deterministic.
The point isn’t the dashboard
Plenty of tools show you metrics. What’s different here isn’t the chart — it’s where the chart lives. The number sits on the same node as the feature it measures, inside the same versioned model that holds your rules, flows, and decisions. When a metric goes off track, you’re one click from the feature, the acceptance criteria, and the decisions that shaped it.
A spec that knows its own numbers stops being a record of what you intended and becomes a live read on whether it’s working. That’s the difference between a document you maintain out of obligation and a model you actually look at.
If you’re already keeping your product definition in Specor, connecting a provider takes a few minutes — see the live metrics integration docs to wire up PostHog or GA4.