What is state-based GTM?
State-based GTM models each account by what is currently true of it — inferred from evidence and re-derived when new evidence arrives — rather than by which stage of a funnel someone last moved it to. A state is an inference the system maintains; a stage is an assertion a person made once. The difference matters because markets change whether or not anyone updates a record.
Funnels describe the seller, not the market
A funnel stage records how far an account has progressed through our process. It says nothing about what is happening at the company. An account sits in Stage 3 because someone moved it there — and it stays in Stage 3 through a reorganisation, a budget freeze, a champion's departure and a competitor's implementation, because none of those events has a mechanism to move it.
The model is not wrong so much as it is about the wrong subject. It is a faithful record of the seller's activity presented as a description of the buyer's reality.
What a state is
A state is what is currently true of an account, inferred from evidence, and re-derived whenever new evidence arrives. Three properties distinguish it from a stage:
- Inferred, not asserted. The system concludes it from evidence rather than storing what a person typed.
- Current, not historical. It updates when the world does, not when someone remembers.
- Explainable. The evidence behind the conclusion is retrievable, so a human can disagree with it specifically rather than in general.
That third property is what makes the model correctable, and correctability is what makes it trusted. A conclusion nobody can interrogate gets ignored no matter how accurate it is — the mechanism behind why reps don't trust lead scoring.
A stage is an assertion someone made once, which the system has no mechanism to notice has become wrong. A state is an inference the system re-derives. That single difference is most of the gap between the CRM and reality.
Why this changes what the system can do
A state model is not a reporting improvement. It is the precondition for three things a stage-based system structurally cannot do.
Detect change
A signal is a difference between what was true and what is true now. That comparison requires a maintained model of the previous state. A CRM field overwrites its old value, which destroys the change at the moment it happens — so a stage-based system can be told what is true, but never that something became true.
Time an action
The largest lever in outbound is contacting someone shortly after their situation changed. Stages contain no information about the buyer's situation, so timing defaults to the seller's cadence. Signal-based work is only possible on top of a state model, which is why signal-based selling stalls at buying intent data — the feed arrives and there is nothing maintaining state for it to change.
Learn
To improve, a system has to establish which conditions predicted movement. That requires knowing the conditions — the state — at the moment of each action. A system that records only stages can count activity and correlate it with outcomes, but it cannot say what was true about the account when the action landed, which is the only thing worth knowing.
What it takes
Less than the framing suggests, and more than a field change. Three requirements:
- Somewhere that retains history, because a state model is meaningless without the ability to compare against what came before.
- Evidence from beyond your own funnel — hiring, structure, technology, timing. What predicts buying mostly happens outside your marketing stack.
- Stated inference rules, written down and inspectable, so the conclusions can be argued with and improved.
Designing the state model is the second layer of the GTM Architecture Audit and the core of Architect. It is second rather than first because a state model is only as good as the evidence underneath it — which is why the layer below it gets evaluated before anyone designs the one above.
Are we supposed to delete our funnel stages?
No. Stages remain useful for forecasting and for describing a deal to another human. The change is that they stop being the system’s model of reality and become a reporting view derived from it. A stage that nobody has to remember to update is a much better stage.
What does a state actually look like in practice?
A set of claims the system maintains about an account with the evidence behind each: whether the buying committee is intact, whether a relevant technology is present, whether hiring in the target function is expanding or frozen, whether usage is trending away from renewal. Each is inferred, dated, and re-derived when new evidence arrives.
Does this require machine learning?
Rarely at the start. Most of the value comes from explicitly stated inference rules over evidence the company can already obtain — which is both cheaper and inspectable, and inspectability is what makes the model correctable. Learned models are useful later, once the feedback layer exists to train them on something real.
How is a state different from a score?
A score compresses everything into one number and destroys the reasoning. A state is a set of specific, dated claims a person can read, disagree with and correct. Compression is useful for ranking a list; it is useless for justifying a conversation, which is why scores get ignored.