Außerdem kann diese Definition auch Offline-Erfahrungen umfassen, die entscheidend für die Wertvermittlung des Produkts sind.
Ist Ihr Produkt beispielsweise eine E-Commerce-Seite, dann würden dazu Merchandise Fulfillment und Warenrückgabe gehören. Im Allgemeinen gehört beim E-Commerce alles zum Produkt mit Ausnahme des tatsächlich verkauften Artikels.
In ähnlicher Weise bezeichnen wir bei einem Medienunternehmen alles mit Ausnahme der Inhalte als Produkt.
Entscheidend ist eine sehr umfängliche und ganzheitliche Definition des Begriffs. Ihr Ziel ist nicht nur die Umsetzung von Leistungsmerkmalen.
Continuous Discovery und Delivery
Weiter oben habe ich erläutert, dass die meisten Unternehmen immer noch einen Prozess verfolgen, der im Kern dem Wasserfallmodell entspricht, und ich habe gesagt, dass in einem modernen Team deutlich anders vorgegangen wird.
Wir werden uns später noch intensiver mit dem Prozess der Produktentwicklung beschäftigen. An dieser Stelle ist es jedoch notwendig, ein übergeordnetes Prozesskonzept vorzustellen, das aus zwei grundlegenden übergeordneten Aktivitäten in allen Produktteams besteht. Wir müssen das zu erstellende Produkt entdecken und wir müssen dieses Produkt an den Markt liefern.
Discovery und Delivery sind unsere beiden Hauptaktivitäten in einem crossfunktionalen Produktteam und sie verlaufen beide typischerweise fortlaufend und parallel.
Es gibt verschiedene Möglichkeiten, darüber nachzudenken und das zu visualisieren, aber das Konzept ist recht simpel: Wir arbeiten immer parallel daran, das notwendige zu erstellende Produkt zu entdecken – worin die tägliche Hauptaufgabe des Product Managers und des Designers besteht –, während die Programmierer daran arbeiten, ein Qualitätsprodukt bereitzustellen.
Wir müssen das zu erstellende Produkt entdecken und wir müssen dieses Produkt an den Markt liefern.
Wie Sie bald sehen werden, gehören dazu noch ein paar andere Dinge. Zum Beispiel helfen die Programmierer auch bei der täglichen Discovery (viele der besten Innovationen entstehen durch diese wichtige Mitwirkung) und der Product Manager und der Designer helfen ebenfalls tagtäglich bei der Delivery (in erster Linie, um die beabsichtigte Funktionalität zu sichern). Aber das ist es, was auf übergeordneter Ebene stattfindet.
Abbildung 8.1: Continuous Discovery und Delivery
Product Discovery
Discovery hat viel zu tun mit der intensiven Zusammenarbeit von Product Management, User Experience Design und Engineering. Im Rahmen der Discovery berücksichtigen wir die verschiedenen Risiken, ehe wir auch nur eine Zeile Produktionssoftware schreiben.
Bei der Product Discovery geht es darum, rasch die guten von den schlechten Ideen zu unterscheiden, um am Ende ein validiertes Product Backlog zu bekommen.
Das bedeutet insbesondere, Antworten auf vier entscheidende Fragen zu finden:
1 Wird der Anwender das Produkt kaufen (oder sich zur Verwendung entschließen)?
2 Kann der Anwender herausfinden, wie man es benutzt?
3 Können unsere Programmierer es erstellen?
4 Können unsere Stakeholder es unterstützen?
Prototyping
Zur Product Discovery gehört eine Reihe sehr rascher Experimente, und um diese Experimente schnell und preisgünstig durchzuführen, verwenden wir eher Prototypen als Produkte. Es gibt verschiedene Arten von Prototypen, jeweils für unterschiedliche Risiken und Situationen, aber sie alle erfordern in jedem Fall deutlich weniger Zeit und Mühen als die Herstellung eines Produkts.
Damit Sie sich eine Vorstellung machen können: Starke Teams testen normalerweise viele Produktideen pro Woche – in der Größenordnung von zehn bis zwanzig oder mehr.
Damit Sie sich eine Vorstellung machen können: Starke Teams testen normalerweise viele Produktideen pro Woche – in der Größenordnung von zehn bis zwanzig oder mehr.
Ich möchte betonen, dass es sich dabei um Experimente handelt, die für gewöhnlich anhand von Prototypen durchgeführt werden. Ein Prototyp ist noch nicht bereit für den großen Auftritt und ganz sicher nichts, das Ihr Unternehmen guten Gewissens zu verkaufen versuchen würde. Aber er ist überaus nützlich, denn er ermöglicht es, schnell und kostengünstig Erkenntnisse zu sammeln.
Product Delivery
Zweck all dieser Prototypen und Experimente bei der Discovery ist, rasch etwas zu finden, das mit einiger Gewissheit die Herstellung wert ist und das wir dann unseren Kunden bereitstellen können.
Das bedeutet, dass die notwendige Skalierung, Performance, Reliability, Fehlertoleranz, Security, der Datenschutz, die Internationalisierung und Lokalisierung erfüllt sind und das Produkt wie beworben funktioniert.
Zweck der Product Delivery ist es, diese Technologieprodukte in Produktionsqualität herzustellen und zu liefern, etwas, das Sie verkaufen und mit dem Sie ein Geschäft machen können.
Produkte und Product/Market-Fit
Allein dass wir die Zeit und Mühe investiert haben, ein belastbares Produkt zu schaffen, heißt noch lange nicht, dass es irgendjemand kaufen wird, also streben wir nach dem Product/Market-Fit.
Das ist das reduzierteste tatsächliche Produkt, das die Bedürfnisse eines spezifischen Kundenmarktes erfüllt. Die Verbreitung dieses äußerst wichtigen Konzepts wird Marc Andreessen zugeschrieben und es ist ein Schwerpunkt dieses Buches.
Nur um das klarzustellen: Da es sich dabei um tatsächliche Produkte handelt, sind siedas Ergebnis der Delivery. Die Arbeitsschritte der Discovery helfen uns dabei, das benötigte Produkt zu bestimmen, aber die Delivery ist es, die tatsächlich dafür sorgt, dass es hergestellt, getestet und auf den Markt gebracht wird.
Product Vision
Das letzte wichtige Konzept ist die Product Vision. Sie bezieht sich auf die längerfristige Zielsetzung dieses Produkts, normalerweise zwei bis zehn Jahre im Voraus. Es geht darum, wie wir als Produktorganisation zur Unternehmensmission beitragen wollen.
Wir verwenden also Prototypen, um rasche Experimente bei der Product Discovery durchzuführen, und bei der Delivery produzieren und vermarkten wir dann Produkte in der Hoffnung, einen Product/Market-Fit zu erreichen, was wiederum ein entscheidender Schritt auf dem Weg ist, die Product Vision des Unternehmens zu erfüllen.
Machen Sie sich keine Sorgen, wenn Ihnen jetzt irgendeins dieser Konzepte noch nicht ganz klar ist. Ich weiß, Sie haben wahrscheinlich viele Fragen, aber die werden hoffentlich beantwortet, wenn wir näher auf jedes der Themen eingehen. Es ist auch ganz normal, ein bisschen skeptisch zu sein – »Wie soll das denn gehen, fünfzehn solcher Experimente in einer Woche durchzuführen?«.
Ich habe Sie ja vorgewarnt, dass starke Produktteams nicht so arbeiten wie die meisten anderen Teams, und das sollte Ihnen einen ersten Vorgeschmack darauf geben, wie verschieden die Dinge sein können.
Minimum Viable Product
Das Konzept des Minimum Viable Product (MVP) ist eins der wichtigsten im Product Management. Es existiert schon seit vielen Jahren. Der Begriff wurde geprägt von Frank Robinson (im Jahr 2001) und ich habe in der ersten Auflage dieses Buches (2008) darüber geschrieben. Weite Verbreitung erlangte er jedoch durch das Buch The Lean Startup von Eric Ries aus dem Jahr 2011.
Erics