Questions people ask before they have a name for the problem.
Direct answers, stated plainly. Each one is a question we get asked in a first conversation, usually phrased as a symptom.
What is GTM engineering?
GTM engineering is the practice of building and operating the systems that execute go-to-market: signal infrastructure, data enrichment, scoring, routing, outbound orchestration and agents. It is an implementation discipline. It answers how a go-to-market system gets built — not what it should observe, infer or decide, which is a question of architecture.
Read the answer →GTM architecture vs RevOps vs GTM engineering: what is the difference?
RevOps optimises how go-to-market operations run. GTM engineering builds and automates the systems that execute them. GTM architecture designs what those systems should observe, infer, decide and learn — the layer that determines what is worth building at all. They are sequential rather than competing: architecture decides, engineering builds, operations runs.
Read the answer →Why do AI SDRs fail?
AI SDRs fail because they are an action layer bolted onto an architecture that cannot tell them which accounts changed, what changed, or whether the outreach caused anything. The model is rarely the problem. The layers underneath it — data, state, signal and feedback — usually are, and no amount of prompt tuning substitutes for them.
Read the answer →Why doesn’t our CRM reflect reality?
A CRM records what people remember to type. It stores assertions — a lifecycle stage someone set once — rather than inferences the system re-derives when new evidence arrives. The gap between the CRM and reality is therefore a design problem, not a hygiene problem, and data-cleanup projects treat the symptom rather than the cause.
Read the answer →What is signal-based selling?
Signal-based selling is go-to-market triggered by detected changes in an account’s state rather than by fixed cadences or static lists. A signal is the observation that something is now different — not a positive indicator, and not a data product you buy. The practice depends on a system that holds a current model of each account, which is why most implementations stall at purchasing intent data and never reach the part that changes outcomes.
Read the answer →What should we actually automate in go-to-market?
Automate the work that is continuous, high-volume and judgement-free: observing, enriching, classifying, detecting change, drafting and monitoring. Keep human the work that is relational, ambiguous or consequential: judgement calls, negotiation, and any decision the system cannot explain. The dividing line is not how difficult the task is — it is whether doing it well requires a model of a person.
Read the answer →Why doesn’t sales use our intent data?
Because intent data arrives as a score with no reason, no owner and no next action attached. Reps are asked to trust a number they cannot interrogate, about accounts they were not already working, with nothing stating why this moment matters. The data is usually fine. What is missing is the decision layer that converts an observation into a specific, explainable instruction.
Read the answer →Why don’t our reps trust the lead scoring?
Because the score is a number they cannot interrogate, built mostly from behaviour that correlates with engagement rather than with buying, and rarely re-derived when the account changes underneath it. Reps find its blind spots faster than anyone measures them. Trust is not restored by retuning the weights — it is restored by making the score inspectable and keeping it current.
Read the answer →