From project to product mode: ein Praxisbuch für die echte Transformation

Das sind IT- und Produktabteilungen in Unternehmen, die für die Generierung neuer Ideen, das Ausprobieren neuer Technologien, die Einführung neuer Arbeitsprozesse und allgemein für Innovation stehen.

Das Problem ist nur, dass dies auch bei diesen Abteilungen bleibt. Während IT-Systeme iterativ in die Cloud ziehen und Produktteams Design Sprints durchführen, verkaufen Vertriebsteams hochindividuelle Systeme statt Standards, und das Controlling taucht regelmäßig mit der Keule auf, weil die Story Points in die Personentage umgerechnet nicht mit der Anzahl ursprünglich geplanter Wochen übereinstimmen.

Das Unternehmen als … Ei

Diese Kluft zwischen IT/ Produkt und dem „Rest“ beschreiben Sebastian und Thomas in ihrem Buch „From Project to Product Mode. A Gameplan to Unlock Scalability for B2B Software Products“ treffend mit einer Metapher: sie vergleichen solche Unternehmen mit einem Ei. Das Eigelb vom Ei, also das Wesentliche, besteht aus IT und Produkt, die was täglich Neues entwickeln. Umgeben sind sie von Abteilungen, die weiterhin im Projekt-Modus funktionieren.

Zwei Produktwelten – Legacy und Zukunft

Die Autoren konzentrieren sich auf B2B-Produktentwicklung und decken dabei lässt sich hier eine Vielfalt von Geschäftsmodellen ab: Unternehmen, die ihr Produkt gerade gelauncht haben, und alles tun, um Kunden zu gewinnen; sowie Unternehmen, die seit Jahren am Markt existieren und zwischen zwei Welten pendeln müssen: einerseits das Legacy-Produkt, das vor Jahren live ging und noch immer Umsätze generiert, aber kundenindividuell entwickelt wurde; anderseits die neue Welt, die erkannt hat, dass solche Produkte weder weiterentwickelbar noch skalierbar sind.

Sieben Herausforderungen auf dem Weg zum Produktmodus

Die Autoren identifizierten sieben Challenges, die für den Übergang zum Produktmodus überwunden werden müssen. Diese Challenges dienen als Filter. Jeder Filter kann Entscheidungen zwischen Produkt- oder Projektorganisation unterstützen.

Produktmodus ist kein Allheilmittel – aber oft die bessere Wahl

Besonders relevant: Produktorganisation ist kein Selbstzweck. Der Projektmodus kann auch eine strategische Entscheidung sein. Ein Produktmodus ermöglicht jedoch bessere Skalierbarkeit und langfristige Profitabilität.

Wenn Prioritäten sich ständig ändern, die Produktroadmap nicht mehr alle Kundenbedürfnisse abdeckt, verschiedene Produktversionen im Umlauf sind und Aufwandsschätzungen unmöglich sind, deutet dies auf ein “gebrochenes” System hin, das eine strategische Neuausrichtung erfordert.

Was braucht es für die Transformation?

1. Segmentierung statt Maßanfertigung

“Sales sells the dream; you inherit the delivery”: Konzentration auf eine homogene Kundengruppe – Segmentierung des bestehenden Kundenstamms, Entwicklung eines Ideal Customer Profiles (ICP), das bei minimalem oder ohne Projektaufwand maximale Umsätze generiert (”scale through standardization”). Die Zusammenarbeit mit Vertriebt birgt Konfliktpotenzial: komplexe Projekte bedeutet höhere Rechnungen und somit höhere Sales-Incentives. Unternehmensweit sollte die Incentivierung daher auf Projekte mit geringerem Aufwand, einfacherem Setup und niedrigerem Risiko ausgerichtet werden.

2. Wertbasierte Preismodelle etablieren

Statt Kosten + Marge sollte im Produktmodus der Wert des Produktes den Preis bestimmen, z. B. anhand der Anzahl von Nutzern oder freigeschalteten Funktionalitäten.

3. Discovery als strategischer Filter

