Viele Organisationen und Unternehmen behaupten, agile Produktenwicklung zu betreiben. Aber die meisten von ihnen straucheln dabei. Der Grund liegt häufig darin, dass sie aus dem klassischen Projekt-Geschäft kommen und nicht verstanden haben, dass Produkte andere Anforderungen haben als Projekte.
In diesem Artikel zeige ich Dir anhand des Business Model Canvas, worin die genauen Ursachen für die Probleme liegen. Und welche Konsequenzen es hat, wenn es Dir nicht gelingt, Deine Projekte sauber von Deiner Produkt-Entwicklung zu trennen.
Der Unterschied zwischen Produkt und Projekt
Im Grunde genommen ist der Unterschied zwischen Produkt und Projekt ziemlich einfach.
Projekte stiften für sich betrachtet keinen Nutzen oder Wert für Deinen Kunden. Sie sind lediglich ein Vehikel, mit dessen Hilfe Du Dein Produkt zum Kunden bringst. Natürlich kann es (zwingend) notwendig sein, Projekte durchzuführen, damit Dein Kunde Dein Produkt nutzen kann. Aber noch einmal, weil es so wichtig ist:
Ein Projekt stiftet keinen Nutzen oder Wert. Der Nutzen entsteht nach dem Projekt, wenn Dein Kunde Dein Produkt verwendet.
Produktentwicklung auf dem Business Model Canvas
Dieser grundsätzliche Unterschied zwischen Projekt und Produkt lässt sich anschaulich mit Hilfe des Business Model Canvas abbilden. Während Dein Produkt die Value Proposition darstellt, gehört das Projekt in das Element Channels.
Projektmanagement auf dem Business Model Canvas
Viele Software-Firmen denken (historisch bedingt) in Projekten. Innerhalb eines Projektes wurde (und wird) für einen spezifischen Kunden ein (mehr oder weniger) individuelles Endergebnis erstellt. Dieses Endergebnis ist kein Produkt im eigentlichen Sinne. Es ist eine Individual-Anfertigung für einen Kunden. (Während ein Produkt Nutzen und Wert für das gesamte Kundensegment erzeugen soll und nicht nur für einen einzelnen Projekt-Kunden.)
In diesem Geschäftsmodell ist das Projekt (als Dienstleistung) die eigentliche Value Proposition. Denn für sie bezahlt der Kunde Geld.
Gleichzeitig wird Dein Produkt zur Key Resource. Ob Dein Produkt gut oder schlecht ist, wird hauptsächlich daran bemessen, wie hilfreich es ist, Deine Projekte effizient umzusetzen. Denn darauf basiert Dein gesamtes Geschäftsmodell. Keine Projekte, keine Umsätze.
Auf dem Business Model Canvas lässt sich das Ganze folgendermaßen darstellen:
Gedankenexperiment
Stell Dir vor, Du würdest ein physisches Produkt herstellen. Wenn ein Kunde Dein Produkt erwirbt, lieferst Du es jedoch nicht per DHL zu Deinem Kunden. Stattdessen hast Du eine umfangreiche, hauseigene Lieferflotte aufgebaut und lieferst Dein Produkt eigenständig an Deine Kunden aus. Kurioserweise verdienst Du mit Deinem Produkt auch wenig bis gar nichts. Dein Geschäftsmodell basiert darauf, dass Du von Deinen Kunden hohe Portogebühren für die exklusive Lieferung erhebst.
Relevant ist das Paket und nicht der Inhalt
Damit Dein Geschäftsmodell funktioniert, ist es natürlich wichtig, dass die Produkt-Pakete möglichst gut und platzsparend in Deine Transporter passen. Darüber hinaus sollten sie auch so leicht wie möglich sein. Je besser die Produkt-Pakete diese Anforderungen Deiner Lieferflotte erfüllen, desto effizienter ist Dein Lieferdienst.
Was nach einer Zustellung passiert, ist dadurch eher zweitrangig, da Deine Transporter schon wieder auf dem Weg zum nächsten Kunden sind. Oder überspitzt formuliert: Solange noch genügend Produkte gekauft werden, ist es absolut zweitrangig, was Dein Produkt kann oder bewirkt. Solange die Pakete, in denen sich Dein Produkt befindet, möglichst perfekt für die Auslieferung sind, ist alles in bester Ordnung. Grundsätzlich könnte der Karton sogar leer sein, da Du Dein Geld ja durch das Porto für die Auslieferung verdienst und nicht mit dem Inhalt des Pakets.
Genau das Gleiche passiert mit Deinem Produkt, wenn Deine Value Proposition das Projektgeschäft ist. Projekte geben den Takt vor, da sie maßgeblich für das Geschäftsmodell Deiner Firma sind. Das Produkt ist zwar noch eine relevante Key Resource. Aber der Wert, den es nach der Auslieferung (also nach dem Projekt) stiftet, ist nicht wirklich relevant.
Gretchenfrage
Um festzustellen, wie stark Dein Unternehmen noch im Projekt-Denken verhaftet ist, existiert ein recht einfacher Test.
Stell Dir vor, Dein Product Owner hat eine revolutionäre Möglichkeit gefunden, sein Produkt zu allen Kunden des Marktes auszuliefern, ohne dass ein einziges Projekt notwendig wäre.
Dabei geht es auch gar nicht unbedingt darum, wie realistisch diese Möglichkeit ist. Aber gesetzt den Fall, sie wäre es: Würde Dein Unternehmen diese Idee verfolgen? Wenn Deine Antwort „Nein“ ist, dann betrachtet sich Dein Unternehmen noch als Dienstleister für Projekte und Euer „Produkt“ lediglich als wichtige Key Resource, um eben möglichst gut, schnell, effizient etc. Projekte umzusetzen.
Verschiebungen im Customer Segment & Stakeholdern
Falls Dein Unternehmen keine echte Produktentwicklung betreibt, kommt es bei Stakeholdern und im Customer Segment zu weiteren Verschiebungen. Projekt-Management fokussiert sich naturgemäß auf einen einzelnen Kunden. Selbst wenn es sich um einen Kunden des anvisierten Customer Segments handelt, steht das Projektgeschäft unter vollkommen anderen Vorzeichen.
Im Vordergrund des Projekt-Managements stehen spezifische Anforderungen eines konkreten Einzelkunden, die nur selten mit den Bedarfen des Deines Customer Segments übereinstimmen. Garniert wird das Ganze mit Deadlines, zu denen das Projekt umgesetzt sein soll. Und Dein Produkt, das nun lediglich eine Key Resource für die Umsetzung von Projekten ist, muss diesen terminierten Anforderungen genügen.
Abgeschnitten vom Customer Segment
Als Produkt Owner bist Du damit vom Customer Segment abgeschnitten. Denn Du musst Dein Product Backlog so priorisieren, dass die nächsten Projekte reibungslos umgesetzt werden können. Je besser das Projekt-Geschäft läuft, desto länger und unflexibler wird auch Dein Produkt-Backlog.
Projekt-Manager (die zuvor Stakeholder waren) werden nun zu Deinen neuen Kunden. Weil sie Dir als Product Owner vorgeben, welche Features als nächstes für ein Projekt benötigt werden. Du bist weder in der Lage, neuen Nutzen für Bestandskunden zu generieren, noch neue Funktionen für Dein Produkt zu entwickeln, die dabei helfen könnten, Neukunden zu gewinnen.
Produktuntaugliche Features durch Projekte
Durch den Zeitdruck während eines Projektes werden Funktionen kundenspezifisch umgesetzt. Sie werden also meistens so programmiert, dass sie den Anforderungen des Projekt-Kunden entsprechen. Für eine produkttaugliche Umsetzung ist in der Regel gar keine Zeit. Das Resultat ist die Anhäufung von technischer Schuld. Statt ein produkttaugliches Feature zu entwickeln, werden Dutzende kundenspezifische Einzellösungen entwickelt. Später ist es dann extrem schwierig, diese wieder herauszulösen und durch ein neues Feature zu ersetzen. (Mal abgesehen davon, dass die Zeit ohnehin nicht zur Verfügung steht, weil ja schon das nächste Projekt ansteht.)
Finde Wege, Produkt und Projekt klar voneinander zu trennen
Wenn Du ernsthaft Produktentwicklung betreiben möchtest, musst Du Projekte als das betrachten, was sie wirklich sind: Ein Element, mit dessen Hilfe Du Dein Produkt zum Kunden bringen kannst (aber nicht musst). Ich hoffe, ich konnte Dir mit meinem Artikel ein verdeutlichen, welche Probleme entstehen, wenn Du Projekt-Management und Produktentwicklung miteinander verbindest.
