How to approach a GTM engineering problem

When someone asks for better lead routing, I first want to understand the routing they already have. This framework moves from that initial complaint to an agreed problem, a tested intervention, and clear responsibility after launch.

The build is one part of the job. Diagnosis and stakeholder alignment determine whether it is the right build at all.

1. 1
   Understand the current process
2. 2
   Diagnose the reported failure
3. 3
   Identify affected people
4. 4
   Agree on the outcome and measures
5. 5
   Establish a baseline or instrument the gap
6. 6
   Choose an intervention
7. 7
   Test and pilot
8. 8
   Launch with clear ownership
9. 9
   Review results and revisit assumptions

Understand what already exists

I ask the requester how they think the process works, whether they have been enabled to use it, and which examples made them lose confidence in it.

Then I inspect the implementation and records. A useful first pass follows a recent item from entry through assignment, action, and final disposition. Compare the expected behavior with what actually happened.

A seller receiving few inbound handraisers might be experiencing a routing defect. They might also be seeing lower demand in their territory, a different allocation rule than they expected, or a missing follow-up notification. The complaint deserves investigation without assuming either the user or the system is wrong.

Separate plausible explanations

Use competing explanations to guide discovery. Do not settle on the one closest to your favorite tool.

Reported symptom	Possible explanation	Evidence to inspect
"I don't get enough inbound."	Demand mix, allocation expectations, or assignment failure	Eligible volume by territory and the actual assignment history
"These leads are bad."	Fit, intent, source quality, or unclear acceptance criteria	Rejection reasons and a sample reviewed against agreed criteria
"Nobody follows up."	Missing ownership, workload, alerts, or enablement	Assignment, acceptance, and follow-up events
"The router is wrong."	Stale territories, incorrect data, or an unmodeled exception	Inputs and rule version at the time of the decision
"The dashboard is wrong."	Population, field authority, refresh timing, or calculation	A trace from the displayed number to its contributing records

These are examples, not a diagnostic checklist that proves the answer. Missing records or activity logging may make the evidence incomplete. Note that gap instead of interpreting silence as proof that no work occurred.

Identify all the clients

The person opening the request is not necessarily the only person affected. For an inbound process, the clients may include Marketing, the receiving sellers, Sales leadership, RevOps, administrators, and the people consuming downstream reports.

Ask who depends on the process, who has to repair it, and who could be harmed by changing it. The builder can be a client too. Reducing repetitive admin work is a valid goal when it improves operating capacity.

I use these conversations to determine whether others experience the same problem. They may describe different symptoms of one failure, or several separate problems that should not be bundled into one project.

The GTM engineering and RevOps reference explains the distinction between approving business rules and implementing them. In a small organization, one person can hold several responsibilities; those responsibilities still need names.

Align on the problem and desired outcome

Once I find a real improvement opportunity, I switch into consultant mode. I may have implementation ideas, but I keep the discussion focused on the problem and what success should look like.

For example, Marketing may want more demand accepted, Sales may want fewer low-fit requests, and Operations may want less daily repair work. Those goals can conflict. Make the tradeoffs visible before deciding which workflow will enforce them.

An agreed problem statement might be:

Eligible inbound requests do not consistently reach an accountable seller, and the team cannot distinguish qualification misses from follow-up misses.

That statement gives the project a testable focus. It is still a hypothesis until the records and stakeholders support it.

Define success without naming the tool. A new AI model, dashboard, or routing application is an implementation choice, not the outcome.

Agree on measurement before implementation

Key performance indicators, or KPIs, should describe the behavior the team wants to improve. Existing measures may need to be clarified, replaced, or retired.

For the inbound example, the team could track eligible requests accepted within a defined service-level agreement, routing corrections, time to first response, and unresolved exceptions. Qualified opportunities may provide a later business outcome.

Write down the definition behind each measure.

Measurement field	What to agree
Population	Which requests are eligible, and which are excluded?
Event	What exactly counts as acceptance, response, or completion?
Calculation	Which numerator, denominator, or time interval is used?
Window	How much time must pass before judging the result?
Owner	Who approves the definition and reviews changes?
Guardrail	What must not get worse while the primary measure improves?

For example, reducing manual review volume is not useful if the system now rejects good demand. Pair efficiency measures with quality and safety checks. See leading and lagging indicators and the metric dictionary template.

Establish the baseline honestly

When improving an existing process, I want to know its current success rate, elapsed time, exceptions, and manual effort. Use the same definitions the new process will be measured against, or document the mapping between old and new measures.

Sometimes the current process never captured the required events. Then the first intervention may be instrumentation: record the states and timestamps needed to understand the process before changing it.

External benchmarks can inform planning when internal evidence is thin. They cannot prove improvement against your own previous performance. If there is no usable baseline, say so and collect one.

Choose the smallest useful intervention

After the problem, clients, outcome, and measures are clear, I work on the how. This is the part I enjoy most.

