Marty Cagan - Inspired

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 Teammitglieder sind typischerweise weiterhin ihrem Functional Manager zugeordnet. Zum Beispiel unterstehen die Engineers dem Engineering Manager. Ebenso sind die Designer für gewöhnlich dem Head of Design zugeteilt und die Product Manager dem Head of Product. Hier geht es also nicht um Hierarchien.

Um das absolut klarzustellen: Der Product Manager ist niemandes Chef im Produktteam.

Ein Produktteam ist eine Gruppe von hoch qualifizierten Personen, die sich für einen längeren Zeitraum zusammenschließen, um schwierige geschäftliche Probleme zu lösen.

Die Art ihrer Beziehung wird hauptsächlich durch echte Zusammenarbeit definiert. Dabei verstehe ich Zusammenarbeit nicht als abgedroschene Phrase. Es geht viel mehr darum, dass Produkt, Design und Technik im wörtlichen Sinne zusammen Lösungen erarbeiten. Dazu später noch viel mehr, fürs Erste ist es für Sie wichtig, zu verstehen, dass hier keine Hierarchie vorliegt.

Ich habe auch noch nichts darüber gesagt, wo die Mitglieder des Teams physisch verortet sind. Auch wenn das nicht immer möglich ist, geben wir uns größte Mühe, dieses Team am selben Ort arbeiten zu lassen.

Am selben Ort bedeutet, dass die Teammitglieder tatsächlich direkt nebeneinandersitzen. Also nicht im selben Gebäude und auch nicht auf derselben Etage. Es bedeutet, so nah beieinander, dass sie einander mühelos auf die Bildschirme schauen können.

Ich weiß, das klingt ein bisschen altmodisch, und die Tools für Zusammenarbeit über räumliche Grenzen hinweg werden immer besser, aber die besten Unternehmen haben den Wert eines gemeinsamen Standorts für Teams erkannt.

Falls Sie jemals zu einem Team mit gemeinsamem Standort gehört haben, wissen Sie bereits, was ich meine. Aber Sie werden an der Art, wie wir unsere Arbeit in einem Produktteam erledigen, erkennen, dass eine spezielle Dynamik entsteht, wenn ein Team zusammensitzt, zusammen zu Mittag isst und persönliche Beziehungen zueinander knüpft.

Ich bin mir darüber im Klaren, dass dies ein etwas emotionales Thema sein kann. Aus persönlichen Gründen leben etliche Menschen nicht an ihrem Arbeitsort und ihre Lebensgrundlage hängt davon ab, dass sie effektiv aus der Entfernung arbeiten.

Ich will das hier nicht allzu schwarz-weiß zeichnen, aber ich will Sie auch nicht in die Irre führen. Bei ansonsten komplett identischen Voraussetzungen wird ein Team mit gemeinsamem Standort wesentlich bessere Leistungen erbringen als ein verstreutes Team. Das ist einfach eine Tatsache.

Zudem ist das auch einer der Gründe, warum wir wesentlich lieber Festangestellte im Produktteam haben als befristete Auftragnehmer oder Dienstleister. Es ist viel leichter, einen gemeinsamen Standort zu haben und ein beständiges Teammitglied zu sein, wenn man fest angestellt ist.

Es ist völlig in Ordnung, wenn ein Unternehmen mehrere Standorte hat, solange wir nach Kräften darauf hinwirken, dass an jedem davon zusammensitzende Teams arbeiten.

Wir werden uns später noch damit beschäftigen, was wir tun können, wenn es nicht möglich ist, dass alle Teammitglieder zusammensitzen.

Haben Sie erst einmal die Grundlagen für ein Produktteam geschaffen, stellt sich als Nächstes diese große Frage: Wo liegt der Zuständigkeitsbereich jedes Teams? Das heißt, wofür ist jedes Team verantwortlich?

Einer der dazugehörigen Parameter ist die Art der zu erledigenden Arbeit und es ist wichtig, dass ein Produktteam die Verantwortung für die gesamte Arbeit trägt – Projekte, Features, Bugfixing, Performance, Optimierungen und inhaltliche Änderungen –, also für wirklich alles, was mit seinem Produkt zusammenhängt.

