1 min lesson
Generalizable program primitives
Walk through each part of "Generalizable program primitives", then explain what each one does.
Step 1 of 2
The single idea that separates a GTM Engineer from an automation tinkerer is building a program as a primitive. Define it once and every future program becomes a configuration instead of a new build.
A program primitive has four parts. Hold them together and you have an abstraction; pull them apart per campaign and you have a maintenance problem waiting to happen.
- Audience
- Who is eligible - the segment definition, queried the same way everywhere.
- Entry rules
- What triggers a record into the program and the dedup/eligibility checks.
- Actions
- What the system does - enrich, score, route, notify, sync.
- Measurement
- The metrics every program reports the same way, so they're comparable.
The trap on the other side is bespoke automations per campaign. One marketer asks for a Zap, then another asks for a slightly different Zap and a year later there are forty undocumented flows that only one person understands and nobody dares to touch. That is the mess the JD is hiring you to prevent, not produce.
Knowing where to expose a knob versus hardcode it is the judgment call that keeps a primitive usable. Config-over-code lets non-engineers run programs without filing tickets; too much config creates a fragile machine anyone can break.