Software Product Management: Produkte bauen, die tragen

Die teuersten Entscheidungen im Software Product Management fallen, bevor die erste Zeile Code existiert. Trotzdem starten die meisten Teams am anderen Ende: Backlog aufsetzen, Tickets schreiben, Sprint planen. Gebaut wird ab Tag eins, entschieden irgendwann später, wenn überhaupt. Das Ritual wirkt professionell und läuft trotzdem verkehrt herum.

Das Backlog fühlt sich nach Fortschritt an: jede Woche neue Tickets, jede Woche etwas ausgeliefert. Die Roadmap füllt sich, bevor die Richtung steht. Nur ist Geschwindigkeit ohne Richtung keine Tugend, das Team liefert bloss schneller am Kunden vorbei. Und die Lage spitzt sich zu: KI hat das Bauen billig gemacht. Code entsteht in Stunden statt Wochen. Damit verschiebt sich der Engpass dorthin, wo er immer schon hingehörte: zur Entscheidung, was gebaut wird und was nicht.

Diese Seite ordnet genau diese Entscheidungen, von der Positionierung über den Umfang bis zur Organisation, und sammelt alle Artikel zur Produkt-Seite. Geschrieben für Produktverantwortliche, Gründer und Führungsleute in B2B-Software-Firmen, die entscheiden müssen, wohin die knappe Bauzeit fliesst.

Ich arbeite an der Schnittstelle von Product, GTM und AI. GTM steht für Go-to-Market, also den Weg deines Produkts zum Kunden. Gerade baue ich Teklens mit auf, eine Software, die in Produktteams mitarbeitet. Die Fragen auf dieser Seite sind für mich deshalb nicht Theorie, sondern Wochenalltag: was bauen, was streichen, woran messen.

Was du hier mitnimmst

• Die drei Fragen, die jede Produktentscheidung tragen: für wen, welches Problem, woran gemessen.
• Warum Positionierung vor dem Code kommt und wie du sie in einem Satz testest.
• Wie schmal eine erste Version sein darf und was in den ersten 90 Tagen bewusst nicht gebaut wird.
• Woran du Product-Market-Fit messbar erkennst und was KI-Agenten am Produktbau ändern.

Gute Produkte entstehen aus klaren Entscheidungen, nicht aus mehr Features

Software Product Management heisst: entscheiden, was gebaut wird, für wen und warum, und dafür sorgen, dass diese Entscheidungen im Alltag halten. Das ist die ganze These dieser Seite. Nicht mehr Funktionen, nicht mehr Prozess, nicht das nächste Framework, sondern klare Entscheidungen, die den ersten lauten Kundenwunsch überleben. Der Rest dieser Seite ist der Beleg dafür, Entscheidung für Entscheidung, bis zu einer messbaren Ziellinie.

Was macht gutes Software Product Management aus?

Klare Antworten auf drei Fragen: Für wen bauen wir? Welches Problem lösen wir? Woran messen wir Erfolg? Wer diese drei Fragen nicht in je einem Satz beantworten kann, baut auf Verdacht.

Die dritte Frage ist die unbequemste. Erfolg heisst nicht Downloads oder gelieferte Funktionen, sondern zum Beispiel: Kunden nutzen das Produkt jede Woche und verlängern den Vertrag. Erst ein messbares Kriterium macht aus einer Produktidee eine überprüfbare Wette.

Gutes Produktmanagement sagt ausserdem öfter Nein als Ja. Jede Funktion kostet dreifach: beim Bauen, beim Warten und beim Erklären. Die wichtigste Fähigkeit ist deshalb nicht das Priorisieren von Ideen, sondern das Streichen. Und die Antworten müssen den Alltag überleben: Eine Strategie, die beim ersten lauten Kundenwunsch kippt, war keine. Die drei Antworten gehören auf eine Seite, sichtbar fürs ganze Team, nicht in ein Strategiedokument, das niemand öffnet. Jede neue Funktionsidee muss sich an diesen Sätzen messen lassen, sonst entscheidet am Ende die Lautstärke.

Warum beginnt das Produkt vor dem Code?

Die wichtigsten Produktentscheidungen fallen, bevor die erste Zeile geschrieben ist. Wer ist der Kunde, was ist das Problem, warum sind wir die richtige Antwort? Das ist Positionierungsarbeit, beschrieben im Guide zur Produktpositionierung im B2B.

