Raus aus der Feature Trap: Wie wir von Development-Sprints auf Growth-Sprints umgestellt haben

Teil 2 der Serie „Von Engineering zu Growth" — was passiert, wenn ein Entwickler-Kopf auf Marketing-Methoden trifft.

---

Die Feature Trap

Es gibt ein Gefühl, das jeder kennt, der Software baut: Ein Feature geht live, die Pipeline ist grün, das Ding läuft in Produktion. Erfolgserlebnis. Also weiter — nächstes Feature, nächster Merge, nächstes Release.

Genau dieses Gefühl ist die Falle.

Denn „wir haben viel gebaut" und „wir haben etwas erreicht" sind zwei verschiedene Dinge. Mehr Features fühlen sich nach Fortschritt an, weil das Shippen selbst belohnt. Ob das Feature jemand braucht, ob es jemand findet, ob es jemand nutzt — darüber sagt das grüne Pipeline-Häkchen nichts aus.

Ich habe jahrelang Frontend-Teams geleitet und Infrastruktur gebaut, damit genau dieses Shippen so schnell wie möglich geht: k3s für Development, k8s in Produktion, ArgoCD, Jenkins-Multipipelines, RBAC-Policies. Mein Job war, dem Team den Rücken freizuhalten. Velocity war die Währung.

Bis wir in meinem Unternehmen ein eigenes Produkt gebaut hatten und mir klar wurde: Unser Bottleneck ist nicht mehr die Entwicklung. Unser Bottleneck ist, dass niemand weiß, dass es uns gibt.

Der Umbau: Sprints behalten, Inhalt tauschen

Wie ich im ersten Teil dieser Serie beschrieben habe, haben wir die grundlegende Sprint-Mechanik nicht über Bord geworfen. Sie bleibt unser Fundament. Doch in diesem Schritt ging es um das Alignment auf Ticket-Ebene und die Führung des Teams: Wie steuert man Engineers, wenn das Ziel plötzlich ein Marketing-Goal ist? Die Technik bleibt bestehen, aber sie ordnet sich der Distribution unter. Die Tabellen-Struktur zeigt den systematischen Shift auf Organisationsebene:

	Development-Sprint	Growth-Sprint
Unit	User Story / Task	Experiment
Key Question	„What are we building?"	„What are we learning?"
Prioritization	Story Points, Velocity	ICE-Score
Success	Feature is live	Hypothesis validated or invalidated
Tools	Grafana, CI/CD	Matomo, Meta Business Suite

Als Engineering Manager ändert sich dadurch die Art der Führung: Ich tracke nicht mehr reine Code / Velocity, sondern leite das Team an, technische Exzellenz direkt auf messbare Marketing-Ziele anzusetzen. Ein Ticket ist im Growth-Modell erst erledigt, wenn wir eine klare Antwort vom Markt haben — und „Hypothesis" validiert ist eine genauso wertvolle Antwort wie „nicht valide".

Anatomie eines Experiment-Tickets

Jedes Ticket bei uns hat drei Pflichtteile. Ohne die wird nichts angefasst.

1. Idea, Hypothesis, Goal

Kein „Lass uns mal X machen", sondern immer dieselbe Struktur:

Wenn wir [Maßnahme umsetzen], dann erwarten wir [messbares Verhalten], weil [Begründung, warum das plausibel ist].

Das „weil" ist der unterschätzte Teil. Es zwingt einen, die Annahme über den Nutzer explizit zu machen — und genau diese Annahme wird getestet, nicht die Maßnahme.

2. KPI: How to track this

Bevor irgendetwas umgesetzt wird, steht im Ticket, wo genau der Erfolg sichtbar wird: welches Dashboard, welcher Report, welche Metrik. Wenn wir nicht sagen können, wie wir messen, ist das Experiment nicht bereit.

Als Entwickler kam mir das sofort vertraut vor: Es ist im Grunde eine Definition of Done — nur dass sie nicht im Code liegt, sondern in den Daten.

3. ICE-Score

Priorisiert wird mit drei Werten von 1 bis 10:

• Impact — wie groß ist der Hebel, wenn es funktioniert?
• Confidence — wie sicher sind wir, dass es funktioniert?
• Ease — wie leicht ist es umzusetzen?

Die Summe entscheidet, was zuerst drankommt. Das klingt banal, hat aber einen enormen Effekt: Diskussionen über „coole Ideen" verschwinden. Stattdessen streitet man über Zahlen — und das ist ein Streit, den man auflösen kann.

Ein echtes Beispiel aus unserem Board

Damit das nicht abstrakt bleibt, hier eines unserer aktuellen Tickets: SEO Optimization & AI Search Discovery.

