Ein Vertriebsleiter präsentiert das nächste Kundenprojekt. Sechs Wochen Individualentwicklung, dann Go-Live. Drei Monate später sitzt ein anderes Team an einer ähnlichen Lösung – für einen anderen Kunden, mit eigenem Code, eigener Dokumentation und eigenem Wartungsaufwand. Niemand hat etwas falsch gemacht. Trotzdem entsteht ein grundsätzliches Problem: Mit jedem neuen Kunden wachsen nicht nur Umsatz und Geschäft, sondern fast im gleichen Maße Entwicklungsaufwand, Wissenssilos und Komplexität. Das Unternehmen wächst aber es skaliert nicht.
Das Perfide dabei: die negativen Folgen werden meist erst sichtbar, wenn sie weit vorangeschritten sind.
Genau solche Strukturen schauen wir uns mit Produktteams und Führungskräften genauer an. Denn hinter vermeintlichen Produktproblemen stecken häufig Organisationsfragen: Wofür sind Teams dauerhaft verantwortlich? Wer entscheidet über Investitionen? Was wird einmal für viele Kunden entwickelt und was bewusst individuell?
Die Antwort darauf lautet aus unserer Sicht nicht automatisch: „Ihr müsst jetzt produktorientiert arbeiten.“ Gerade in Technologieunternehmen mit komplexen B2B-Produkten haben projektorientierte Strukturen gute Gründe. Schwierig wird es dort, wo jedes neue Kundenprojekt wieder bei null beginnt und Wachstum fast zwangsläufig mehr Menschen, mehr Sonderlösungen und mehr Komplexität bedeutet.
Auf dieser Seite zeigen wir euch deshalb, was hinter dem Product Operating Model und der produktorientierten Organisation steckt, woran ihr die Grenzen einer Projektlogik erkennt.
Und vor allem, wo mehr Produktorientierung tatsächlich sinnvoll ist und wo nicht.
Woran Führungskräfte projektorientierte Arbeit als Wachstumsbremse erkennen
Die Symptome zeigen sich selten im einzelnen Projekt. Sie zeigen sich in der Summe: Jede Kundenanfrage startet wieder bei null. Lösungen, die technisch fast identisch sind, tragen unterschiedliche Namen, unterschiedliche Verträge, unterschiedliche Wartungsmodelle. Skalierung bedeutet fast ausschließlich mehr Personal, nicht mehr Hebel pro Mitarbeiter.
Einzelne dieser Symptome kommen in jeder Organisation gelegentlich vor. Kritisch wird es, wenn mehrere davon gleichzeitig zutreffen:
Die technische Schuld wächst schneller als neue Funktionen, weil jede Kundenlösung ihre eigene Architektur mitbringt.
Kritisches Wissen über einzelne Systeme sitzt bei wenigen Personen, deren Ausfall den Betrieb real gefährdet.
Umsetzungszeiten steigen von Projekt zu Projekt, weil niemand mehr genau überblickt, was in welcher Lösung tatsächlich steckt.
Der Umsatz wächst, die Profitabilität stagniert oder sinkt, weil jedes Projekt eigene Fixkosten trägt statt bestehende Strukturen zu nutzen.
Neue Kundenanfragen werden nach freier Kapazität priorisiert, nicht nach strategischer Passung zum Portfolio.
Neue Mitarbeiter brauchen ungewöhnlich lange fürs Onboarding, weil Wissen in Projektdokumentation verstreut liegt statt in wiederverwendbaren Produktstrukturen.
Nach außen fehlt eine klare Antwort auf die Frage, wofür das Unternehmen eigentlich steht. Der Vertrieb verkauft einzelne Lösungen statt eines Portfolios mit erkennbarer Identität. Investoren, Kunden und neue Mitarbeiter bekommen kein konsistentes Bild. Positionierung wird schwierig, weil jedes Projekt sein eigenes Narrativ mitbringt.
Roadmaps existieren in vielen projektorientierten Organisationen nur als Wort. Tatsächlich handelt es sich um eine sortierte Liste von Kundenprojekten, priorisiert nach Vertragsdatum statt nach strategischer Wirkung. Das nächste große Kundenprojekt bestimmt die Kapazität, nicht die nächste Produktentscheidung.
Projektorientierte Arbeit liefert eine Lösung für einen konkreten Auftrag, mit definiertem Anfang und Ende. Das Team löst sich nach Abschluss auf oder wechselt zum nächsten Auftrag.
Produktorientierte Arbeit organisiert sich um ein bestehendes Produkt oder eine Produktlinie mit dauerhafter Verantwortung. Das Team bleibt bestehen, lernt aus jedem Release und trägt die Konsequenzen langfristig mit.
- Projekt: befristet, auftragsbezogen, endet mit Abnahme
- Produkt: dauerhaft, outcome-bezogen, endet nie wirklich
Product Operating Model: der Begriff hinter der produktorientierten Organisation
Der Begriff Product Operating Model stammt aus Marty Cagans Buch „Transformed“ und beschreibt, wie Organisationen arbeiten müssen, damit Produkte erfolgreich werden: befähigte Teams, erkenntnisbasierte Strategie, kontinuierliche Discovery, verlässliche Delivery. Cagan hat den Begriff geprägt, nicht die Idee dahinter. Autor:innen wie Mik Kersten beschreiben denselben Wandel unter dem Titel „Project to Product“, Teresa Torres über die Praxis kontinuierlicher Discovery. Der Kern bleibt gleich: Organisationen verschieben ihre Struktur von befristeten Lieferaufträgen zu dauerhafter Produktverantwortung.
Für die praktische Umsetzung zählt weniger, welchem Autor man folgt, sondern welche Verschiebung tatsächlich stattfindet. Teams bekommen Probleme statt Anforderungslisten. Erfolg wird an Wirkung gemessen, nicht am Liefertermin. Strategie bedeutet, sich für wenige Wetten zu entscheiden, statt jede Kundenanfrage zu bedienen. Wie sich diese Verschiebung über die vier Dimensionen Teams, Strategy, Discovery und Delivery konkret zeigt, bildet unser Produktaktivitätsrahmen ab, eine Übersicht der strategischen, Inbound- und Outbound-Aktivitäten produktorientierter Teams.
Ein Projekt endet. Ein Produkt bleibt. Und mit ihm bleibt die Verantwortung, dass es weiter funktioniert.
Webinar: Das Product Operating Model – vier Dimensionen für wirkungsstarke Produktarbeit
In der Webinaraufzeichnung mit Ulf Greiner ordnen wir die vier Dimensionen Teams, Strategy, Discovery und Delivery sowie die 20 zugrunde liegenden Prinzipien ein und zeigen, woran ihr erkennt, ob euer Team wirklich befähigt ist.
Webinaraufzeichnung ansehenWann projektorientiertes Arbeiten weiterhin die richtige Wahl bleibt
Komplexe B2B-Produkte mit hohem Individualisierungsgrad brauchen häufig projektnahe Strukturen, nicht aus Rückständigkeit, sondern weil der Markt es verlangt. Anlagenbau, Systemintegration, regulierte Branchen mit kundenspezifischen Compliance-Anforderungen: Hier bestimmt der einzelne Kunde einen erheblichen Teil der Lösung. Eine reine Produktorganisation, die versucht, jeden Kunden in eine Standardlösung zu pressen, verliert genau die Kunden, die für Individualität bezahlen.
Der Übergang ist selten vollständig. Die meisten Unternehmen, die produktorientierter arbeiten wollen, behalten projektorientierte Elemente dort, wo Kundenbindung über maßgeschneiderte Betreuung entsteht, und verschieben die Produktlogik dorthin, wo Wiederverwendung und Skalierung den größeren Hebel bringen.
| Merkmal | Produktorientierung im Vorteil | Projektorientierung bleibt sinnvoll |
|---|---|---|
| Kundenbedarf | Ähnliche Bedarfe über viele Kunden hinweg | Stark individuelle, kundenspezifische Anforderungen |
| Wiederverwendung | Hohe Wiederverwendung von Code, Prozessen, Komponenten | Jede Lösung unterscheidet sich strukturell |
| Skalierungslogik | Ein Investment bedient viele Kunden | Ein Investment bedient einen Kunden |
| Vertriebsversprechen | Standardisiertes Leistungsversprechen | Maßgeschneidertes Leistungsversprechen als Verkaufsargument |
| Team-Zuschnitt | Dauerhaft am Produkt, über Releases hinweg | Befristet, zugeschnitten auf Projektlaufzeit |
Was Unternehmen und Kunden gewinnen – und was sie aufgeben
Produktorientierung ist kein Nullsummenspiel zugunsten des Unternehmens. Beide Seiten der Vertragsbeziehung tragen Vor- und Nachteile, unterschiedlich stark je nachdem, wie individuell der tatsächliche Bedarf ist.
Für Unternehmen liegt der größte Hebel nicht nur in Kosten, sondern in Steuerbarkeit. Wer produktorientiert arbeitet, bestimmt die eigene Roadmap selbst, statt bei jeder Kundenanfrage neu zu entscheiden, wohin sich das Portfolio entwickelt. Projektgetriebene Organisationen laufen dagegen Gefahr, sich in Marktsegmente ziehen zu lassen, die zwar kurzfristig Umsatz bringen, aber kein ausreichendes Wachstumspotenzial haben, einfach weil ein Kunde zufällig danach gefragt hat. Standardisierte Prozesse verkürzen zudem Lieferzeiten und beschleunigen die Fakturierung, während individuelle Projekte oft erst nach vollständiger Abnahme abgerechnet werden können.
Die Kehrseite: Eine produktorientierte Entscheidung ist eine Wette auf die Zukunft, kein bestätigter Auftrag. Trifft sie den tatsächlichen Bedarf nicht, betrifft das Problem alle Kunden gleichzeitig, nicht nur einen.
| Perspektive | Vorteile | Nachteile |
|---|---|---|
| Fürs Unternehmen | Kostensenkung durch Skaleneffekte in Produktion, Prozessen und Support. Aufbau von eigenem geistigem Eigentum. Leichtere Steuerung und Vermarktung, etwa durch übergreifende Datenanalyse. Mehr Kontrolle über die eigene Strategie, statt von einzelnen, kaum planbaren Kundenanfragen getrieben zu werden. Schnellere Lieferung an Kunden und schnellere Fakturierung. | Die Investition ist spekulativ und basiert auf einer Zukunftsprognose, nicht auf einem bestätigten Auftrag. Löst das Problem oft weniger zielgenau als eine Individuallösung. Verlangt Bekenntnis zu einer laufenden Roadmap, auch wenn einzelne Kunden andere Prioritäten setzen. Produktfehler betreffen alle Kunden gleichzeitig. Die Lösung lässt sich für Wettbewerber leichter kopieren als eine kundenspezifische Individuallösung. |
| Für die Kunden | Erhalten eine bereits bewährte Lösung statt eines Prototyps. Verstehen das Angebot leichter, weil es sich nicht von Fall zu Fall unterscheidet. Profitieren von einem Ökosystem rund um das Standardprodukt. Zahlen in der Regel weniger als für eine Individuallösung. Sehen eine Zukunftsvision und Roadmap, statt nur die aktuelle Version. | Das Produkt erfüllt selten alle individuellen Anforderungen vollständig. Ungenutzte Funktionen erhöhen die Betriebskosten und schränken die Nutzbarkeit ein. Differenzierung gegenüber Wettbewerbern sinkt, wenn diese dasselbe Standardprodukt einsetzen. Integration in bestehende Systeme verursacht mitunter Zusatzkosten, neue Funktionen sind an den Release-Rhythmus gebunden. |
Genau diese Nachteilsseite erklärt, warum Positionierung nach außen und Struktur dahinter oft bewusst auseinanderfallen müssen, wie der nächste Abschnitt zeigt.
Die Positionierungsfalle: Wenn Baukasten-Vertrieb Vertrauen kostet
Genau hier entsteht ein Missverständnis, das viele Transformationen unnötig riskant macht. Wer intern auf modulare, wiederverwendbare Komponenten umstellt, spart Aufwand: Baukasten, Konfiguratoren, Varianten statt Einzelanfertigung. Das Problem entsteht, wenn diese Effizienz nach außen sichtbar wird, gerade in Märkten, in denen Kunden explizit Anpassungsfähigkeit erwarten.
Ein Vertrieb, der eine Baukastenlösung als „Standardprodukt“ verkauft, wirkt in diesem Kontext wie eine Absage an individuelle Betreuung, selbst wenn die Lösung technisch genauso gut zum Kunden passt wie eine Neuentwicklung. Die Positionierung nach außen darf projektorientiert bleiben, auch wenn die Delivery dahinter längst produktorientiert läuft. Das ist kein Widerspruch, sondern eine bewusste Entkopplung von Vertriebsversprechen und Delivery-Struktur.
Was sich verändert, wenn Organisationen gezielt produktorientierter arbeiten
Der Wechsel ist selten ein Schalter, eher eine Verschiebung von Schwerpunkten, angepasst an die eigene Produkt- und Kundenlandschaft. Die folgenden Veränderungen zeigen sich typischerweise dort, wo Organisationen bewusst einzelne Bereiche in Richtung Produktlogik verschieben.
Roadmaps orientieren sich an strategischen Zielen statt an der Reihenfolge unterschriebener Verträge.
Teams bleiben über mehrere Releases hinweg für ein Produkt verantwortlich, statt bei Projektende neu zusammengesetzt zu werden.
Positionierung nach außen wird konsistenter, weil ein erkennbares Produktportfolio existiert statt einer Sammlung von Einzellösungen.
Skalierung bedeutet zusätzlicher Umsatz pro Team, nicht zwingend zusätzliches Personal pro Kunde.
Teams entscheiden bewusst über kundenspezifische Anforderungen, statt automatisch in Individualentwicklung zu münden.
