Produktentwicklung als Teil der Digitalen Transformation4 Tipps zum Einsatz von Product Discovery in traditionellen Unternehmen

Agile Vorgehensweisen erfreuen sich längst auch in traditionellen Unternehmen immer größerer Beliebtheit. Hiermit sind Unternehmen gemeint, die ursprünglich kein digitales Geschäftsmodell haben und sich zurzeit in der Digitalen Transformation befinden. Zu Beginn dieser Transformation ist die digitale Produktentwicklung noch kein integraler Bestandteil des Unternehmens, sodass digitale Produktteams oftmals organisatorisch von den Fachbereichen des Unternehmens getrennt sind. Zusätzlich wird in dieser Phase häufig nicht zwischen einem Produkt und einem Projekt unterschieden.

Aus dieser fehlenden Produktkultur entstehen neben den typischen Herausforderungen in der Produktentwicklung weitere Stolperfallen für Produktteams. Eine gemeinsame Product Discovery von Produktteam und Fachbereich kann dabei helfen, diese zu umgehen und gleichzeitig die Produktkultur des Unternehmens zu stärken. Nachfolgend findet ihr vier typische Probleme und deren Lösung mithilfe von Product Discovery.

1. Business als einziger Stakeholder – Woher kommen die Anforderungen für’s Produkt?

Bei jeder Produktentscheidung kann grob zwischen zwei Phasen unterschieden werden: “Decide what to build and then build it”. Der erste Teil (“decide what to build”) beschreibt dabei die Product Discovery, der zweite Part (“build it”) die Product Delivery.

Viele traditionelle Unternehmen haben bereits erfolgreich die Delivery von Software durch agile Methoden professionalisiert. Digitale Unternehmen hingegen haben in der Regel längst erkannt, dass die größere Herausforderung weniger in der Umsetzung, sondern viel mehr in der Identifikation eines relevanten Problems und der entsprechenden Lösungsfindung liegt. Genau diesem Teil der Produktentwicklung wird in traditionellen Unternehmen häufig noch nicht genug Beachtung geschenkt. Zur Definition eines Produktes werden weiterhin Methoden wie z.B. klassisches Requirements Engineering genutzt. Hierbei definiert ein Fachbereich Anforderungen, welche dann anhand der Spezifikation von der IT oder einer externen Agentur umgesetzt werden. Diese Vorgehensweise ist jedoch stark von der unternehmensinternen Sichtweise geprägt und lässt sich daher nicht direkt auf die Produktentwicklung für Kunden übertragen. Wie von Marty Cagan in seinem Buch Inspired beschrieben, werden hierbei kritische Risiken nicht bzw. erst nach Auslieferung des Produktes validiert:

  • Will the customer buy this, or choose to use it (value risk)
  • Can the user figure out how to use it (usability risk)
  • Can we build it (feasibility risk)

Genau diese Fragen sollen mit einer Product Discovery beantwortet werden. Zumindest soweit, dass das Risiko vor der Delivery deutlich minimiert wird.

Innerhalb von traditionellen Unternehmen kann die Discovery darüber hinaus dafür genutzt werden, aus einem bisher rein intern fokussierten Projektdenken ein kundenzentriertes Produktdenken zu entwickeln. Hierzu empfiehlt es sich ein Discovery-Team aus Fachbereich, Designern, Softwareentwicklern und Produktmanagern zusammenzustellen. Dieses Team ist dann gemeinsam sowohl für die Definition des zu lösenden Problems als auch für die zugehörige Lösungsfindung verantwortlich. Durch die verschiedenen Hintergründe der Teammitglieder können bereits bei der Definition des Produktes verschiedene Sichtweisen berücksichtigt werden.

Aus der rein internen Betrachtung wird ein kollaboratives Vorgehen, welches neben den Unternehmenszielen auch den Kundennutzen und die technische Umsetzbarkeit berücksichtigt. Dies führt nicht nur zu besseren Produkten, sondern fördert auch das gegenseitige Verständnis. Die frühzeitige Integration von Fachbereichen kann einerseits die Akzeptanz neuer Produkte innerhalb des Unternehmens erhöhen. Andererseits können Fachbereiche die Arbeitsweisen des Produktteams kennenlernen wodurch Produktdenken und Kundenfokus innerhalb des Unternehmens verbreitet werden.

2. Fokus auf Output statt Outcome – Wie wird Produkterfolg gemessen?

In traditionellen Unternehmen werden für die Produktentwicklung häufig die gleichen Erfolgsmetriken wie für Projekte herangezogen: Delivery in time, in scope und in budget. Dies sind alles Metriken für den Output eines Teams. Da Produktteams jedoch erst erfolgreich sind wenn das Gelieferte auch Outcome für das Unternehmen generiert, ist es unerlässlich, den Produkterfolg in Form von tatsächlicher Zielerreichung (gemessen durch KPIs) zu definieren. Neben der Erfolgsmessung sind KPIs essentiell um ein richtiges Level an Alignment zwischen Fachbereich und Produktteam herzustellen. (Hier im Blog findet ihr einen passenden Podcast zum Thema Produkt vs. Projekt.)

