Frameworks
The frameworks, drawn
The frameworks from the end of the qualitative report, as diagrams. Every label and every line of detail is the report's own wording — open a card to read it.
Framework · One
Seven classes, three tiers
The classes are grouped by what they are about: the machine, the person, the world.
Tier A — about the machine
- Answers
- What is true in the system right now?
- Where it lives
- The database. Records, balances, entitlements, configuration.
- Discipline
- Correctness and modelling. Bahadori: "you just want to know the state of this thing at this point in time."
- Cannot tell you
- Anything about behaviour, cause, or intent. A correct database is compatible with a failing product.
- Usual owner
- Backend engineering. Usually the only class with a clear owner.
- Answers
- What did the software do, where did it break, what was slow?
- Where it lives
- Observability — traces, logs, error tracking, latency. Tools like Sentry, New Relic, Logfire, Jaeger, are there to improve observability.
- Discipline
- Catching problems before they become disastrous.
- Cannot tell you
- why a user chose something. It is structured around requests, not around people.
- Constraint
- Storage cost and privacy law. Bahadori's rule: store everything you legally can, anonymised, because the question you'll need it for hasn't been asked yet.
Tier B — about the person
- Answers
- What did users do?
- Where it lives
- Product analytics — events, funnels, retention, session replay.
- Status
- A hypothesis, not a cause. Bahadori: "It could be a plausible case; it could be a rumor in a dashboard."
- Cannot tell you
- Why. This is Theme 1, and it is the whole reason this report exists.
- Failure mode
- Treated as Class 07 (impact) without anyone noticing the substitution.
- Answers
- What do users say about the product, and how do they talk about it?
- Where it lives
- Interviews, NPS, support tickets, testimonials, sales calls, reviews.
- Strength
- The only class that reaches motive directly. Farahani trusts it above everything; van Eeghen processes 600 feedback points per cycle from NPS, support, and sales.
- Cannot tell you
- what people actually did. Petrova: "Actions speak as loud as words." People report the reasons they have access to, which are not always the operative ones.
- Reliability rule
- Scales with how much each respondent is worth to you. In B2B, a single account is close to authoritative; in consumer, one respondent is one anecdote.
- Answers
- How does this person actually live around the problem you solve?
- Where it lives
- Observation, site visits, shadowing, being in the room. Not retrievable by asking, and largely not automatable.
- Why it is its own class
- Petrova's distinction: a screen-by-screen map of your product is a service blueprint — a fact about your company. The customer journey is what happens in their day, most of which occurs outside your software entirely.
- The proof case
- The Evondos nurse who values the drive. No behavioural or stated instrument would have surfaced it; someone had to be there.
- Cost
- Highest per unit of any class, and the first thing cut when a cheaper instrument exists — which is precisely Astra's argument for having no dashboard.
Tier C — about the world
- Answers
- Is there demand, who else is serving it, how big is it?
- Where it lives
- Competitor revenue and traffic, market sizing, pricing, hiring signals, community noise.
- Why it matters here
- It is the only class that exists before your product does. Aksoy, pre-users: "what I try to understand is the competitors — how much revenue they make, how many users they get, how big the market is."
- Cannot tell you
- whether your version works. It is a proxy standing in for Class 03 you do not yet have.
- Answers
- What changed in someone's life or business because this product exists — and for whom?
- Where it lives
- Nowhere by default. It has to be constructed, and it requires naming a beneficiary before you can read it.
- Van Eeghen's version
- "More interesting than your data is the data about how it's impacting those you're building the product for." One dispensing metric, read three ways: freedom for the patient, money for the care organisation, a lost quiet drive for the nurse.
- Cannot tell you
- which beneficiary should win. That is a values question wearing a metric's clothes.
- Failure mode
- Optimised in one direction while quietly costing a party nobody listed.
Framework · Two
The access axis
The second axis is not what you want to know, but whether you can reach the people who could tell you. The bar narrows as access is rationed away.
- What it looks like
- Hundreds of thousands of users; contacting any one of them is statistically meaningless.
- What it forces
- You must trust the aggregate, and you must be anxious about it. Class 03 is the primary instrument; Class 04 is sampled, never surveyed one-to-one.
- What it looks like
- You can both instrument and call. The default assumption in B2B SaaS.
- What it forces
- The luxury of choosing per question — and the risk of always picking the cheaper instrument.
- What it looks like
- Access exists but is rationed, expensive, and mediated by someone else.
- What it forces
- Never automate contact. Every conversation is a one-shot, so it goes to the highest-value question you have.
- What it looks like
- You will never see usage. Open source, on-premise, embedded, or legally fenced.
- What it forces
- A wholesale substitution: Classes 04, 06 and 07 have to carry the load Class 03 carries elsewhere.
Framework · Three
Where the two axes cross
Given my access state, which classes are actually reachable — which are valuable and cost effective in my case. Am I integrated them in development loops, and can I trust their validity?
The composite question
Framework · Four
Three registers, and the two tests
The registers differ by when the number arrives relative to the decision, and whether it had the power to change it.
The rule is written in advance, and the number selects between options. The human's judgment goes into designing the rule and choosing the threshold, not into the individual call. Adib's Zapp is the clearest case in the set: high frequency, low stakes, reversible by tomorrow.
The tell
you could state the decision rule before seeing the data.
Judgment forms the option; data holds a veto before commit. The number can stop the decision but rarely originates it. This is what most participants honestly described — "we use data as a supplement, not to search the data for what to do next" — and it is a legitimate, defensible register, not a lesser one.
The tell
the decision existed before the number, but the number could have killed it.
The decision is made, then evidence is assembled to support it. The number arrives last and never had a vote. This is the most common register and the least admitted; nobody in these interviews described their own work this way, and several described watching others do it.
The tell
the metric was chosen after the conclusion.
The two tests
1.
The unplanned question
Can you ask something the tool was not built for and rely on the answer?
2.
The second asker
If a colleague asks the same question independently, do they get the same number?
Framework · Five
Four phases of a decision system
Phases of a decision system, not of company size. Each one has a characteristic error and a condition for leaving it.
No product data exists. Decisions run on market signal, founder taste and conversations. The correct move is to build conviction fast and cheaply, and to instrument the thing you are building before anyone uses it.
Characteristic error: data-decoration — assembling a market-size slide to justify a decision already made for other reasons.
Leave when real users are doing real things you did not watch them do.
Behavioural data now exists but cannot yet bear weight. The productive pattern is Farahani's: every number is a prompt to talk to someone, not a verdict. The yellow flag does not tell you what is wrong; it tells you whom to call.
Characteristic error: reading a 12% drop across forty users as a finding.
Leave when a metric moves for a reason nobody in the company noticed in a conversation first.
The most valuable phase and the most avoided one. It is where you discover which of your instincts were signal and which were preference — and the discovery only happens if the data is allowed to win occasionally. Petrova's B2B/B2C fork operates here: call the customer if you can, run the test if you cannot.
Characteristic error: quietly relegating any number that disagrees to "the tracking must be broken" — sometimes true, which is what makes it such a durable excuse.
Leave when you can name a specific decision that went against your gut because of a number, and it was the right call.
The rule now has to leave the head, or the company cannot act without the person holding it. This is where ownership becomes the binding constraint rather than tooling — Repo's five different numbers are what a phase-four company looks like when nobody ever wrote the rules down. The reversible decisions become genuinely data-driven; everything ambiguous stays data-validated, permanently.
Characteristic error: assuming this phase is reached by buying tools. It is reached by naming owners.
Leave when — you do not. This is where you stay, maintaining it.
Extension · Six
Where Skene sits in all of this
An extension, not a finding. The five frameworks above are the research; this last part reads Skene, the sponsor of the series, against each of them in turn. Editorial independence is preserved — Skene did not direct this assessment.
Skene is not a new instrument for any of the seven classes. It is infrastructure underneath one of them — the behavioural class — and what it sells against is a number that stays readable after it stops being true.
Skene's own description: product intelligence for GTM teams, protecting the collection layer that feeds analytics tools such as PostHog and Mixpanel rather than replacing them.
On the seven classes
Underneath 03, reading 01 and 02
01 State
02 System
03 Behavioural
04 Stated
05 Contextual
06 Market
07 Impact
It does not generate new evidence about a person. It defends the validity of evidence already being collected — reading the schema and the repository (State, System) to keep the behavioural record intact.
On the access axis
Available and abundant only
Skene presupposes that usage is instrumentable in your own database. It has nothing to offer the structurally unavailable state, and in the scarce state it is beside the point. That is a segment definition, not a shortcoming.
On the three registers
Register three, enforced
Register three — Data-driven
The discipline it enforces
Register two — Data-validated
Register one — Data-decorated
What it structurally prevents
The metric, the goal and the rule are committed before the change ships. Once that is on the record, the metric cannot be chosen after the conclusion — which is the whole definition of register one.
On the four phases
The buyer is phase three
1 · Borrowed conviction
Too early
2 · Earned intuition
Too early
3 · Contested intuition
The buyer
4 · Distributed decision
Before real weight sits on the numbers there is no collection layer worth protecting, and a number is only a prompt to call someone.
On the two tests
One passed, one partly
The second asker
The whole product
The five-different-numbers problem is the failure it addresses: the same question, asked independently, coming back differently each time.
The unplanned question
Answered only partly
Its method asks you to name the question before you ship, which is the opposite move to asking something the tool was not built for.
The report's own boundary applies here too: this grades the small, frequent, reversible calls well, and cannot grade the irreversible ones.
The full argument, the ten themes and the sources for all of the above are in the full report.