tl;dr Go-to-market isn't software, but it often fails like software. The funnel behaves like a request lifecycle. The org chart behaves like a service topology. Once you read it that way, the acronyms get less mystical, behavior becomes a better input than self-reported intent, and "the stack is broken" usually resolves into a small set of failure modes you already know how to debug. "GTM Engineer" is the labor market catching up to work that's been getting more technical for years.
I used to think the marketing funnel was embarrassing because it was too simple.
You know the diagram. A triangle. Awareness at the top. Decision at the bottom. A few soft nouns in between: consideration, evaluation, intent. If you've spent most of your career around code, it's hard not to wince a little. Surely the commercial system of a software company can't be reduced to a triangle with a gradient fill.
It can't. But the problem isn't that the diagram is wrong. The problem is that it hides the machinery.
What looks like a funnel is really a request lifecycle. Cold cache. Route hit. Drop-off at every hop. A hundred thousand impressions become a few customers through ordinary attrition, not one dramatic failure. The numbers vary by company, motion, price point, category and execution. The topology is stubbornly familiar.
Go-to-market teams already use the right clues. They talk about pipeline, leakage, routing, handoffs, latency and attribution. Engineers hear those words and assume they're analogies. I don't think they are. I think the two vocabularies evolved apart and then kept describing the same underlying system from different rooms.
That's where a lot of the friction starts.
For the engineer crossing into growth work, or for the GTM Engineer who's been doing the work without ever seeing it named cleanly, the functions look organizational. They're mostly services. The metrics look financial. Many are operational. The acronyms look proprietary. They aren't. They name events.
This is the field guide I wish someone had handed me earlier. It will not make you a marketer. It will make the system legible enough that you can stop translating every sentence in your head.
Start with the word most likely to cause a wrong turn.
In engineering, a signal is a measurement. Telemetry. An event in a stream. A metric, a trace, a log line. Sometimes a UNIX interrupt. The word usually points to something observed before interpretation.
In go-to-market, a signal is already an inference. A pricing-page visit. A job change. A funding announcement. A trial activation. The shorthand means, "somebody did something that might indicate buying intent."
I've seen this exact mismatch waste whole conversations. A growth lead says, "we got a signal from Acme last week." The engineer asks which event, metric or source table. The growth lead means, "Acme behaved like a company we should talk to now." Both are reasonable. They're just naming different layers.
// same word, different layer
const engineeringSignal = observe(eventStream, {
as: ["metric", "trace", "log_line"]
});
const gtmSignal = inferIntent({
from: ["pricing_page", "job_change", "trial_activation"],
meaning: "they_might_buy"
});The distinction matters because most modern go-to-market tooling uses signal in the second sense, while the architecture underneath looks like the first: event stream, classifier, router, destination. The buyer-side meaning rides on top of the engineering shape. Once you can hold both meanings at once, the rest of the vocabulary gets easier.
A go-to-market motion is the system a company uses to turn strangers into customers, and then to turn those customers into retained or expanded revenue. Every acronym, function and dashboard lives somewhere inside that system.
At its simplest, the pipeline has four conceptual stages. Most of the vocabulary you'll meet names an event, a state or a transition between them.
UNKNOWN → ANONYMOUS_VISITOR.ANONYMOUS_VISITOR → IDENTIFIED_LEAD → QUALIFIED.QUALIFIED → CUSTOMER.CUSTOMER → EXPANDED | CHURNED.If you've built a state machine, this should look familiar, with two complications. First, the transitions are noisy and partially observable. Second, the object moving through the system isn't just a message. It's a person, a company or both in changing ratio over time.
That identity carries history. A buyer's state at time T+1 depends on their state at time T and on every touch between those two points: the ad they ignored, the doc they read, the teammate who invited them, the sales email they didn't answer, the renewal call that happened six months later. People go backward. They switch jobs. They return after a quarter of silence. The median motion may take weeks. The long tail takes quarters or years.
The word "funnel" makes this sound cleaner than it is. The system is stateful, partially observable and full of tail latency. That's the useful mental model.
Put the familiar funnel into a vocabulary engineers already use.
Don't treat these rates as benchmarks. They're illustrative, and deliberately round. The point is to make the shape visible.
Drop-off isn't an exception here. Drop-off is the default. The whole system is a multiplicative loss function, which means the right place to optimize is wherever the marginal improvement survives furthest downstream.
That sounds obvious until you sit in the planning meeting.
Teams will argue about whether the top of funnel is weak, whether sales is underperforming, whether the website needs work, whether pricing is wrong. Sometimes the loudest argument is correct. More often, the arithmetic is more useful than the volume.
If you're running ten qualified leads through a fifteen-percent close rate, doubling close rate gains roughly 1.5 customers per period. Improving a small form-fill rate by twenty percent may barely show up. In a different motion, with much more top-of-funnel volume and a healthy close rate, the reverse can be true. There's no permanent answer. The math changes as the system changes.
Good teams stop asking which stage is "the problem" in the abstract. They ask which stage's next unit of improvement compounds the most this quarter.
Modern B2B SaaS usually runs two motions through the same pipeline. They differ in who initiates the transitions.
In a sales-led motion, humans move the process forward. Marketing generates the lead. A sales development rep works it. An account executive demos, negotiates and closes. A contract gets signed. The cycle is longer, the contract value is higher, and the process has more human judgment at every hop.
In a product-led growth motion, the product moves more of the process forward. The user signs up without talking to sales. They reach value inside the product. They invite a teammate. They hit a limit, a trigger or a reason to upgrade. The cycle is usually shorter, the initial contract value is usually lower, and the system depends on the product doing work that a seller used to do.
Most scaled software companies end up hybrid. Self-serve handles the bottom of the market. Sales handles the top. The interesting work happens in the seam: a self-serve user inside a five-hundred-person company who looks ordinary until their behavior suggests they could become a six-figure account.
That seam is where the math gets non-linear. It's also where the tooling stack is often least coherent.
Viewed from the right distance, a go-to-market organization is less a hierarchy than a service topology. Each function owns a stage of the pipeline and exposes a contract to the function downstream of it. The contracts are often informal, which means they drift. A lot of what gets called sales and marketing alignment is really contract drift between services.
Marketing. Owns the top of the funnel: awareness, interest, demand generation, content, brand, lifecycle, product marketing. The function as a whole is the ingest layer. It creates events for downstream teams to consume. If it over-fires, sales gets a queue full of poor-fit work. If it under-fires, sales starves. If it changes the definition of a qualified lead without telling anyone, the downstream service starts failing in ways that look like culture problems.
Sales. Owns the middle and bottom of the funnel: qualifying, demoing, negotiating, closing. The sales development rep is a worker queue. The account executive is the request handler that actually commits the transaction. The account manager handles expansion and renewal on existing customers. The sales engineer is the field engineer, the technical co-pilot for demos, proofs and security questions. Compensation across these roles is usually some form of quota, which is just a revenue target with a paycheck attached.
Customer success (CS). Owns what happens after the contract is signed: onboarding, adoption, renewal, expansion and support. Good CS looks a lot like good on-call. They watch the customer's real usage after deploy. They notice when an account goes quiet. They page the right human before the renewal is already dead. Broken CS looks like everyone screaming in #incidents, except the incident is a renewal you didn't know was at risk.
RevOps (Revenue Operations). Owns the infrastructure all of the above run on: the CRM, data model, lead-routing rules, forecasting, territory logic and compensation mechanics. This is the platform team. They don't sell and they don't market. They keep the commercial system operable. They care, more than anyone else, whether product events are clean, typed and usable. In practice, they own a schema that many teams can break.
Growth. Owns the product-led loop: sign-up, activation, retention, virality and monetization. In a product-led company, growth sits halfway between engineering and marketing. Growth teams run experiments, instrument funnels, build dashboards and ship code. They're usually the GTM function closest to the product itself.
The buyer has a topology too. A champion wants you to win. An economic buyer can sign the check. Legal, security, finance, IT and the team lead can all become veto points. The exact cast changes by market, but the shape is consistent enough to matter.
A B2B sale is a quorum protocol, not a single-leader write. The deal doesn't close until enough of the system agrees.
That's not only a clever line. Forrester's 2026 buyer research put the typical buying decision at 13 internal stakeholders and nine external influencers. Gartner's 2025 buyer-team research described buying groups ranging from five to 16 people across as many as four functions, and found that consensus is materially tied to deal quality. The exact numbers will change. The point will not: there's rarely one buyer.
Once you read these roles as services and counterparties in a distributed system, the acronyms stop looking like soup. They start looking like interface descriptions.
The older model of qualification ran through forms. A lead filled out a contact form, checked a few boxes about company size and budget, and entered a queue. Marketing-qualified lead became sales-qualified lead after a salesperson decided it was worth working.
That model still exists. It's also weaker than it used to be.
In a product-led world, the best qualification data is often not what a user claims on a form. It's what they do. A user signs up, completes onboarding, invites two teammates, hits a free-tier limit and visits the pricing page twice in a week. At that point, they're qualifying themselves in the event stream. The form was a proxy for behavior. Now the behavior is visible directly.
// behavior as qualification
const pql = qualify(user.events, {
activated: true,
invitedTeammates: 2,
hitUsageLimit: true,
viewedPricing: "twice_this_week"
});
if (pql.score >= threshold) {
route.to("sales", { reason: pql.explain() });
}That's the useful idea inside the term product-qualified lead (PQL). The acronym isn't beautiful. The concept is. Behavior is usually a better intent signal than declared interest, and the go-to-market system should be built to notice it.
Most systems still don't.
The design problem is straightforward to state and difficult to do well: read the stream, classify what it shows, route the resulting signal to the right person or system, and keep enough audit trail that someone can answer, "why did we email this customer last Thursday?" three months later.
That last requirement is easy to underrate. A system that turns behavior into outreach but can't explain what it saw will become unsupportable as soon as it scales beyond the team that built it. Audit isn't compliance overhead. Audit is the work record.
Talk to enough people running go-to-market systems at real scale and the same failures come up again and again. They're usually described in commercial language. The shape is engineering language.
Failure one: the data doesn't reconcile. Salesforce says one thing. The warehouse says another. The dashboard the CFO uses to forecast says a third. The requested fix is usually "a single source of truth," which sounds technical until the numbers move. Then it becomes political. Every team has built reporting around the version of reality that makes its own performance legible, sometimes flattering. Reconciliation means somebody loses a chart they liked.
Failure two: the handoff drops events. Marketing fires a lead and sales never sees it, or sees it three days late. Sales closes a deal and customer success never gets the kickoff context. Product records usage that would change the account plan, but nobody in the revenue team knows where to look. In engineering terms, this is an event-driven system without retries, idempotency or a dead-letter queue. In go-to-market terms, it's Tuesday.
Failure three: the integrations rot. A webhook payload changes. A field gets renamed. A sync silently stops mapping the value everyone depends on. For two weeks, the wrong deals route to the wrong queue and the dashboard keeps looking normal. This is API contract drift without integration tests. It's worse when nobody owns the schema because the schema crosses organizational boundaries, and boundaries are where ownership tends to blur.
When a growth leader says "the stack is broken," they usually mean one of these three. The practical question isn't whether the stack is broken. It's which contract failed, who owns it, and what would make the failure visible sooner next time.
This guide is trying to install intuition more than terminology. Once the intuition is there, the terms have somewhere to go. Still, a few acronyms show up often enough that knowing them early is useful.
ICP is ideal customer profile. It's the company-level shape of the customer a product is built to serve: size, industry, use case, budget, maturity, trigger, constraints. If you retain one acronym, retain this one. A weak ICP makes every downstream system noisier.
NRR, or net revenue retention, is the retention metric people care about most in SaaS. It measures revenue this period from the customers you had last period, including expansion and churn. Above 100% means the existing customer base grows even before new logos are added. Bessemer's 2023 State of the Cloud benchmarks call 100% good, 110% better and 120% or higher best for growth-stage SaaS.
CAC is customer acquisition cost. LTV is lifetime value. The ratio is a shorthand for unit economics. David Skok's SaaS metrics guide puts a healthy LTV:CAC ratio above 3, and treats CAC recovery under 12 months as a guideline that runs longer for land-and-expand motions.
MEDDIC and BANT are sales qualification frameworks. They're mnemonics for whether sales asked the right questions. MEDDIC originated inside PTC in 1996 and has since grown variants with extra letters. BANT is older and shorter: budget, authority, need, timeline. The mnemonics matter less than the discipline they impose.
The rest you can learn in the wild. A demand gen lead running a lifecycle program is, in one reading, a person on the ingest team writing pub-sub jobs against a templating engine. The more time you spend around the work, the less strange the job descriptions sound.
The thesis here isn't that every GTM person should talk like an SRE. Please don't do that.
The thesis is that go-to-market has become an engineering surface. The functions have been getting more technical for years. The vocabulary has lagged the work. The job title "GTM Engineer" feels new because the labor market is finally naming a job that already existed in pieces.
Once you read the system this way, arguments get more specific.
A marketing campaign isn't only a creative artifact. It's an event generator with a payload. A sales process isn't only theater. It's a request lifecycle with informal SLA contracts between handlers. Customer success isn't only relationship management. It's observability and on-call for retained revenue. The CRM isn't only a database of accounts. It's the system of record tying the rest of the mesh together.
None of this removes the human craft from the work. Sales is still a craft. Marketing is still a craft. Customer success is still a craft. The best people in those functions are excellent in ways that resist instrumentation, and the systems view should never be used to flatter the measurable parts at the expense of the real ones.
What the systems view does is make the work modelable. It gives the engineer and the go-to-market lead a shared way to talk about where information enters, where it mutates, where it drops and where it should be routed next.
If you're crossing into this work, welcome. The system is more legible than its vocabulary suggests. If you're already in the work and the title GTM Engineer is somewhere in your present or future, this guide is for you in a different way. The shift is real. The names are catching up.
Source: https://www.civic.com/field-notes/field-guide-go-to-market