The answer may be enablement, a repaired report, revised rules, native configuration, a connection between tools, a purchased capability, custom code, or AI assistance. It may also be no build if the investigation shows the current process is working and the real issue is understanding or expectations.

1. Step 1
   Clarify the failure
2. Step 2
   Compare interventions
3. Step 3
   Select a bounded change
4. Step 4
   Define its test

Compare configure, connect, buy, and build at the capability level. A product purchase still requires integration and adoption. A custom build needs an owner and a maintenance plan. The data-quality build-versus-buy framework provides a detailed example, while GTM tech stack architecture addresses where the selected work should execute.

Turn the solution into explicit contracts

A request to automate inbound may contain separate decisions about eligibility, company matching, ownership, and permission to act. Name each one so the implementation does not invent policy.

Use the Decision Card for the question, evidence, outcomes, unknown states, and business authority. Use the workflow specification for the tasks, handoffs, timing, completion evidence, and failures that follow.

These artifacts sit inside problem-solving. Completing a workflow template does not substitute for establishing that the problem is real.

Test failures as well as expected behavior

Test the cases that can expose incorrect assumptions before people depend on the output.

For example, an inbound implementation may need tests for missing evidence, duplicate identities, stale ownership, conflicting rules, insufficient user access, partial success, repeated delivery, and a downstream service being unavailable.

For each case, specify the expected outcome and who owns recovery. A review state with no visible queue or accountable operator is unfinished work.

Test the operating controls too. Confirm the change can be paused, inspect what already happened, and exercise the recovery path. Use the production-readiness checklist and limits and staged rollout reference for deeper controls.

Pilot with users who can expose problems

For complex systems, I often start with a small group of users who have a reason to care about the outcome. They can help identify unclear outputs, poor timing, or a missing step before wider release.

Also include representative users and ordinary cases, not only enthusiasts or the easiest records. A pilot that works for the people who helped design it may still need better enablement for everyone else.

Check whether users understand the output, know what they own next, and can resolve exceptions. Observe workarounds. They may indicate a missing requirement, training gap, or friction the metrics do not show.

Define promotion and rollback criteria before expanding. Technical success alone is not enough if users cannot complete the intended work.

Operate and measure after launch

Make the agreed metrics visible to the people who need them. The business owner should see outcomes; the technical owner should see execution and failure evidence; users should have a clear way to report problems.

Business outcome

Did the agreed result improve?

Adoption

Are the intended people using the process?

Execution

Are jobs, writes, and handoffs completing?

Exceptions

Where is review or repair accumulating?

User feedback

What does the workflow make difficult?

Changed assumptions

Has the business, data, ownership, or tooling changed?

Compare like populations and allow enough time for later outcomes to appear. A changed source mix or shorter observation window can distort the comparison. Do not call a before-and-after difference causal without an evaluation that supports that conclusion.

Testing may reveal that the previous process was better. A checkpoint may add delay without improving quality, or an automated decision may need more human review. The project should be able to respond to either result.

Revisit the assumptions

A process that works today can become unsuitable when territories, products, customers, or ownership change. Define review triggers rather than waiting for another complaint.

Examples include a scheduled rule review, repeated exceptions, KPI drift, a major tool change, or a new operating model. Name the reviewer and the evidence they should inspect.

The technical-debt audit helps when the issue spans several systems. Retirement, simplification, or returning to manual work can be legitimate outcomes of the review.

Keep experimentation and production ownership distinct

I want teams to experiment with automation. A seller, marketer, or CSM can uncover an idea that the GTM engineering team missed.

When an idea becomes a shared dependency, someone needs to own its rules, maintenance, permissions, and measurement. That transition protects people from spending their primary working time maintaining overlapping infrastructure.

Self-service can be the right design. It should expose useful choices within an agreed operating model rather than leave every individual to recreate shared eligibility and audience controls.

The same discipline applies to GTM engineers: becoming absorbed in implementation can obscure the original business objective. Different commercial and technical backgrounds can be effective when the owner understands both the outcome and the system needed to support it.

A reusable problem brief

Complete this review document before a detailed build brief. Unknowns are acceptable when they are explicit and have a next step.

Section	What to capture
Reported symptom	The requester's description in their own terms
Observed evidence	Records, user examples, or measures supporting the diagnosis
Current process	Existing rules, systems, owners, and manual steps
Clients	Affected users, stakeholders, and operators
Agreed problem	The bounded failure or opportunity to address
Desired outcome	What success means without specifying the tool
Measurement	Definitions, baseline status, window, owner, and guardrails
Open questions	What is unknown and how it will be investigated
Intervention	Options considered and the reason for the proposed change
Validation	Test cases, pilot population, and promotion or rollback criteria
Operations	Support owner, monitoring, enablement, and review trigger

This is a stakeholder artifact, not executable configuration. Keep it short enough to review together. Then use the GTM System Map to connect the agreed outcome to data, decisions, work, and evidence.