Turn a founder's successful improvisation into a usable system
Use several wins and losses rather than a single best case. Identify the repeated buyer problem and buying roles, then separate special relationships or custom product promises from the standard motion. The transferable part is the decision logic, not every sentence the founder used.
Create a play with a trigger, source evidence, neutral discovery questions, stage acceptance, escalation and stopping condition. Let a new seller practice while the founder observes. Review disagreements against buyer evidence. If the process only works when the founder intervenes, identify the missing product context or decision rule.
| Decision | Evidence to use | What changes next |
|---|---|---|
| Account judgment | Observable fit and disqualifier conditions | A researcher can select unfamiliar accounts |
| Buyer judgment | Problem validation and meaningful next-step evidence | A seller can qualify without founder intuition alone |
| Commercial judgment | Scope, price and exception boundaries | Another owner can progress a standard decision responsibly |
Work through the decision
Illustrative founder pattern: three deals were won after buyers discussed manual monthly reconciliation. Write down who owned that workflow, why the issue mattered and which conditions made a standard implementation feasible. Then test a new seller on an account that lacks one of those conditions.
A repeatable system should help the seller reject the weak case, not pressure them to reproduce the founder's win. Documenting why not to proceed is part of the motion. The evidence from these attempts should revise the playbook while preserving the original reasoning.
Repeatable means rigid instead of reasoned
A script that prevents sellers from responding to new evidence is brittle. Preserve the core decision rules while allowing relevant questions and escalation. Track exceptions so they improve the system rather than becoming hidden founder interventions.
A concrete next step
Document one repeatable play from two wins and one loss. Have another seller apply it independently, then revise the missing decision rules before increasing activity.
Sources and research notes
- GitLab customer-ready shadow programCompany operating handbook
- GitLab sales operating proceduresCompany operating handbook
Primary sources reviewed October 6, 2026. The operating recommendations and worked scenarios are Daavid’s analysis. Illustrative numbers are assumptions, not measured client results. Company marks identify sources and prior experience; they do not imply a customer relationship or endorsement.
Schematic