Guides
GTM engineering makes more sense with a real problem in front of you. If the role is new to you, start with Preface: GTM Engineering 101. Then work through the decisions, build the system in your browser, and save your progress as you go.
Preface
New to GTM engineering?
Learn what the role does, who it serves, and how to turn a business problem into a system. Six short chapters and a capstone with a project brief you can keep.
Follow the sequence or enter where your system is breaking.
Ground Your GTM Data
Can everyone, and every system, agree what the data means?
Your CRM only works when its records have a shared meaning. Define that meaning, keep it accurate as the business changes, and make it available wherever the work happens.
- 1a
Define What Your CRM Data Means
Two teams read the same pipeline report and reach different numbers because nobody agreed what a stage means. Start CRM implementation with business meaning by defining the records, lifecycles, fields, and owners behind a Business Truth Map your team can review.
Business Truth Map - 1b
Keep Your CRM Data Trustworthy
CRM data decays in recognizable ways: duplicate records split a person's history, opt-outs reach the wrong channel, and enrichment spends money on records nobody will use. Diagnose the failures and write the policies that keep them from returning.
CRM Data Reliability Plan - 1c
Build a CRM AI context layer
A CRM agent gives a confident wrong answer because it can see the fields but not what they mean. Fix the missing context, authority, permissions, and tests in a lab that needs no CRM connection.
Grounded CRM Agent Lab
Make Better Decisions
Can the system make a clear recommendation without pretending to know more than it does?
First define the decision (2a), then design how to answer it (2b), then make its evidence and review path visible (2c). The examples distinguish a supported recommendation from permission to act.
- 2a
Define the Decision Before You Automate It
Four words in a team channel can become three different decisions. Turn a request that names a technology into a Decision Card somebody else could implement without filling in the missing rules themselves.
Decision Card - 2b
Make the Decision Without Faking Certainty
The dangerous answer is the one that looks exactly like a good answer: an empty field read as a bad signal, a score of 20 that means two unrelated things. Compare rules, models, and combined designs against the awkward cases that separate them.
Decision Design - 2c
Show the Reasoning and Let People Overrule It
People may distrust a result they cannot inspect, while over-trust can let plausible errors pass without review. Give people evidence to inspect a result, disagree with it, and correct it without erasing what happened.
Decision Review Policy
Put Decisions to Work
Can the system safely help the business complete real work?
Map the owned workflow (3a), add boundaries and recovery (3b), then carry the work across systems (3c). Keep technical delivery separate from the business outcome you still need to confirm.
- 3a
Turn the Decision Into a Workflow
A working workflow needs more than a successful sequence. It also needs owners, waiting states, and recovery paths for cases that cannot proceed. This guide makes those boundaries explicit before implementation.
Workflow Specification - 3b
Add the Right Safety Checks
Confidence in a recommendation and permission to act answer different questions. Consider the consequences of a wrong action, who can authorize it, and how it can be reversed before deciding how independently the system should operate.
Workflow Control Plan - 3c
Carry the Work Across Teams and Tools
Systems can use different definitions and fall out of sync. A repair can also overwrite a fact another team owns. Name the rules that must remain true across both systems, then design the handoff and recovery around them.
Cross-System Operating Plan
Report, Learn, and Improve
Can we see what happened, determine whether it helped, and improve the process?
Capture the evidence while work happens (4a), interpret it in a useful report (4b), then turn findings into tested changes (4c). Each stage builds on a different question, not another version of the same dashboard.
- 4a
Make the Work Reportable
A report is not a view of what happened. It is a view of what got recorded, and those two diverge in ways invisible from inside the report. The person who did the work and logged it wrong is identical, in the number, to the person who did nothing.
Reporting-Ready Specification - 4b
Report on What Matters
A report can be arithmetically correct and still tell the wrong story. Define what the numbers include, pair each measure with the context it needs, and make every conclusion traceable to the records behind it.
Metric Dictionary and Reporting Brief - 4c
Use Reporting to Improve the System
The reports exist. Somebody looks at them. Nothing changes. Build the review rhythm and change process that turns a finding into an owned decision, a measured release, and a result the team can learn from.
Operating Review and Improvement Plan