Der andere Aspekt ist der Arbeitsumfang. In einigen Unternehmen ist das Produktteam für ein komplettes Produkt zuständig. Heutzutage ist es jedoch häufiger so, dass das Produkt komplett identisch mit dem Kundenerlebnis ist (denken Sie nur an Facebook oder PayPal), und jedes Team ist verantwortlich für irgendeinen kleineren, aber bedeutsamen Teil dieses Erlebnisses.

Sie arbeiten beispielsweise in einem Team bei eBay, das für eine Technologie verantwortlich ist, die Betrug aufdeckt und verhindert, oder für Tools und Dienstleistungen für gewerbliche Anbieter. Oder Ihr Team ist bei Facebook zuständig für den Newsfeed, für eine native iOS App oder für die Einsatzmöglichkeiten, die für einen bestimmten vertikalen Markt erforderlich sind.

In einem kleinen Start-up ist das einfach, denn hier gibt es üblicherweise nur ein oder wenige Teams, in denen Sie leicht Dinge aufteilen können.

Doch wenn ein Unternehmen wächst, erweitert sich die Anzahl der Teams von einer Handvoll zu zwanzig, fünfzig oder mehr Teams in großen Produktunternehmen. Die Koordination wird schwieriger (dazu mehr im Abschnitt Product @ Scale), doch das Konzept ist sehr gut skalierbar und genau genommen einer der Hauptfaktoren für die Skalierbarkeit.

Es gibt viele sinnvolle Methoden, den Kuchen aufzuteilen. Manchmal konzentriert sich jedes Team auf eine andere Art von Anwendern oder Kunden. Manchmal ist jedes Team verantwortlich für eine andere Geräteart. Manchmal nehmen wir die Aufteilung nach Workflow oder Customer Journey vor.

Manchmal, oder genauer gesagt sehr häufig, definieren wir die Teams weitgehend aufgrund der Architektur. Das ist recht verbreitet, weil die Architektur die Technologieplattform bestimmt, und das erfordert oft verschiedene Arten von technischem Fachwissen.

Auf jeden Fall ist das Alignment zwischen Product Management und Engineering von größter Bedeutung. Deshalb setzen sich der Head of Product und der Head of Engineering normalerweise zusammen, um Größe und Zuständigkeitsbereich der Teams festzulegen.

Ich kann Ihnen sagen, dass es keine perfekte Aufteilung des Kuchens gibt. Machen Sie sich bewusst: Wenn Sie das eine optimieren, geht das auf Kosten von etwas anderem. Entscheiden Sie also, was Ihnen am wichtigsten ist, und halten Sie sich daran.

Ich habe schon mehrfach erwähnt, dass diese Teams dauerhaft zusammenbleiben müssen, aber ich habe nicht gesagt, ob damit ein paar Monate oder mehrere Jahre gemeint sind.

Grundsätzlich gilt, dass wir uns sehr bemühen, die Teams zusammenzuhalten und Stabilität zu gewährleisten.

Natürlich gibt es immer Unwägbarkeiten und die Leute wechseln den Arbeitsplatz oder das Team, doch wenn die Mitglieder eines Teams einander erst mal kennengelernt und herausgefunden haben, wie sie gut zusammenarbeiten können, ist das wirklich eine wunderbare und erfolgreiche Angelegenheit, also geben wir uns alle Mühe, diese Dynamik nicht zu zerstören.

Was das langfristige Zusammenhalten eines Teams ebenfalls so wichtig macht, ist, dass es eine Weile dauern kann, bis man genügend Fachwissen in einem Gebiet gesammelt hat, um zu innovieren. Wenn die Leute ständig von einem Team zum anderen wechseln, fällt es ihnen schwer, diese Fachkompetenz zu erlangen und das notwendige Verantwortungsgefühl sowie eine missionarische Leidenschaft für ihr Produkt zu entwickeln.

Ein Produktteam rufen wir nicht ins Leben, um nur ein einziges bestimmtes Projekt zu realisieren. Es ist nahezu unmöglich, ein Team aus Missionaren zu schaffen, wenn die Teilnehmer für ein Projekt zusammengebracht werden, das nur ein paar Monate dauert, und sich danach wieder trennen.