GTM-Grundlagen - GTM-Team-Struktur: Das richtige Modell für Ihre Phase
Die meisten Gespräche über GTM-Struktur beginnen mit einem Organigramm und enden in einem Einstellungsplan. Diese Reihenfolge ist verkehrt. Struktur ist die Folge von zwei Dingen: der gewählten Mechanik und der Größe des Deals, den Sie verfolgen. Stimmen diese, zeichnet sich das Organigramm weitgehend von selbst.
Diese Seite behandelt die drei Strukturmodelle, die in der Praxis tragen, wie die Berichtslinien darin verlaufen sollten, die konkreten Signale dafür, dass Sie Ihre aktuelle Form überwachsen haben, und wie Sie den Übergang durchführen, ohne ein Quartal zu verlieren.
7 Min. Lesezeit7 AbschnitteGTM-Grundlagen
Das nehmen Sie mit
- Struktur folgt Mechanik und Dealgröße. Ein Self-Serve-Produkt für 5.000 € und ein Enterprise-Deal über 250.000 € können sich kein Organigramm teilen.
- Zentrales RevOps gehört in jedes Modell, auch in die kleinen — der Umfang ändert sich, der Bedarf nicht.
- Das Pod-Modell bringt zwischen etwa 2 und 20 Mio. € ARR die höchste Rendite — und wird am häufigsten falsch umgesetzt.
- Übergänge scheitern, wenn sie verkündet statt sequenziert werden. Zuerst Definitionen und Daten bewegen, dann Menschen.
Was Ihre Struktur tatsächlich bestimmt
Bevor Sie ein Modell wählen, seien Sie bei vier Eingangsgrößen ehrlich. Jede davon beschränkt die Form stärker als jede Organisationsphilosophie.
- Durchschnittlicher Vertragswert
- Unter etwa 5.000 € im Jahr trägt sich menschlicher Vertrieb selten selbst; die Struktur sollte sich auf Produkt und Marketing stützen. Über 50.000 € brauchen Sie Discovery, technische Validierung und Multi-Threading — also spezialisierte Rollen.
- Länge des Verkaufszyklus
- Einen Zweiwochenzyklus kann eine Person durchgängig führen. Ein Neunmonatszyklus mit Einkaufsphase und Security-Review braucht Übergaben — und Übergaben brauchen eine Operations-Funktion, um sie zu überstehen.
- Größe des Buying Committee
- Ein Entscheider bedeutet eine Beziehung. Sechs Stakeholder aus Finanzen, IT, Security und Fachbereich bedeuten, dass Sie Menschen brauchen, die jede dieser Sprachen sprechen.
- Primäre Mechanik
- Inbound, Outbound, produktgetrieben und partnergetrieben verlangen je einen anderen Schwerpunkt. Zwei davon ernsthaft gleichzeitig zu betreiben verdoppelt den Koordinationsaufwand — ein Strukturkosten-, kein Personalkostenproblem.
Schreiben Sie diese vier Punkte auf, bevor Sie Kästchen zeichnen. Teams, die diesen Schritt überspringen, kopieren meist das Organigramm eines Unternehmens drei Phasen weiter und wundern sich dann, warum Koordination ihre Woche auffrisst.
Modell 1: Founder-led
Bis etwa 1–2 Mio. € ARR sind die Gründer das GTM-Team. Das ist kein schnell zu behebender Mangel, sondern die einzige Phase, in der die Person, die über das Produkt entscheidet, in jedem Verkaufsgespräch sitzt — und dieser Rückkopplungskreis ist mehr wert als jeder Prozess, den Sie stattdessen einführen könnten.
Der Fehlermodus ist nicht das Modell, sondern das, was in dieser Phase unterbleibt. Gründer verkaufen intuitiv, passen den Pitch in Echtzeit an und behalten alles im Kopf. Nichts davon lässt sich übertragen. Wenn die erste Vertriebseinstellung kommt, übergibt man ihr eine Mechanik, die nur in einem Kopf existiert.
- Wer macht was
- Ein Gründer verantwortet Discovery, Pricing und Abschluss. Ein Marketing-Generalist deckt Content, Website und Events ab. Alles Operative ist manuell — bei diesem Volumen ist das in Ordnung.
- Was Sie trotzdem aufbauen sollten
- Ein schriftlicher ICP, aufgezeichnete Gespräche, ein einziges CRM mit ehrlichen Phasendefinitionen und ein Dokument, das das Verkaufsgespräch beschreibt. Zwei Tage Arbeit, die die erste Einstellung Monate früher produktiv machen.
- Wann Sie wechseln sollten
- Wenn die Kalenderzeit der Gründer der begrenzende Faktor für die Pipeline ist oder wenn Gründer Deals abschließen, die sie nicht mehr gut betreuen können. Beides ist meist ein Quartal sichtbar, bevor jemand handelt.
Modell 2: Pods und Squads
Zwischen etwa 2 und 20 Mio. € ARR schlägt das Pod-Modell die Alternativen zuverlässig. Ein Pod ist eine kleine funktionsübergreifende Gruppe — typischerweise Demand Generation, ein SDR, ein bis zwei Account Executives und ein Customer-Success-Kontakt — die ein Segment, eine Region oder eine Produktlinie durchgängig verantwortet.
Der Grund ist Eigentümerschaft. Wenn dieselben vier Personen für den gesamten Weg vom Erstkontakt bis zur Verlängerung in einem Segment verantwortlich sind, verschwindet das Übergabeproblem weitgehend, weil es keine organisatorische Grenze gibt, an der Kontext verloren geht.
| Rolle | Anzahl | Verantwortung |
|---|---|---|
| Account Executive | 2 | Discovery bis Abschluss für das Segment |
| SDR / BDR | 1 | Outbound und Inbound-Qualifizierung für diese AEs |
| Demand Generation | 0,5–1 | Segmentspezifische Kampagnen und Content |
| Customer Success | 1 | Onboarding, Adoption und Verlängerung der vom Pod gewonnenen Accounts |
| RevOps (zentral, geteilt) | — | Definitionen, Daten, Reporting, Tooling über alle Pods hinweg |
Zwei typische Fehlumsetzungen: jedem Pod einen eigenen Prozess geben, was die Vergleichbarkeit im Unternehmen zerstört; und RevOps in einem Pod statt zentral zu verankern, wodurch niemand Konsistenz verantwortet. Prozess zentral, Eigentümerschaft lokal.
Modell 3: spezialisierte Funktionsorganisation
Ab etwa 20 Mio. € ARR schlägt Tiefe die Breite. Enterprise-Deals brauchen dedizierte Solutions Engineers, Partnerschaften eine echte Funktion, und Demand Generation teilt sich in Paid, Content, Lifecycle und Field. Die Organisation wird zu Funktionsteams unter einem CRO, mit RevOps und GTM-Engineering als zentralen Shared Services.
Der Preis sind Nahtstellen. Jede zusätzliche Spezialisierung schafft eine weitere Grenze, an der ein Deal Momentum verliert — überlebensfähig bleibt das nur mit einer starken Operations-Schicht, die echte Autorität über Prozess und Daten hat.
- Berichtslinien
- Marketing, Vertrieb und Customer Success unter einer Revenue-Führung. RevOps ebenfalls dorthin — nicht an die Finanzabteilung, wo es zur Reporting- statt zur Betriebsfunktion wird.
- Verortung von GTM-Engineering
- Innerhalb von RevOps oder als gleichrangiges Team, nie im Produkt-Engineering-Backlog vergraben. Konkurriert GTM-Engineering mit kundenseitigen Features um Priorität, verliert es jedes Quartal und das Revenue-Tooling wird nie ausgeliefert.
- Was zentral bleiben muss
- Definitionen, Datenmodell, Forecast-Methodik und Tool-Stack. Funktionen dürfen ihre Taktik besitzen — aber nicht ihre eigene Version der Wahrheit.
Wo RevOps sitzt — und warum meist falsch
Revenue Operations ist die eine Funktion, die in jeder funktionierenden Struktur vorkommt — und die am häufigsten falsch verortete. Drei Platzierungen sind verbreitet, nur eine funktioniert gut.
Unter der Finanzabteilung wird RevOps zur Reporting-Funktion: korrekt, rückwärtsgewandt und strukturell unfähig, die Arbeitsweise des Revenue-Teams zu verändern. Im Vertrieb wird daraus Sales Operations, und die Marketingdaten verfallen leise. Die Berichtslinie an die Revenue-Führung mit Mandat über alle kundenseitigen Funktionen ist die Platzierung, die tatsächlich liefert.
Signale, dass Sie Ihre Struktur überwachsen haben
Strukturwandel ist so störend, dass die meisten Teams zu lange warten. Diese Signale lohnen ein Handeln, ungefähr in der Reihenfolge ihres Auftretens.
- Der Forecast ist eine Verhandlung
- Wenn die Führung die von Vertrieblern gemeldete Zahl routinemäßig korrigiert, bedeuten Phasendefinitionen nichts mehr und Sie brauchen eine zentrale Operations-Funktion mit Autorität.
- Dieselbe Frage bekommt drei Antworten
- Fragen Sie drei Personen nach der Win-Rate des letzten Quartals. Drei verschiedene Zahlen bedeuten, dass Ihr Datenmodell Ihre Governance überwachsen hat.
- Übergaben brauchen jemanden, der hinterherläuft
- Wenn jemand täglich Zeit darauf verwendet sicherzustellen, dass Leads beim richtigen Vertriebler landen, sollte das Routing Code sein — und die Struktur einen Verantwortlichen dafür haben.
- Vertriebler verkaufen alles
- Decken AEs jedes Segment, jede Größe und jeden Use Case ab, flachen Win-Rates ab und niemand entwickelt Tiefe. Das ist der Auslöser für die Segmentierung in Pods.
- Pods sind auseinandergelaufen
- Zwei Pods, die dieselbe Kennzahl unterschiedlich berichten, sind das Signal, den Prozess zu zentralisieren und Eigentümerschaft lokal zu lassen — nicht, das Pod-Modell aufzugeben.
Wie Sie eine Umstrukturierung ohne Quartalsverlust durchführen
Umstrukturierungen scheitern aus einem vorhersehbaren Grund: Sie werden als Organisationsänderung verkündet, während die eigentliche Arbeit eine Daten- und Definitionsänderung ist. In dieser Reihenfolge bleibt die Störung beherrschbar.
Ist-Zustand einfrieren und dokumentieren
Schreiben Sie die heutigen Phasendefinitionen, Routing-Regeln, Zuständigkeiten und Reports auf, so unvollkommen sie sind. Ohne Basislinie lässt sich der Erfolg nicht messen — und das Aufschreiben fördert meist zwei oder drei Regeln zutage, von denen niemand wusste, dass sie noch laufen.
Neue Definitionen vor neuen Kästchen festlegen
Phasendefinitionen mit Austrittskriterien, Qualifizierungsschwellen, Segmentgrenzen und Übergabe-SLAs. Schriftlich abgestimmt mit den Menschen, die daran gemessen werden.
Datenmodell entsprechend umbauen
Segmentfelder, Territory-Zuweisung, Eigentümerregeln und Reporting-Objekte im CRM aktualisieren, bevor jemand den Platz wechselt. Der Schritt, der Engineering-Zeit braucht und den Teams zu überspringen versuchen.
Pipeline explizit migrieren
Account für Account entscheiden, wer zum Stichtag was verantwortet. Unklarheit erzeugt genau die verlorenen Deals, die eine Umstrukturierung wie einen Fehler aussehen lassen.
Menschen bewegen und ein Quartal Kurs halten
Die Struktur verkünden, sobald das System darunter sie trägt. Danach mindestens ein Quartal nicht erneut ändern — Sie brauchen eine saubere Messperiode, um zu wissen, ob es funktioniert hat.
Gegen die Basislinie auswerten
Phasenkonversion, Zykluslänge und SLA-Einhaltung gegen die eingefrorene Basislinie vergleichen. Bewegen sich die Zahlen nicht, war das Problem nicht strukturell — auch das ist eine wertvolle Erkenntnis.
Häufige Fragen
Was ist die ideale GTM-Team-Struktur?
- Es gibt keine einzelne ideale Struktur. Die richtige ergibt sich aus durchschnittlichem Vertragswert, Zykluslänge, Größe des Buying Committee und primärer Mechanik. Praktisch: Founder-led bis etwa 2 Mio. € ARR, funktionsübergreifende Pods zwischen 2 und 20 Mio. €, darüber spezialisierte Funktionen unter einem CRO.
Sollte RevOps an den Vertrieb oder an Finance berichten?
- An keines von beiden. RevOps sollte an die Revenue-Führung berichten, mit Mandat über Marketing, Vertrieb und Customer Success. Unter Finance wird daraus eine rückwärtsgewandte Reporting-Funktion; unter Vertrieb verfällt die Datenqualität in Marketing und CS.
Wie viele Personen gehören in einen GTM-Pod?
- Vier bis sechs ist der praktikable Bereich: ein bis zwei Account Executives, ein SDR, eine geteilte Demand-Generation-Ressource und ein Customer-Success-Kontakt. Größere Pods brauchen interne Koordination — genau den Overhead, den das Modell vermeiden soll.
Wann sollten wir eine GTM-Engineering-Funktion aufbauen?
- Wenn Integrations- und Automatisierungsanfragen hinter der Produkt-Roadmap warten oder wenn jemand in RevOps den Großteil der Woche mit manueller Datenarbeit verbringt. Das ist meist zwischen 3 und 10 Mio. € ARR der Fall.
Wie oft sollte sich die GTM-Struktur ändern?
- Selten und nie mitten im Quartal. Die meisten Unternehmen brauchen eine Strukturänderung bei jedem Größensprung des Umsatzes. Häufiger als jährlich zu ändern deutet meist darauf hin, dass ein Definitions- oder Datenproblem für ein Strukturproblem gehalten wird.
Ein neues Organigramm repariert kein kaputtes Datenmodell
Wir bauen die CRM-Architektur, Routing-Logik und Reporting-Schicht neu, von der eine Umstrukturierung abhängt — damit die neue Struktur ab Tag eins funktioniert statt ab Quartal drei.