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.
Teil II: DIE RICHTIGEN LEUTE
Jedes Produkt beginnt mit den Leuten im crossfunktionalen Produktteam. Wie Sie die Positionen definieren und wen Sie auswählen, um bei diesem Team mitzuwirken, erweist sich sehr wahrscheinlich als bestimmender Faktor für seinen Erfolg oder Misserfolg.
Dies ist ein Bereich, in dem viele Unternehmen versagen, weil sie in den alten Modellen der Vergangenheit feststecken. Für viele Organisationen repräsentieren die hier besprochenen Positionen und Verantwortlichkeiten etwas deutlich anderes, als sie gewohnt sind.
In Teil II beschreibe ich die Schlüsselrollen und -verantwortlichkeiten moderner technologiegetriebener Produktteams.
PRODUKTTEAMS
Überblick
Dies ist wohl das wichtigste Konzept im gesamten Buch:
Es dreht sich alles um das Produktteam.
Das werden Sie mich im Laufe der folgenden Kapitel auf die verschiedensten Arten sagen hören, aber ein so großer Teil dessen, was wir in einer starken Produktorganisation tun, besteht darin, die Effektivität von Produktteams zu optimieren.
9 Die Grundsätze starker Produktteams
In den folgenden Kapiteln werde ich auf jede der wichtigen Rollen in einem Team eingehen, aber in diesem Kapitel erkläre ich zunächst die Grundsätze eines starken Produktteams.
Produktteams werden manchmal als fest zugeordnete Produktteams oder als dauerhafte Produktteams bezeichnet, um hervorzuheben, dass sie nicht nur für die Arbeit an einem einzelnen Projekt oder Feature zusammengestellt wurden. Gelegentlich werden sie auch Squad genannt – ein Begriff aus dem Militärwesen, der betonen soll, dass es sich um funktionsübergreifende Teams handelt.
Ein Produktteam ist eine Gruppe von Personen, die unterschiedliche spezialisierte Fähigkeiten und Zuständigkeiten aufweisen und echte Verantwortung für ein Produkt oder zumindest für einen maßgeblichen Teil eines größeren Produkts tragen.
Es gibt viele Möglichkeiten, Produktteams zusammenzustellen (über die wir später im Abschnitt People @ Scale sprechen werden). Aber Sie werden feststellen, dass es in guten Produktunternehmen eine Reihe sehr wichtiger Gemeinsamkeiten gibt, trotz der Unterschiede, die durch die jeweiligen Umstände und einzigartigen Produkte bedingt werden.
Ein Team aus Missionaren
Es gibt viele Vorzüge von Produktteams, aber ein großes Ziel lässt sich am besten durch ein Zitat des berühmten Silicon-Valley-Investors John Doerr illustrieren: »Wir brauchen Teams aus Missionaren, nicht aus Söldnern.«
Wir brauchen Teams aus Missionaren, nicht aus Söldnern.
Söldner schaffen das, was man ihnen vorschreibt. Missionare glauben wirklich an die Mission und setzen sich dafür ein, Probleme für ihre Kunden zu lösen. In einem fest zugeordneten Produktteam agiert und wirkt das Team recht ähnlich wie ein Start-up innerhalb des größeren Unternehmens, und genau das ist die Absicht.
Teamzusammensetzung
Ein typisches Produktteam besteht aus einem Product Manager, einem Product Designer und zwischen zwei und zehn bis zwölf Engineers.
Sicher, wenn das Produkt, an dem Sie arbeiten, sich nicht unmittelbar an den Benutzer richtet – zum Beispiel eine Serie von Programmierschnittstellen –, brauchen Sie wahrscheinlich keinen Product Designer. Aber viele Produktteams benötigen diese Position und in diesem Buch gehe ich allgemein davon aus, dass dies auch auf Ihr Team zutrifft.
Teams können auch weitere Mitglieder haben, zum Beispiel einen Product Marketing Manager, einen oder mehrere Test Automation Engineers, einen User Researcher, einen Data Analyst und, bei größeren Produktorganisationen, einen Delivery Manager.
Machen Sie sich keine Gedanken, wenn Sie noch nicht wissen, wozu einige dieser Positionen gut sind – wir gehen in Kürze auf jede davon näher ein.
Teamkompetenzen und Zuständigkeit
Wesentlich für das Konzept von Produktteams ist, dass sie dazu da sind, schwierige unternehmerische Probleme zu lösen. Sie erhalten klare Zielvorgaben und stehen für ihre eigene Umsetzung dieser Ziele gerade.
Sie haben die Befugnis, die besten Methoden herauszufinden, um diese Ziele zu erfüllen, und sie sind zuständig für die Ergebnisse.
Teamgröße
Es gibt keine Regel, wonach alle Produktteams in einem Unternehmen dieselbe Größe haben müssen. Zwar gibt es die Vorstellung einer Mindestgröße für ein Produktteam – für gewöhnlich ein Product Manager, ein Designer und zwei Engineers. Doch für manche Teams können auch fünf Engineers und zwei Test Automation Engineers gerechtfertigt sein – oder sogar mehr.
In der Praxis ergibt sich eine Obergrenze für ein Team, die normalerweise bei etwa acht bis zwölf Programmierern erreicht ist. Sicher haben Sie schon mal von der Zwei-Pizza-Regel gehört, die dazu dienen soll, Teams in dieser Größenordnung zu halten.
Wichtiger als die tatsächliche Größe des Teams ist jedoch das Gleichgewicht der Qualifikationen, die erforderlich sind, um die richtigen Dinge herzustellen und diese Dinge auch richtig herzustellen.
Die Hierarchiestruktur im Team
Beachten Sie, dass ich noch nichts darüber gesagt habe, wer für wen arbeitet.
Bei einem Produktteam geht es nicht um Hierarchien – es hat eine bewusst flache Organisationsstruktur. Für gewöhnlich leistet jeder in einem Produktteam einen individuellen Beitrag und es gibt keinen Vorgesetzten.
Die