Someone changed the lead-scoring rule on a Tuesday. You know this because by Thursday the SDRs were saying the leads felt off, and by the following week pipeline was down enough to show up on a chart. You ask what changed. Nobody is quite sure. Someone adjusted a threshold, or added a condition, or removed one. There is no record of what the rule was before, who changed it, or why. The team spends a meeting trying to reconstruct a config that existed, in full, a week ago. We have sat in that meeting. You probably have too.

It happens because the most important logic in your go-to-market is treated as settings, not as code. And nobody reviews a settings change. You just make it.

The parts of your GTM that are actually code

Look at what runs your funnel and ask which pieces are really programs. Your ICP definition is a set of rules that decides who counts. Your lead scoring is a function: attributes and behavior in, a number out. Your routing is a switch statement. Your sequences are branching logic with timers, and your plays are conditionals: when this happens, do that.

None of it looks like code, because it lives in spreadsheet cells and CRM fields and the settings panels of five different tools. But it behaves like code. It has inputs, outputs, and edge cases. It breaks when an assumption changes upstream, and when it breaks it doesn't throw an error. It just returns the wrong answer and keeps going. The only thing it's missing is the discipline software teams invented to keep exactly this kind of logic from rotting: version control.

diff
  # lead-scoring, edited Tuesday 14:32- pricing_page_views >= 2     (+15 points)+ pricing_page_views >= 4     (+15 points)- score_threshold: 60+ score_threshold: 75​  author: unknown  reason: unknown  previous version: not kept

What version control actually buys you

Version control is not a tool. It is four habits, and you can practice all four without ever touching a repo.

The first is review. A change to scoring or routing gets a second set of eyes before it goes live, the same way a code change gets a pull request. Not because the person making it is careless. Because nobody can see the whole blast radius alone, and routing changes in particular have a way of starving one queue to feed another.

The second is attribution: every change has an author, a date, and a reason. When pipeline moves three weeks later, you can line the move up against what changed and when. Without attribution, every diagnosis starts with an investigation into who did what, and that investigation usually stalls.

The third, and the most underrated, is the diff. You can see exactly what changed: the threshold went from 60 to 75, this condition was added, that one removed. A diff turns "scoring feels off" into "scoring got stricter on the 9th," which is a sentence you can act on.

The fourth is the rollback. When a change makes things worse, you put the previous version back in minutes, because you kept it. Teams without rollback don't undo bad changes. They pile new changes on top, hoping to climb back out, and the config drifts further from anything anyone understands.

Review, attribution, diff, rollback. Software teams didn't adopt these because they enjoy process. They adopted them because a system that many hands touch, and that costs real money when it breaks, cannot be run any other way. Your funnel is that kind of system.

The four habits, as one pipeline A pipeline diagram in terminal style: change proposed, reviewed, shipped, diffed, then a dashed decision node asking "regresses?". The no path exits upward labeled "keep it." The yes path loops back under the pipeline into shipped, labeled "rollback: put the previous version back, in minutes." Code-comment tags under the stages read review, attribution, diff, rollback. four habits, one pipeline # every change to scoring, routing, ICP definitions, sequences no → keep it change proposed threshold: 60 to 75 reviewed second set of eyes // review shipped author · date · why // attribution diffed +2 -2 on record // diff regresses? watch the metric // rollback yes rollback: put the previous version back, in minutes # without the loop, new changes pile on top and the config drifts The four habits, as one pipeline A pipeline diagram in terminal style: change proposed, reviewed, shipped, diffed, then a dashed decision node asking "regresses?". The no path is labeled "keep it." The yes path is a rollback that puts the previous version back, in minutes, and loops back into shipped. Code-comment tags on the stages read review, attribution, diff, rollback. four habits, one pipeline # every change to scoring, routing, # ICP definitions, sequences change proposed threshold: 60 to 75 reviewed second set of eyes // review shipped author · date · why // attribution diffed +2 -2 on record // diff regresses? watch the metric // rollback no → keep it yes → rollback: put the previous version back, in minutes back into shipped # without the loop, the config drifts

You do not need a new tool to start

The reflex here is to go shopping for software that promises governance. You can, later, if you still want one. The habits matter more than the tooling, and you can install them this week with what you already have.

Pick the few artifacts that move the most money: scoring, routing, the ICP definition, the core sequences. For each one, write down the current version somewhere durable and shared. A doc is fine. Then make one rule: changes to these go through a short change-log entry before they ship. Author, date, what changed, why, what you expect it to do. Name an owner for each artifact, the person who has to be looped in. Add a light review step for anything that touches a money path, even if review is one message and a thumbs up.

YAML
CHANGE LOG: lead scoringdate:      2026-06-09author:    D. Reyeschange:    score_threshold 60 to 75; pricing_page_views minimum 2 to 4why:       SDRs reporting low-quality handoffs below 75 since the May ICP updateexpect:    fewer MQLs, higher accept rate; revisit in 2 weeksreviewed:  J. Park (thumbs up, 06-09)rollback:  previous config saved at gtm-config/scoring-2026-05-12.md

That is the whole system. A written current state, a change log, an owner, a review step. It is unglamorous. It will also save you the Tuesday-mystery meeting within a month, which is a good trade. Once the habit holds, you can decide whether a real tool is worth it. Most teams find the discipline was the hard part, not the software.

Stop relitigating, start diffing

The deeper cost of an unversioned go-to-market is not the occasional outage. It is that the team relitigates the same decisions forever. Without a record, every change is a fresh argument, because nobody can point to what was tried, when, and what happened. You debate scoring in March, and you debate the same scoring in June as if March never happened.

A change log ends that. The conversation stops being "what should scoring be" in the abstract and becomes "here is what we changed on the 9th, here is what it did, do we keep it or roll it back." That conversation converges.

Your go-to-market is software. It has been all along. Give it the four habits that keep software alive, and the Tuesday mystery stops being a recurring genre.