Genau bei der Definition von Produkterfolg tun sich viele traditionelle Unternehmen schwer. Eine Ausprägung davon ist, dass bei Diskussionen über Roadmaps der Fokus allein auf neue Features anstatt auf den erwarteten Outcome gelegt wird. In diesem Fall wird das Produktteam daran gemessen, wie viele Features in welchem Zeitraum geliefert, anstatt welche Probleme tatsächlich gelöst wurden. Eine gemeinsame Product Discovery kann dabei helfen, den erwünschten Outcome eines Features von Anfang an herauszuarbeiten. Somit gelangt man weg von einer Feature-getriebenen zu einer problemorientierten Denkweise: Hat das Discovery Team ein Problem gemeinsam erarbeitet, fällt es in der Regel deutlich leichter die Erfolgskriterien dieser Lösung zu definieren. Je klarer das Problemverständnis aller Beteiligten ist, umso einfacher lassen sich die KPIs für den Produkterfolg definieren.

Innerhalb des Product Discovery Prozesses sollte genug Zeit dafür reserviert werden, um festzulegen, wie der Erfolg nach der Umsetzung gemessen werden soll. Dies sollte bereits in der Phase der Problemdefinition vorbereitet und dann innerhalb der Lösungsfindung konkretisiert werden. Diese gemeinsam definierten KPIs sollten dann in der Dokumentation der Discovery festgehalten und nach Umsetzung regelmäßig an alle Stakeholder berichtet werden. Dies fördert nicht nur die Produktkultur innerhalb des Unternehmens, sondern sorgt für mehr Zufriedenheit bei Fachbereich und Produktteam. Fachbereiche können sicherstellen, dass die Unternehmensziele ausreichend berücksichtigt werden und das Produktteam erlangt den notwendigen Handlungsspielraum in der Umsetzung.

3. Fehlendes Verständnis für Aufwände – Wie werden Hindernisse kommuniziert?

Wie bereits in Daniels Artikel zu den Gründen des Scheiterns bei der digitalen Transformation beschrieben, wird “Digital” oft als schnelle Lösung für lang bestehende Probleme angesehen. Dies kann schnell dazu führen, dass Aufwände in der Produktentwicklung unterschätzt und der Fortschritt eines Produktteams als zu langsam angesehen werden. Besonders in Unternehmen mit vielen Altsystemen und nicht digitalisierten Prozessen, können scheinbar kleine Features schnell größere Aufwände nach sich ziehen. Durch eine organisatorische Trennung von Produktteam und Fachabteilungen werden diese nicht allen Abteilungen im Unternehmen direkt sichtbar und sind daher schwer nachzuvollziehen.

Innerhalb einer Product Discovery empfiehlt es sich daher, mit den Fachbereichen, ggf. der IT-Abteilung und einigen Softwareentwicklern aus dem Produktteam auch technische Herausforderungen in einem dedizierten Workshop zu diskutieren. Hierbei sollten notwendige Schritte bei der Umsetzung aus erster Hand – von Softwareentwicklern selbst – deutlich gemacht werden. Dies sorgt für besseres Verständnis bei allen Beteiligten und ist weitaus wirkungsvoller, als wenn technische Herausforderungen in späteren Status-Meetings vorgestellt werden. Hohe technische Aufwände können so in der Discovery zum frühestmöglichen Zeitpunkt identifiziert, kommuniziert und gemeinsam angegangen werden. Themen mit hoher technischer Unsicherheit sollten bestenfalls bereits innerhalb der Discovery selbst, z.B. in Form von eines Proof-of-Concept, angegangen werden. Die Ergebnisse hieraus können dann direkt in den Prozess einbezogen werden.

4. Komplexe Kommunikationswege – Wie schafft man Alignment?

Eine typische Herausforderung großer Unternehmen ist effiziente Kommunikation. Für ein erfolgreiches Produkt wiederum ist die Zusammenarbeit vieler Beteiligter notwendig, sodass erforderliche Abstimmungen schnell zeitintensiv werden können. Darüber hinaus ist es oftmals schwierig die verschiedenen Arbeitsweisen von Fachbereich und Produktteam zusammenzubringen.

Zwar gibt es agile Artefakte, wie z.B. Standups und Reviews, die einen regelmäßigen Austausch ermöglichen, jedoch kann durch eine gemeinsame Discovery ein wesentlich stärkeres Alignment zwischen Fachbereich und Produktteam hergestellt werden. Da das Discovery Team gemeinsam sowohl für Problemdefinition als auch Lösungsfindung verantwortlich ist, sorgt dies für eine wesentliche stärkere Identifikation dem Produkt an sich, als wenn fertige Produktinkremente in Reviews präsentiert werden. Durch diese frühzeitige Kommunikation in der Discovery können nicht nur bessere Produkte entstehen, sondern gleichzeitig Abstimmungsrunden mit dem Management oder anderen Abteilungen erleichtert werden. Da verschiedene Fachbereiche von Anfang an mitwirken können, wird das Produkt nicht als Fremdkörper sondern als Bestandteil des Unternehmens wahrgenommen.

Discovery erfolgreich im Unternehmen integrieren

