All notes
Builds 5 March 2026 1 min read

GTM problem vs. GTM engineering problem

Some pipeline problems need automation. Others need a better ICP or sales brief. Conflating the two wastes engineering time on problems that won't respond to it.

The most useful skill in GTM engineering isn’t knowing how to build systems. It’s knowing which problems need a system and which ones don’t.

A GTM engineering problem has a structural cause. The signal exists but no workflow catches it. The data exists but doesn’t flow to the right place. The play works in theory but can’t be executed at the scale required by a human. These problems have engineering solutions.

A GTM problem has a strategic or organisational cause. The ICP is wrong. The value prop doesn’t land. The sales motion doesn’t match how buyers actually make decisions in the category. Reps are consistently losing at a specific deal stage. These problems have no engineering solutions, at least not yet. Automating a bad message at scale adds nothing.

Both types look similar on the surface, which is why teams misdiagnose them. Low conversion rate could be a routing problem (engineering) or a positioning problem (strategy). Slow pipeline velocity could be a follow-up timing problem (engineering) or a lack of urgency in the deal itself (sales process). Diagnosing which type you’re looking at requires talking to the people in the motion: reps, sales leaders, sometimes customers. CRM data alone won’t show it.

Some rough signals that it’s an engineering problem: the problem is consistent and repeatable across reps, not concentrated in specific individuals. It disappears when more human time is applied to it. It exists at the handoff between systems or teams. The data to solve it exists somewhere in the stack but isn’t connected.

Rough signals that it’s a strategy problem: top performers don’t have it. It shows up in certain deal types but not others. Fixing the process on paper doesn’t change the outcome. More information doesn’t help because the issue is judgment, not data.

The engineer who makes this distinction correctly is worth more than one who doesn’t. Building a system around a strategy problem is expensive, politically awkward to unwind, and often masks the real issue for another six months.

Keep reading