# AI-GTM Transformation Loop (DSAE)

> A build order for transforming toward an AI-native GTM function in four phases: decode, shape, amplify, evolve, run as a loop rather than a waterfall. The core framing: AI sales is a product, not a project; it gets versioned, not completed.

- Canonical URL: https://www.convios.com/en/methods/ai-gtm-transformation-loop
- Language version: https://www.convios.com/de/methodik/ai-gtm-loop
- Status: Convios practice framework
- Method library: https://www.convios.com/en/methods — Markdown: https://www.convios.com/en/methods.md

## Problem

AI initiatives in sales are frequently set up as one-off projects: select a tool, roll it out, close the project. Afterwards, playbooks, signals and automations go stale and the hoped-for effect fizzles. The transformation needs an order that starts at the constraint, and an operating mode built for ongoing iteration rather than an end state.

## Approach

1. Decode: diagnose the GTM function's constraint and sharpen positioning before automating anything.
2. Shape: build a shared, versioned playbook as one source of truth for the team and AI systems (ICP, personas, messaging).
3. Amplify: wire the channels into a signal-driven stack in which buying signals trigger workflows.
4. Evolve: introduce agents like team members, with a clear role, approvals and human decision-making.
5. Run the four phases as a recurring loop; each cycle versions the system further.

## Example

A typical case: a B2B software vendor has introduced several AI tools in sales, each as its own project with a completion date. A year later the prompts are stale, the data flows broken, and usage has gone dormant. The restart follows the loop: first clarify constraint and positioning, then build a shared playbook, then wire up the signals, and only then introduce agents. The decisive part is the operating mode: one owner keeps versioning the system in fixed cycles instead of declaring it finished.

## Limits

The loop is a practitioner framing and not independently validated; its phases largely coincide with established methods for positioning, demand and orchestration. It describes the GTM rebuild, not enterprise-wide AI transformation. Without permanent ownership the system falls back into the project mode it is meant to avoid.

## Metric

Cycle cadence and version state of the system (playbook, signals, agent charters), plus how the constraint evolves from round to round.

## Sources

- A Spiral Model of Software Development and Enhancement — IEEE Computer 21(5) (Barry W. Boehm), 1988 · academic and scholarly literature · supports the underlying mechanism. Carries the principle of running a transformation in repeated, risk-driven rounds rather than in a single pass. (https://www.cse.msu.edu/~cse435/Homework/HW3/boehm.pdf)
- Primary source: A Spiral Model of Software Development and Enhancement (https://www.cse.msu.edu/~cse435/Homework/HW3/boehm.pdf)

## Related

- Method: [AI-GTM Maturity (4 Levels)](https://www.convios.com/en/methods/ai-gtm-maturity-levels)
- Method: [GTM Stack Signal Routing](https://www.convios.com/en/methods/gtm-stack-signal-routing)
- Method: [Leading AI Agents as Team Members](https://www.convios.com/en/methods/ai-agents-as-team-members)