Читать книгу Inspired - Marty Cagan - Страница 19

8 Die Hauptkonzepte

In diesem Buch nehme ich Bezug auf eine Reihe von Konzepten, welche die Grundlage der modernen Produktarbeit darstellen. Ich möchte sie hier kurz erklären.

Holistisches Produkt

Ich habe den Begriff Produkt bislang eher unspezifisch verwendet und gesagt, dass ich nur über technologiegetriebene Produkte spreche. Aber im allgemeineren Sinne verbinde ich mit dem Begriff Produkt eine sehr ganzheitliche Definition.

Dazu gehört sicherlich die Funktionalität – die Leistungsmerkmale.

Doch dazu gehört auch die Technologie, die diese Funktionalität ermöglicht.

Außerdem gehört dazu das User Experience Design, das diese Funktionalität präsentiert.

Es gehört dazu, wie wir diese Funktionalität zu Geld machen.

Es gehört ebenfalls dazu, wie wir Nutzer und Kunden gewinnen und akquirieren.

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 Buch war für Produktteams von großem Nutzen und aus meiner Sicht ist es eine unverzichtbare Lektüre für alle im Product Management Beschäftigten. Aber die meisten würden wohl zugeben, dass das Konzept des MVP in den Reihen der Produktteams einige Verwirrung ausgelöst hat, und ich verbringe viel Zeit damit, Teams dabei zu helfen, sich dieses wichtige Konzept zunutze zu machen.

Wenn ich ein Team kennenlerne, das hart daran gearbeitet hat, ein MVP zu schaffen, kann ich die Teammitglieder meistens davon überzeugen, dass sie denselben Lerneffekt auch mit einem Bruchteil der Zeit und Mühen hätten erreichen können.

Sie haben tatsächlich Monate mit der Erstellung eines MVP verbracht, dabei hätten sie dieselben Erkenntnisse auch innerhalb von Tagen oder manchmal sogar Stunden erlangen können.

Eine weitere unselige Konsequenz besteht darin, dass der Rest des Unternehmens – insbesondere die obersten Führungskräfte im Verkauf und im Marketing – verwirrt und peinlich berührt davon ist, was das Produktteam den Kunden da andrehen will.

Zum Teil liegt das sicherlich daran, wie die meisten Menschen dieses Konzept erlernt haben, aber ich glaube, die Wurzel des Problems ist diese: Das P in MVP steht zwar für Produkt, doch ein MVP sollte niemals ein tatsächliches Produkt sein (das als etwas definiert wird, was Ihre Entwickler voller Zuversicht auf den Markt bringen, mit dem Ihre Kunden Geschäfte machen und das Sie verkaufen und hinter dem Sie stehen können).

Das MVP sollte ein Prototyp sein, kein Produkt.

Das Schaffen eines tatsächlichen Produktes in Produktionsqualität zu Lernzwecken, selbst wenn das Ergebnis nur eine minimale Funktionalität aufweist, führt zu einer erheblichen Zeit- und Geldverschwendung und das ist natürlich genau das Gegenteil von Lean.

Ich finde, die Verwendung des allgemeineren Begriffs Prototyp macht diesen entscheidenden Punkt dem Produktteam, dem Unternehmen und den potenziellen Kunden deutlicher.

In diesem Buch spreche ich also von verschiedenen Arten von Prototypen, die bei der Discovery verwendet, und Produkten, die für die Delivery hergestellt werden.