Process optimization

# Process optimization

## Goal

Find the few handoffs and loops in the commercial engine that waste time, drop evidence, or sell a customer the next stage cannot honor, and specify the smallest change that would fix them.

Optimization is not a new ritual, a new meeting, or a new tool. It is a change to how work already moves from market → conversation → close → value → retention → product.

This is diagnosis and redesign. Do not reorganize people, rewrite production systems, or declare a transformation. Do not invent throughput numbers.

Complete the analysis autonomously. Do not stop to ask clarifying questions.

Do not modify application code.

## Prerequisites

Read the full current GTM set: ICP, market, positioning, pricing, campaigns, nurture, channels, pipeline, deals, collateral, onboarding, retention, feedback, stack, and metrics; any notes about missed handoffs, dropped leads, angry implementations, or founder bottlenecks; and any existing `docs/gtm/process.md`, `docs/gtm/process.yaml`, and `docs/gtm/process-changelog.md`.

If those files disagree, the disagreement is the first process defect.

## Evidence standard

Use the shared GTM labels.

A complaint about “alignment” is not a defect until it names a dropped object, a delayed stage, or a broken promise. A busy calendar is not proof the process is wrong. A quiet pipeline may be a market problem, not a workflow problem.

## Step 1: Draw the actual path

Map the current path of one beachhead purchasing unit from first touch to retained customer. Use what the files and repository say is actually done, not the org chart.

Mark each handoff: marketing to sales, sales to onboarding, onboarding to support, success to product, product back to GTM.

For each handoff record: object passed, required evidence, owner, typical delay, failure mode, and whether the next stage can refuse the work.

If a stage cannot refuse, it will absorb bad-fit work. That is a defect.

## Step 2: Find the constraint

Name the current constraint using evidence: demand, qualification, founder selling time, demo capacity, paper, implementation, support, or product gaps.

Do not optimize a non-constraint. Speeding top-of-funnel when onboarding is full makes the company worse.

If the constraint is “we do not have a position” or “we cannot qualify,” return `REVISIT` to that prompt instead of adding process.

## Step 3: Name defects, not vibes

List defects as testable failures:

* unqualified work enters the pipeline
* two stories are told in two stages
* sold path the product cannot implement
* evidence is re-collected because the previous stage did not write it down
* tools disagree on stage
* volume exceeds capacity
* RED requests skip the feedback rules
* metrics use a definition no stage honors

For each defect: evidence, cost in time or broken promises, owner, smallest fix, what would show the fix worked.

Propose at most three fixes this cycle. Unused process is also a defect.

## Step 4: Redesign the refusal and the write-back

Every stage needs:

* a way to refuse work
* a required written artifact
* a time box
* a path back to product or ICP when the same defect repeats

Write the weekly operating loop: what is reviewed, using which metrics, what decision can be made in that meeting, and who is allowed to skip it if there is nothing to decide.

If the loop cannot change a campaign, a gate, or a package, it is theater. Delete it.

## Step 5: Desk-test

1. The constraint is named and the fixes attack it.
2. Stages can refuse.
3. No fix adds a tool the stack prompt rejected.
4. No fix requires a team the company does not have.
5. Definitions stay consistent with metrics and pipeline.
6. The founder is not the undocumented integration layer in every handoff, or that fact is the constraint.

## Decision

* `CHANGE`: adopt the named fixes
* `CHANGE NARROWLY`: one handoff only
* `HOLD`
* `REVISIT` a named earlier GTM artifact
* `DO NOT ADD PROCESS`: the engine is not failing on workflow

Lead with:

“As of [date], the commercial constraint is [constraint]; the next process change is [fix or none], because [evidence]; decision [CHANGE / CHANGE NARROWLY / HOLD / REVISIT / DO NOT ADD PROCESS].”

## Deliverables

### 1. `docs/gtm/process.md`

Actual path, constraint, defects, at most three fixes, refusal rules, operating loop, desk tests.

### 2. `docs/gtm/process.yaml`

`version`, `status`, `decision`, `path`, `handoffs`, `constraint`, `defects`, `fixes`, `refusals`, `operating_loop`, `assumptions`, `unknowns`, `sources`.

### 3. `docs/gtm/process-changelog.md`

Append only.

## Boundaries

* Do not add meetings, tools, or roles as the default fix.
* Do not optimize a non-constraint.
* Do not invent SLA performance.
* Do not paper over a broken ICP, price, or product with workflow.
* Do not make the founder the silent integration layer without naming it.
* Preserve uncertainty.

## Done when

* The actual path and the constraint are explicit.
* At most three fixes are specified, or an explicit choice to add no process.
* Stages can refuse work.
* Desk tests passed or forced `HOLD`.
* The three files agree with the rest of the GTM set.