Positionierung heisst: Kunden verstehen sofort, warum dein Produkt für sie das richtige ist. Fehlt sie, rächt sich das doppelt. Das Team baut Funktionen für alle und niemanden, und der Vertrieb erklärt jedem Interessenten ein anderes Produkt. Gerade technisch starke Firmen im DACH-Raum unterschätzen diese Arbeit gern, weil sie sich nicht wie Arbeit anfühlt. Ein einfacher Test: Erklär dein Produkt in einem Satz, ohne den Firmennamen. Passt der Satz auf zehn andere Anbieter, hast du keine Positionierung, sondern eine Beschreibung.

Und weil ein Produkt nur lebt, wenn es den Markt erreicht, gehört das Duo aus Bauen und Vermarkten zusammen, wie im Artikel über Produktmarketing und Produktmanagement. Das eine Team baut das Produkt, das andere bringt es zu den Kunden. Wie gut die beiden zusammenspielen, entscheidet über dein Wachstum.

Wie schmal darf die erste Version sein?

Schmaler, als sich die meisten trauen. Der häufigste Produktfehler ist Grössenwahn im Umfang. Meine Gegenposition: ein SaaS-Produkt in 90 Tagen, schmal, ehrlich, ausgeliefert. Nicht alles, was du dir wünschst, aber das, wofür Kunden zahlen.

Genauso wichtig ist die Liste dessen, was in den ersten 90 Tagen nicht gebaut wird: kein Rollen- und Rechtesystem, keine Integrationen für hypothetische Grosskunden, kein Admin-Dashboard, keine Mehrsprachigkeit. Alles davon kann später kommen, wenn ein zahlender Kunde es verlangt. Bis dahin ist es totes Kapital, das du pflegen musst. Der Effekt der Schmalheit ist doppelt: Du lieferst früher, und du lernst früher. Ein Kunde, der eine schmale Version wirklich nutzt, sagt dir mehr über dein Produkt als zehn Workshops über eine grosse.

Dazu gehört auch die ehrliche Frage, ob du überhaupt ein Produktgeschäft willst, oder eine Agentur, siehe Service-Agentur versus Software-Produkt. Diese Grundsatzentscheidung gehört ins Kapitel Entrepreneurship, denn sie prägt alles, was danach kommt.

Brauchst du ein Framework wie das Spotify-Modell?

Fast sicher nicht. Kopierte Organisationsmodelle scheitern, weil ihnen der Kontext fehlt, in dem sie entstanden sind: die Firmengrösse, die Kultur, die Probleme jener Zeit. Warum das berühmte Modell mit Squads und Tribes, also kleinen autonomen Teams und Gruppen solcher Teams, bei dir nicht funktioniert, steht in Das Spotify-Modell funktioniert bei dir nicht.

Und mit kleinen Teams plus KI-Helfern brauchst du es auch nicht. Die Koordinationsprobleme, die solche Frameworks lösen sollen, entstehen erst mit vielen parallelen Teams. Bleib darunter, solange es irgendwie geht. Ein kleines Team mit klaren Verantwortungen schlägt die nachgebaute Struktur eines Konzerns.

Software Product Management in der Praxis: erste Schritte und typische Fehler

So startest du, ohne dich zu verzetteln:

• Beantworte die drei Fragen schriftlich: für wen, welches Problem, woran gemessen.
• Formuliere die Positionierung in einem Satz, bevor du Funktionen planst.
• Streiche die erste Version auf das zusammen, wofür ein Kunde heute zahlt.
• Definiere die Ziellinie messbar, zum Beispiel mit den drei Zehnern von Hendrikse, dazu gleich mehr.
• Lerne die technischen Grundbegriffe. Du musst nicht programmieren können, aber die Grundbegriffe solltest du einordnen können. Cloud-Native, IaaS, PaaS und SaaS erklärt die Cloud-Welt in Klartext.

Die typischen Fehler sind die Umkehrungen: bauen ohne Positionierung, weil Bauen sich produktiver anfühlt als Nachdenken. Die Roadmap nach dem lautesten Kunden richten statt nach dem Zielkundenprofil. Organisationsmodelle kopieren, statt das eigentliche Problem zu lösen. Und Product-Market-Fit fühlen statt messen, bis das Geld ausgeht. Dazu kommt ein leiser Fehler: die technische Grundlage ignorieren, bis sie sich von selbst meldet. Wer die Grundbegriffe einordnen kann, versteht, was das eigene Team bremst und was es trägt.

Die messbare Ziellinie: Product-Market-Fit, und was KI daran ändert

Zum Schluss die zwei schwersten Argumente: eine Ziellinie, die du messen kannst, und eine Verschiebung, die gerade jede Produktorganisation trifft.