Damit der gemeinsamen Product Discovery nichts im Wege steht, gibt es einige Dinge zu beachten: Aufgrund der fehlenden Erfahrung mit dieser Arbeitsweise kann es schwierig sein, den Wert dieses Vorgehens vorab deutlich zu machen. In der Regel führen Unternehmen bereits abseits der Entwicklung digitaler Produkte unterschiedlichste Projekte durch, so dass Fachbereiche bereits mit Meetings und Workshops überhäuft sind. Da eine Discovery dennoch einige Zeit benötigt und dieser vermeintlich hohe Zeitaufwand anfangs Skepsis hervorrufen kann (“Die Anforderungen sind doch alle schon klar, können wir das nicht einfach so bauen?”) ist eine gute Vorbereitung unerlässlich. Nach meiner Beobachtung ist es aufgrund des Tagesgeschäfts für Fachbereiche undenkbar eine ganze Woche am Stück zu investieren, weshalb Discovery Ansätze wie z.B. Design Sprints kaum umsetzbar sind. Besser funktioniert es, die Discovery in eine Serie von Workshops aufzuteilen, die sich dann je nach Themenumfang über mehrere Termine verteilen. Zwar benötigt dies dann einen etwas längeren Zeitraum, jedoch lässt sich eine Discovery dadurch in die bestehenden Arbeitsweisen von Fachbereichen integrieren.

Unabhängig davon wie die Discovery durchgeführt wird, sollte dabei eines unbedingt berücksichtigt werden: Diese Art der Arbeit ist besonders zu Anfang für viele Beteiligte ungewohnt. Eine gute Vorbereitung, ein erfahrener Moderator und passende Räumlichkeiten sind daher umso wichtiger. Alle zu erwartenden Schritte der Product Discovery sollten schon vor dem Start transparent gemacht und währenddessen ausreichend erklärt werden. Innerhalb des Prozesses sollten Ergebnisse und nächste Schritte regelmäßig allen Teammitgliedern und Stakeholdern kommuniziert werden.

Welche Erfahrungen habt ihr mit Product Discovery in traditionellen Unternehmen gemacht? Wir freuen uns über Kommentare und Feedback.

Über Philip Steen

Philip ist aktuell als Produktmanager bei der Digital Unit von AIDA Cruises in Hamburg tätig. Hier beschäftigt er sich vor allem mit der Entwicklung von digitalen Produkten, sowie der Einführung der dafür erforderlichen Prozesse und Methoden. Zuvor war Philip in der Beratung im E-Commerce Umfeld tätig und hat in der Softwareentwicklung bei CoreMedia gearbeitet. Ab Januar 2019 wird er als freiberuflicher Produktmanager und Agile Coach tätig sein, um Kunden bei der Entwicklung von digitalen Produkten zu unterstützen.

2 Kommentare

  1. FelixT1000

    So wie ich die Konstellation und Aufgabenstellung des Discorvery Teams interpretiere, vermutet dieses Team Probleme, skizziert gemeinsam erste Lösungen und validiert diese frühzeitig mit Anwendern.

    Da die Anwender in der Konstellation in Form von Vertretern unterrepräsentiert sind, muss das Team sich bewusst machen, dass Anwender vermeintliche Lösungen nicht akzeptieren könnten.

    Ich habe erlebt, wie eine ähnliche “task force” ein Problem „erkannt“ hat, dafür eine Lösung skizzierte, die dann von Kunden und deren Anwender als unnötig empfunden wurden. Es erforderte viel Fingerspitzengefühl, dem Team (und damals gefühlt dem halben Management der Firma) verständlich zu machen, dass diese Lösung keinen Anklang finden wird. Aber: Je häufiger wir den Prozess gemeinsam durchschritten, desto mehr Verständnis und Routine kehrte ein.


  2. Dietrich Bachmann

    Kommunikation in allen Bereichen von Business ist sehr wichtig, besonders in Zeiten wie diese mit dem Coronavirus. Wenn es nicht möglich ist, im Büro Gespräche zu haben, muss man seine Gedanken ausdrücken können. Die Produktentwicklung spielt eine große Rolle. Wenn erforderlich, könnte ein Unternehmen eine Engineeringfirma aussuchen, die mit der Entwicklung von Produkten helfen kann.


Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Mit Absenden des Kommentars stimmst Du der Speicherung deiner persönlichen Daten (Name, eMail-Adresse, Webseite und Nachricht) durch uns bis auf Widerruf zu. Zur Vermeidung von Spam und zur rechtlichen Absicherung wird deine IP für 2 Monate gespeichert. Ebenfalls zur Vermeidung von Spam werden diese Daten einmalig an Server der Firma Automattic inc. geschickt. Zur Darstellung eines Nutzerbildes wird die eMail-Adresse im pseudonymisierter Form an Automattic inc. übermittelt. Wenn du einen oder beide Haken für die eMail-Benachrichtigungen setzt, wird deine eMail-Adresse bei Automattic inc. gespeichert. (Datenschutzerklärung)

Du hast noch viel mehr zu erzählen?

Dann schreib doch einen eigenen Artikel auf produktbezogen.

Artikel vorschlagen →