Shashank Khanna on revenue as a state machine
Shashank Khanna argues that revenue should be managed like a state machine, not a reporting stack. If ICP, signals, or plays change, the system should update before the lagging dashboard tells you something is off.
A standalone clip for Shashank's talk was not published with the event assets. For the full event recording, use the April Tools Day recap.
The most useful idea in Shashank Khanna's April Tools Day talk is that most revenue teams still manage a living system as if it were a reporting problem.
They look at dashboards.
They inspect lagging numbers.
They make changes after the system has already moved.
Shashank's argument is that this is the wrong mental model. Revenue should behave more like a state machine.
That sounds abstract until he defines the pieces:
- TAM
- ICP
- personas
- signals
- plays
Those are not separate artifacts. They are interdependent parts of the same system.
The dashboard model is too slow
Shashank is not saying dashboards are useless. He is saying they are late.
By the time a review meeting notices that meeting-booking rates or revenue conversion changed, the interesting decisions already happened upstream:
- which accounts entered the TAM
- how ICP was defined
- which signals were being watched
- which play got assigned
That is what makes the state-machine framing useful. It forces the dependencies into the open.
If your ICP changes, your TAM should change with it.
If a competitor blows up, your prioritization should not wait for next quarter's planning cycle.
If a signal starts outperforming, the routing and play layer should respond before a manager notices the trend in a dashboard.
The metaphor matters because of what it allows
Once you start thinking in state-machine terms, a new set of capabilities starts to make sense:
- dynamic TAM updates
- live signal detection
- runtime play selection
- real-time reassignment
- continuous testing of personas and sequences
- AI-prioritized call tasks instead of noisy queues
This is not a metaphor for its own sake. It is a way of forcing the GTM system to behave like the thing it already is: interconnected, changing, and sensitive to timing.
The human role does not disappear. It becomes narrower and more leveraged. Reps still make the call. Operators still decide what good looks like. The system simply stops asking humans to rebuild the priority stack from scratch all day long.
The build-vs-buy point is sharper than usual
Shashank's case for internal systems is not ideological. It is local.
Packaged systems do not know:
- which sequences actually work for your company
- which persona differences matter in your market
- which signal combinations are worth trusting
- what should happen when one assumption changes
A vendor can sell you a workflow. It cannot fully encode the transitions that make your business specific.
That is why the state-machine framing matters more than any single feature. The durable value lives in the transitions.
This is also where the talk lines up closely with the broader Deepline worldview. Outcome-first systems require ownership of the evidence and the dependencies, not just the report at the end.
The takeaway
The biggest shift in the talk is not technical. It is conceptual.
Most GTM teams still think in terms of tools and reports.
Shashank is asking them to think in terms of state and transitions.
That is harder. It is also closer to how high-performing revenue systems already behave:
- always changing
- always generating new evidence
- always forcing tradeoffs about what should happen next
Once you buy that framing, the downstream product requirements become clearer. You stop asking for a prettier dashboard. You start asking for a system that can notice a meaningful state change and do something intelligent with it before the number shows up three weeks later in a review.
That is a much more ambitious target. It is also much closer to where AI-native GTM is headed.
If you want to go deeper
For the full event context, start with the April Tools Day recap.
If you want to build GTM systems that can react to state changes earlier, start with Deepline.
More talk breakdowns from the same event:
- Ben Holley on outbound from the terminal
- YG Hong on shipping lead scoring without knowing ML
- Garrett Wolfe on why cookie-cutter GTM is dead
- Jai Toor on outcome-first GTM systems
Build GTM systems that notice state changes early
Deepline helps teams connect signals, personas, and plays so the system can adapt before the lagging numbers show up in a review meeting.