Woran erkennst du Product-Market-Fit?

An Zahlen, nicht am Gefühl. Product-Market-Fit heisst: Dein Produkt löst ein Problem so gut, dass Kunden zahlen und bleiben. Stijn Hendrikse macht diese Ziellinie in T2D3 messbar: Product-Market-Fit ist erreicht, wenn unter anderem 10 zahlende Kunden, 10 öffentliche Referenzen und 10 Neukunden über Weiterempfehlung stehen.

Das Gefühl täuscht nämlich systematisch. Interessenten sind höflich, Pilotkunden loben unverbindlich, und ein voller Terminkalender fühlt sich an wie Nachfrage. Die drei Zehner von Hendrikse sind unbestechlich: Bezahlt, öffentlich empfohlen, weiterempfohlen. Erst wenn Fremde dein Produkt aus eigenem Antrieb weitertragen, trägt es. Hendrikse schreibt aus dem US-SaaS-Kontext mit Investoren im Rücken. Seine Checkliste funktioniert trotzdem für jede Kapitalstruktur, weil sie nur zählt, was Kunden freiwillig tun: zahlen, empfehlen, öffentlich hinstehen.

Dahinter steht bei Hendrikse ein Reifemodell mit fester Reihenfolge, wie Bases im Baseball: erst die erste verkaufbare Produktversion, dann Product-Market-Fit, erst danach Skalierung. Keine Base lässt sich überspringen. Wer es trotzdem versucht, geht später zurück und repariert. Für dein Produktmanagement heisst das: Vor der Ziellinie zählt Lernen, nicht Ausbau.

Was ändert KI am Software Product Management?

Code ist billig geworden, Entscheidungen und Kontext sind teuer geworden. Die Arbeitsweise selbst verändert sich gerade grundlegend: KI-Helfer schreiben Code und arbeiten im Team mit, wenn man sie führt. Das Produktmanagement wird dadurch wichtiger, nicht unwichtiger.

Was das konkret heisst, zeigen From Vibe Coding to Agentic Engineering und Agentic Product Engineering: früher 30, heute 3. Drauflos-Programmieren mit KI hat einen Kater hinterlassen: unsicherer Code, langsamere Teams. Jetzt zählt, wer die Helfer führt, statt ihnen blind zu vertrauen. Und Arbeit, für die früher eine ganze Produktorganisation nötig war, erledigt heute ein kleines Team mit Agenten.

Führen heisst hier: Kontext liefern. Eine Aufgabe ist erst dann gut beschrieben, wenn Mensch und KI-Helfer sie ohne Rückfrage ausführen können. Wie so ein Arbeitsauftrag aussieht, zeigt die Anatomie eines GTM-Tickets. Kleine Teams plus Agenten ersetzen so die Squad-Strukturen von gestern. Für die Teamplanung heisst das: Statt Organisationsmodelle zu kopieren, beschreibe Arbeit so, dass sie delegierbar wird, an Menschen wie an Agenten. Das ist die neue Kernkompetenz im Produktmanagement. Mehr zum Zusammenspiel von Automatisierung und Produktarbeit findest du im Hub B2B Automation und AI.

Entscheiden statt stapeln: was bleibt

✅ Was glänzt: Die drei Fragen kosten nichts und wirken sofort. Ein Team, das für wen, welches Problem und woran gemessen in je einem Satz beantworten kann, trifft ab morgen bessere Entscheidungen, ganz ohne neues Werkzeug.

❌ Was nicht glänzt: Klare Entscheidungen fühlen sich langsamer an als Bauen. Streichen produziert keine Demo, und ein Nein sieht im Sprint-Review nach nichts aus. Diesen Rhythmus hältst du nur durch, wenn die Führung ihn deckt.

⚠️ Warnung: Die grösste Falle ist billiger Code. Weil KI das Bauen fast gratis macht, wächst der Umfang schneller, als ihn jemand hinterfragt. Wer heute ohne Positionierung baut, macht den alten Fehler in Maschinengeschwindigkeit.

Damit schliesst sich der Kreis zum Anfang: Die teuersten Entscheidungen fallen weiterhin vor der ersten Zeile Code, nur folgt heute auf jede Entscheidung mehr Code als je zuvor. Das Backlog war noch nie der richtige Startpunkt, jetzt ist es nicht einmal mehr der Engpass. Wenn du solche Notizen regelmässig lesen willst, abonniere meinen Newsletter.

Alle Artikel zur Produkt-Seite findest du unten, jeweils einfach beschrieben.