Product Discovery ermittelt die entscheidenden Funktionen und ist der wichtigste Filter für das Unternehmen. Grundprinzipien sind regelmäßiger Austausch mit (potenziellen) Kunden und Fokussierung auf Kernfeatures. Diese Frage hilft, um festzulegen, was gebaut werden sollte: Was passiert, wenn wir das nicht bauen?..

4. Priorisierung nach Kundenwert

Priorisierung wird einfach, wenn Zielkunde, Preismodell und Kernfeatures klar sind: zuerst sollten kritische Probleme der umsatzstärksten Kunden gelöst werden. Ist die Priorisierung ein Kampf zwischen Abteilungen und dem Tagesgeschäft, sollten zuerst die obigen Herausforderungen bewältigt werden.

5. Autonome Teams statt Flaschenhälse

Notwendig sind selbstständige, cross-funktionale Teams mit klarer Mission. Sie sollten befähigt sein, Kundenprobleme innerhalb ihrer Domäne, also eines klaren fachlichen Rahmens, lösen zu können und kontinuierlich lernen und sich weiterzuentwickeln.

6. Pull-Prinzip statt Feature-Factory

Die Erwartung eines klassischen Projektmanagers, dass ein Entwickler-Team Features liefert, die ein Kunde in den Backlog mittels eines Product Owners reingeschrieben hat. Im Produktmodus darf alles hinterfragt werden: ein Produktteam abreitet nicht eine Wunschliste ab, sondern liefert Features, die einen Mehrwert bringen.

7. Konfiguration mit Augenmaß

Jeder Kunde hat individuelle Anforderungen. Dennoch ist eine Balance zwischen Individualisierung und Standardisierung entscheidend. Unvermeidbare Kundenanpassungen müssen ein kostendeckendes Preisschild erhalten.

Produktteams allein reichen nicht

Aus meiner Berufserfahrung weiß ich: diese Transformation kann nicht vom Produktteam allein bewältigt werden. Produktmanager und Software-Entwickler werden oft entmündigt und als „Lieferanten“ behandelt, die durch Projektmanager gesteuert werden. Auch Produktverantwortliche (Heads of Product/Innovation/etc.) haben meist keine ausreichende Einflussnahme auf unternehmensweite Prozesse. Der Wandel erfordert eine Beteiligung des gesamten Unternehmens oder wie Marty Cagan betont: „Technologie muss als Geschäftskern verstanden werden.“

Dicht, praxisnah – aber ohne Fallbeispiele

Das Buch von Sebastian Borggrewe und Thomas Hartmann bietet praktische Handlungsempfehlungen für diesen Wandel. Die Autoren betonen zu Recht: es gibt keine “one fits all”-Strategie, aber durchaus Sachen, die ein Produktteam machen kann, um diese Transformation in die Wege zu leiten.

Und noch was…

Das Buch hat etwas mehr als hundert Seiten, aber zumindest in meinem Fall konnten die Autoren ihr Versprechen nicht einhalten, das Buch innerhalb von einer-zwei Stunden des fokussierten Lesens abschließen zu können (auf dem Bild sieht man sehr schön: ich wollte es während eines Freibadbesuchs auslesen (-: ).

Trotz der Kürze von gut 100 Seiten ist das Buch so dicht gepackt mit Ideen, dass ich immer wieder Pausen einlegen musste: es sind zu viele Impulse zum Nachdenken und Querdenken auffordern. Hier fehlen auch Beispiele oder Interviews, die für die Bücher über die Produktentwicklung üblich sind. Natürlich ist die Nennung von B2B-Unternehmen schwierig, aber künftige Auflagen könnten eventuell fiktive Fallstudien integrieren, um Konzepte noch anschaulicher zu machen.

Pflichtlektüre für alle mit echter Produktverantwortung

Und dennoch: Wer in einem B2B-Umfeld echte Produktverantwortung übernehmen will, sollte dieses Buch gelesen haben und idealerweise auch die anderen darüber erzählen.