Was ist ein Produkt?
Das Konzept der Produktentwicklung ist grundlegend in Agile und wenn Sie in einem Scrum Team arbeiten, wissen Sie sicherlich auch, dass Sie einen Product Backlog und einen Product Owner haben sollten.
Aber was ist eigentlich ein Produkt?
Für einige Teams ist das eine ganz wesentliche Frage. Immerhin können Organisationen keine vernünftigen Product Owner, Teams oder Rollen identifizieren, ohne vorab zu wissen, was ihre Produkte sind. Und wenn es für jedes Produkt einen Product Backlog geben soll, müssen wir wissen, was unsere Produkte sind, bevor wir für jedes einzelne einen Product Backlog erstellen können.
In den meisten Fällen erscheint es ziemlich einfach, die Produkte einer Organisation zu identifizieren. Hersteller für Armbanduhren könnten beispielsweise jeden Artikel, den sie verkaufen, als Produkt ansehen. Allerdings könnte man mit dieser Denkweise die Dinge schon zu sehr vereinfachen und in manchen Organisationen ist die Identifizierung von Produkten nun mal nicht ganz so einfach.
Was sind die Produkte einer Airline?
Nehmen wir eine Airline als Beispiel. Vor einigen Jahren arbeitete ich mit einer Airline zusammen, als dort die Frage aufkam, was eigentlich ein Produkt ist. Einige Leute waren der Ansicht, dass eine Airline nur genau eine Sache mache: Leute von A nach B bringen. Daher argumentierten sie, dass es nur ein einziges Produkt geben solle – selbst bei einer Unternehmensgröße von mehr als 40.000 Mitarbeitern.
Andere meinten jedoch, dass es viele verschiedene Produkte in diesem Unternehmen gäbe. Zum Beispiel gab es eine Webseite, die die Fluggäste nutzen konnten, um Reservierungen zu machen, einzuchecken oder den Status ihres Flugs nachzuschauen. Außerdem gab es ein System für die Überwachung und Terminierung der Flugzeugwartung und ein weiteres, das es den Crew-Mitgliedern erlaubte, je nach Dienstalter die Flüge für ihren Dienst selbst auszuwählen.
Waren das auch alles Produkte?
Definition und Beispiel eines Produkts
Ein Produkt definiere ich als etwas (physisches oder nicht-physisches), das durch einen Prozess entsteht und einem Markt einen Nutzen bringt.
Demnach wäre ein Stuhl ein Produkt. Microsoft Office wäre auch ein Produkt. Eine Beratungsdienstleistung wäre ein Produkt. Ein Gemälde wäre ein Produkt. Ein Produkt kann etwas Greifbares sein (der Stuhl). Es kann ein digitales Produkt sein (Microsoft Office, E-Books oder Videostreams). Es kann aber auch ein Service sein (Beratung bei einer agilen Transition).
Sogar eine Idee kann ein Produkt sein (ein patentierbarer Algorithmus oder das Geheimnis, wie man bei Tinder mehr Leute dazu bekommt, nach rechts zu wischen).
Jedes dieser Beispiele entsteht durch einen Prozess oder ganz grundsätzlich durch eine oder mehrere Aktivitäten. Irgendjemand hat das Holz für den Stuhl zurecht gesägt und den Stuhl zusammengesetzt. Für Microsoft Office wurde ein Desing erstellt, der Code geschrieben und Tests wurden durchgeführt. Der Prozess, durch den ein Produkt entsteht, muss nicht besonders formell oder streng definiert sein. Unter Umständen sind die jeweiligen Personen sich dieses Prozesses gar nicht bewusst. Allerdings ist für jedes Produkt irgendeine Art von Aktivität nötig.
Produkte können rekursiv definiert werden
Auch innerhalb eines Produktes können weitere Produkte existieren. Ein Kugelschreiber kann beispielsweise austauschbare Tintenpatronen haben. Der Kugelschreiber ist ein Produkt. Die Tintenpatronen im Kugelschreiber allerdings auch.
Sogar bei einem Stuhl gibt es Unterprodukte. Der Hersteller und Verkäufer des Stuhls hat vielleicht die fertigen Stuhlbeine von einer anderen Firma bezogen. Die Stuhlbeine wären demnach ein separates Produkt.
Produkte können rekursiv definiert werden. Ein Holzfällunternehmen hat die Bäume gefällt, um Holz zu gewinnen – was schon ein Produkt für sich ist. In einem Sägewerk wurden danach Stuhlbeine aus dem Holz gemacht. Eine weitere Firma hat dann mit diesen vorgefertigten Stuhlbeinen die Stühle nach eigenem Design zusammengebaut. Produkte können also auch innerhalb von anderen Produkten existieren.
Produkte bieten einen Nutzen
Wenn wir innerhalb eines größeren Produkts diverse Unterprodukte identifizieren, müssen wir darauf achten, dass jedes dieser Unterprodukte auch einen Nutzen für den Markt bietet. Die oben genannte Definition besagt nicht, dass etwas gekauft werden muss, um ein Produkt zu sein. Allerdings muss etwas einen Wunsch oder ein Bedürfnis befriedigen, um als Produkt zu gelten.
Sowohl vorgefertigte Stuhlbeine als auch Ersatzpatronen für Kugelschreiber erfüllen dieses Kriterium. Wenn man also Produkte definiert – und somit auch Product Owner und Product Backlogs in Scrum – ist es wichtig, jedes Produkt so zu definieren, dass es einen Nutzen für den Markt bietet.
Anwendung dieser Produktdefinition auf das Airline-Beispiel
Wenn nun Produkte durch einen Prozess entstehen und einen Nutzen für den Markt haben, sind Softwarekomponenten dann Produkte?
Um diese Frage beantworten zu können, schauen wir uns noch einmal das Beispiel der Airline an. Wie kann das Wissen, dass Produkte durch Prozesse entstehen und einen Nutzen für den Markt bieten sollen, einer Airline helfen, Produkte zu identifizieren?
Erst einmal ist es recht leicht zu erkennen, dass es ein Produkt ist, Leute von einem Ort zu einem anderen zu transportieren. Diese Aktivität bietet einem gewissen Markt an Menschen einen Nutzen und sie zahlen gerne für die Möglichkeit, an einen bestimmten Ort fliegen zu können.
Aber was ist mit dem System zur Überwachung und Terminierung der Flugzeugwartung? Ich behaupte, dass auch das ein Produkt ist.
Es entsteht durch einen Prozess und bietet einem gewissen Markt außerdem einen Nutzen. Aber welchem Markt?
Nun ja, man könnte so weit gehen und sagen, dass gut gewartete und sichere Flugzeuge von Nutzen für die Fluggäste sind. Wenn wir den Fokus aber noch etwas mehr auf die Entwicklung des Produkts lenken, können auch die Mitarbeiter der Airline von computerunterstützter Wartung und Terminierung profitieren, da sie das alles nicht mehr manuell auf Papier erledigen müssen.
Das gilt auch für die Webseite der Airline, die es den Fluggästen ermöglicht, Reservierungen vorzunehmen. Auch dafür gibt es einen Markt.
Die Airline hat also ein Hauptprodukt – und viele Unterprodukte. Alles innerhalb dieses Unternehmens, das einen Wert für einen Markt bietet, ist ein Produkt.
Anwendung dieser Produktdefinition auf Softwarekomponenten
Versuchen wir das alles im Hinterkopf zu behalten und es auf Softwarekomponenten zu übertragen. Wenn ein Team Software entwickelt, die von einem anderen Team genutzt wird, kann man das dann als ein Produkt bezeichnen? Stellen Sie sich vor, dass ein Team ein Kalender-Widget entwickelt. Es bietet einen Nutzen für einen bestimmten Markt: den anderen Teams, die dieses Widget nutzen werden. Auch in diesem Fall würde ich behaupten, dass eine Komponente für andere Teams ein Produkt ist.
Bei solchen Widgets (oder anderen Komponenten), die nur von einem Team genutzt werden, würde ich allerdings eine Grenze ziehen. Natürlich kann ein Markt auch nur mit einem einzigen Kunden existieren. Ein Gemälde, beispielsweise, wird nur an eine Person verkauft.
Wenn man jedoch über die Produktentwicklung spricht (wie etwa in Agile), kann es recht gefährlich sein, etwas als Produkt zu bezeichnen, das nur von einer Person oder einer Gruppe genutzt wird. Das könnte nämlich dazu führen, dass man Code als Produkt ansieht, weil er an einen Markt von Testern geliefert wird. Das ist nicht nur ein Schritt zurück in eine sequenzielle Entwicklung, es ist auch eine Form von Suboptimierung.
Die Suboptimierung von Produkten vermeiden
Laut dem Wirtschaftsprofessor Thayer Watkins von der San Jose State University bedeutet Suboptimierung, „sich auf eine Komponente eines Ganzen zu fokussieren, diese durch Veränderungen verbessern zu wollen…und dabei die Auswirkungen auf die anderen Komponenten zu ignorieren”.
Auch wenn Organisationen immer versuchen sollten, alle ihre Produkte zu definieren, um ihre Arbeit auf bestmögliche Weise managen zu können, sollten sie sich jedoch nicht so sehr auf die einzelnen kleinen Dinge fixieren, sodass sie das große Ganze nicht mehr erkennen können. Aus diesem Grund sollten Organisationen ihre einzelnen Produkte so breit wie möglich definieren.
Wie wir zuvor bei der Airline gesehen haben, kann es aber auch so etwas wie eine zu breite Definition eines Produkts geben. Wenn ein Produkt so umfangreich ist, dass es mehrere Märkte bedient, sehe ich das lieber als mehrere kleine Produkte für die jeweiligen individuellen Märkte an.
Zum Beispiel wäre es recht einfach, Microsoft Office als ein einziges Produkt anzusehen. Allerdings besteht Office aus einer Reihe von Produkten, die alle verschiedene Features bieten und leicht unterschiedliche (und sich überschneidende) Märkte bedienen.
Daher sehe ich Word, Excel, PowerPoint usw. jeweils als einzelne Produkte an. Jedes dieser Produkte sollte demnach auch seinen eigenen Product Owner und Product Backlog haben. Alleine der Spell Checker, also die automatische Rechtschreibekorrektur, könnte ein Produkt sein, denn diese Funktion bietet einen Nutzen für einen Markt (den anderen Teams, die dann nicht selbst einen Spell Checker entwickeln müssen).
Jedoch würde ich beispielsweise Funktionen wie das Errechnen einer Summe oder eines Durchschnittswerts bzw. die Zählfunktion usw. nicht als Produkte definieren. Sie sind einzigartig für Excel und dienen damit nur einem einzigen Kunden. Es wäre einfach zu riskant, jedem dieser Dinge einen eigenen Product Owner und Product Backlog außerhalb der Welt von Excel zu geben.Suboptimales Denken bei der Arbeit mit verschiedenen Produkten zu reduzieren, schafft man nicht nur, indem man Produkte für nur einen einzigen Kunden vermeidet, sondern auch indem man einen Chief Product Owner ernennt. Der Chief Product Owner ist eine strategische Rolle und verantwortlich dafür, eine Vision zu schaffen, die alle Unterprodukte beinhaltet. Bei Microsoft Office würde der Chief Product Owner überlegen, wie die einzelnen Produkte die Suite als Ganzes beeinflussen.
Produktentwicklung als Product Owner lernen
Wenn du tiefer in die Produktentwicklung einsteigen willst, dann schau dir unsere CSPO Trainings an. Die zwei bis drei Tages Trainings zeigen dir, worauf du als Product Owner bei deinem Produkt achten musst und wie du ein hervorragender PO werden kannst. Wenn du neu in der Rolle bist, kannst du dich zum Certified Scrum Product Owner von unseren Trainern ausbilden lassen. Solltest du schon eine Zertifizierung als CSPO haben, stehen dir die Fortgeschrittenen Trainings als Advanced Certified Scrum Product Owner oder sogar als Certified Scrum Trainer - Product Owner offen. Welche Voraussetzungen du hierfür erfüllen musst, siehst du bei den jeweiligen Trainings.