Hypothese: Wenn wir unsere Inhalte optimieren und SEO-Landing-Pages für Keywords rund um schnelles, kostenloses Backtesting erstellen, dann erwarten wir, dass Nutzer uns über AI-Suchmaschinen entdecken und testen — messbar als Strom von High-Intent-Traffic auf unsere Landing Pages. Weil Nutzer, die nach schnellen und kostenlosen Tools für Backtesting suchen, bereits eine starke Absicht mitbringen, ihre Ideen sofort auszuprobieren.

KPI: Im Acquisition-Report beobachten wir, ob die AI-Assistant-Tabelle beginnt, Referral-Traffic von Quellen wie ChatGPT, Perplexity oder Gemini zu zeigen. Dort tracken wir direkt die Conversion auf unser definiertes Ziel — bei uns heißt es „Guest Access started".

ICE: Impact 8, Confidence 5, Ease 7 -> 20 Punkte.

Interessant an diesem Ticket: Die Confidence ist bewusst nur eine 5. Wir wissen nicht, ob AI-Suchmaschinen für uns ein relevanter Kanal sind. Genau deshalb ist es ein Experiment und kein Projekt. In der alten Denkweise hätten wir vermutlich drei Monate eine „SEO-Strategie" gebaut, bevor irgendjemand eine Zahl gesehen hätte.

Was sich nach zwei Sprints verändert hat

Wir arbeiten erst seit wenigen Sprints nach dieser Methodik, aber die Veränderungen decken sich exakt mit den erprobten Standards moderner Product-Led-Growth-Teams:

Erstens: Objektive Priorisierung statt Meinungen. Die Roadmap-Diskussionen sind radikal verkürzt. Durch das standardisierte ICE-Scoring eliminieren wir den klassischen „HiPPO-Effekt“ (Highest Paid Person’s Opinion). Wer eine Idee höher priorisieren will, muss Impact oder Confidence datenbasiert verargumentieren — nicht, warum die Idee gefühlt „wichtig" ist.

Zweitens: Daten-Validierung vor Code-Auslieferung. Es wird weniger ungetesteter Code gebaut und deutlich mehr gemessen. Im Growth Engineering ist es Branchen-Standard, Hypothesen zuerst über Low-Code-Experimente, Landing-Page-Variationen oder Kampagnen zu validieren. Der wertvollste Sprint-Inhalt ist oft der, bei dem kein einziges Deployment stattfindet, weil er unnötigen Entwicklungsaufwand verhindert.

Drittens: Fehlerkultur als statistischer Standard. Scheitern ist mathematisch eingepreist. Die Growth-Praxis zeigt, dass weit über 50 % aller validierten Hypothesen fehlschlagen. Wenn eine Hypothese mit Confidence 5 startet und kippt, ist das kein Fehlschlag, sondern ein valides Daten-Ergebnis, das den Druck rausnimmt und das Team ehrlicher macht.

Viertens: Der Shift zu Taste, Judgment und Green Path. Früher lag unser Fokus rein auf How to build (Infrastruktur, Skalierbarkeit, Pipelines). Heute verschiebt sich ein Großteil unserer Zeit auf die Fragen What to build, When to build und Why to build. Es erfordert tiefes Problem-Verständnis und „Taste & Judgment“, um den optimalen Wachstumspfad (Green Path) des Nutzers zu explorieren — während unsere solide Software-Architektur weiterhin das stabile Fundament bildet, um gewonnene Erkenntnisse sofort nachhaltig zu skalieren.

Ps. Für Produkt Owner ist das ein Spielparadies. Bzw. für uns IT Teamleiter, die nicht nur die Technik im Blick haben sondern auch den Impact dahinten.

Was Entwickler daraus mitnehmen können

Falls du aus dem Engineering kommst und dich fragst, ob dieser Denkwechsel etwas für dich ist: Die Werkzeuge sind vertrauter, als man denkt. Hypothesen sind Unit Tests für Geschäftsannahmen. KPIs sind Monitoring. ICE ist Priorisierung nach Aufwand-Nutzen — das machen wir beim Tech-Debt-Abbau seit Jahren.

Neu ist nur die Frage, die man stellt. Nicht: „Läuft es?" Sondern: „Bewierkt es etwas?"

---

Im nächsten Teil der Serie: Zum ersten Mal mit Marketern arbeiten — warum diese Leute anders denken, was Meta Business Suite und Matomo mit meinem Grafana-Reflex gemacht haben, und welche Vokabeln ich lernen musste. Außerdem: Was machen Entwickler, wenn das Leadership-Team mit Hypothesen beschäftigt ist, und wo liegt nun der Bottleneck?