Product Discovery und Scrum
Ein Praxiseinblick

Product Discovery und Scrum

Die Gäste zum Thema Product Discovery und Scrum
Antina Horster & Juliana Brell

Juliana ist mit ihrem Hintergrund aus Psychologie, Informatik und Kommunikationswissenschaft in der Tech-Branche gelandet und bildet die Schnittstelle zwischen verschiedenen Disziplinen. Als Product Discovery Coach mit UX Research Expertise unterstützt sie Teams dabei, gute Entscheidungen zu treffen und durch Experimente iterativ sowohl das Produkt als auch die Prozesse zu verbessern.

Antina ist Product Owner und kommt ursprünglich aus der Medien- und Agenturwelt, konkret Sales und New Business. Mittlerweile setzt sie ihre Fähigkeiten und Begeisterung für die unterschiedlichen Perspektiven auf Produkte, die Kunden und das Business in der agilen Entwicklung von SaaS Produkten ein. Sie kümmert sich um ein wertvolles Backlog für ihr crossfunktionales Team, um gemeinsam gute Software iterativ zu shippen.

Aktuell (2023) arbeiten Juliana & Antina beide bei sipgate, die seit 2004 Cloud-Telefonie für primär den B2B Bereich anbieten. Bei sipgate gibt’s also Software zum Telefonieren und für professionelle Telefonieszenarien fürs Büro, das Home Office und Unterwegs.

Was ist Product Discovery?

Product Discovery dient dazu, Unsicherheiten bei der Produktentwicklung im Team zu minimieren und das (bestenfalls crossfunktionale) Team zu befähigen, gute Entscheidungen zu treffen. Discovery ist das Gegenstück zur Product Delivery. Während es in der Delivery darum geht, Software tatsächlich zu bauen und auszuliefern, geht es in der Discovery darum, informierte Entscheidungen zu treffen, was gebaut werden soll. Das passiert auf zwei Ebenen:
1) Mit welchem Problem sollte sich ein Produktteam als nächstes befassen?

2) Welcher Lösungsansatz ist für das gewählte Problem am besten?

Dabei ist es wichtig zu wissen, dass die Art und Weise, wie Discovery für Unternehmen funktioniert, je nach Produktlebenszyklus (z.B. Startup vs. Grownup) und Unternehmensform (z.B. Agentur vs. Produkt) anders ist. Wir bei sipgate haben mit unserer Cloud Telefonie Software ein seit 2004 gereiftes B2B SaaS Produkt. Daher geht es bei uns aktuell – es ist tatsächlich eine momentane Bestandsaufnahme, denn das sah vor und sieht in 6 Monaten vermutlich anders aus – um das Hebeln von Wert im Rahmen unserer Produktstrategie. Wir arbeiten also mit Annahmen über den Problemraum aus der Strategie, erforschen im Team den Lösungsraum und entwickeln die Lösung. 

“Wir” bedeutet in diesem Artikel: Es ist ein persönlicher Erfahrungsbericht von Antina Horster (Product Owner) & Juliana Brell (Product Discovery & Research) und keine Handlungsanleitung von sipgate als Unternehmen. 

Klicken Sie auf den unteren Button, um den Inhalt von play.libsyn.com zu laden.

Inhalt laden

Warum macht ihr Discovery? Fehlte euch in der Produktentwicklung etwas, als ihr primär mit Scrum gearbeitet habt?

Kurze Antwort: Ja!

Lange Antwort: Scrum setzen wir seit 2012 als Framework dafür ein, wie unsere agilen Teams iterativ Software entwickeln. Seitdem ist sipgate sowohl personell als auch produkttechnisch gewachsen. Es gibt mehr Teams, neue Strukturen und eine vollwertige Cloud-Telefonanlage inklusive App und allem, was das Telefonie-Herz begehrt. Und da kam vor 1,5 Jahren das Thema Product Discovery ins Rennen, denn die Fragen “Was ist wirklich wertvoll für uns und Kund:innen? Was kommt ins Backlog? Wie können wir in den Produktteams eigenständig gute Entscheidungen bzgl. Problem- und Lösungsraum treffen?” lassen sich nicht mit Scrum beantworten. Während wir in der Delivery weiterhin akkurat nach Scrum arbeiten, ist es bei uns in der Discovery flexibler und zusätzlich von Team zu Team unterschiedlich. Scrum findet also genauso statt wie vorher – nur dass wir durch die Discovery sicherer sind, an der relevantesten Stelle zu arbeiten und die beste Lösung für das Problem zu wählen.

Wie hilft Product Discovery dabei, bessere Produkte zu entwickeln?

Als Unternehmen, als Produktteam und besonders als Product Owner (PO) tragen wir bei Entscheidungen das Risiko a) in ein unwichtiges Problem zu investieren oder b) eine unpassende Lösung zu entwickeln, die uns viel Geld oder sogar unsere Kund:innen kostet. Dabei ist direkt sichtbar: Das kann eine Person nicht alleine bearbeiten, denn so viel Wissen hat niemand. Dafür braucht es verschiedene Rollen und Fähigkeiten. 

Der Scrum Guide gibt POs eine Rolle, in denen sie die Verantwortung tragen, das Wertvollste ins Backlog zu bringen und mit dem Team umzusetzen. Nun gibt aber Scrum keinerlei Hilfestellung, wie man herausfindet, was eigentlich das next big thing ist und welche Idee man besser verwirft. Um die Trefferquote für Wertvolles zu maximieren, befassen wir uns in kontinuierlichen Discovery Aktivitäten und verschiedenen Rollen mit potenziellen Risiken aus vier Bereichen:

  • Business Viability = hat es Relevanz für das Unternehmen?
  • Customer Value = liefert es Wert für unsere Kund:innen? 
  • Usability = können wir es für Kund:innen verständlich umsetzen? 
  • Feasibility = ist es technisch machbar?
 

Das sind Risiken, die wir vor der tatsächlichen Produktentwicklung klären sollten. Die frühen Discovery-Aktivitäten gehen somit der Delivery voraus und ermöglichen uns zudem das Verwerfen von Ideen, bevor sich das gesamte Team ausführlich damit beschäftigt. Iteratives Arbeiten und der “Build Measure Learn”-Kreislauf finden also gezielter statt.

Welche Fallstricke gibt es, wenn man in einem Scrum Team Product Discovery aufgreift? 

Puh, tatsächlich so einige! Und wir sind in viele davon rein gelaufen, waren verwirrt und haben uns wieder entwirrt. Diese Achterbahnfahrt beim Herausfinden, was für das Unternehmen bzw. das jeweilige Team funktioniert, ist definitiv Teil des Prozesses – auch heute noch 😉 Es gibt bei Discovery im Gegensatz zu Scrum kein vorgegebenes Schema, das man anwendet und einfach iteriert. Es fühlt sich an wie ein Versuchslabor.

Wenn ein Team sich mit dem Thema Discovery befasst und für sich herausfindet, wie das funktionieren kann, wird in dieser Zeit weniger Software als zuvor geshippt. Es findet z.B. Kontext-Switching statt und es gibt mehr Termine. Das führt sowohl bei Management-Rollen als auch im Team erstmal zu Unsicherheit und teilweise Unmut – es macht uns hinten raus allerdings sicherer und effizienter. Zudem baut das Team immer mehr Wissen über die Zielgruppe, deren Verhalten und das eigene Produkt auf. 

Klingt nach nem Haufen Mental Load für POs? Ist es. Denn neben der Backlog- und Stakeholder-Arbeit findet viel Strukturierungsarbeit und Denken auf Metaebene statt. 

Nicht nur POs, alle Mitglieder eines Produktteams müssen für den neuen Modus ein paar Verhaltensweisen ändern: Sie sind nun nicht mehr ausschließlich fürs Umsetzen und Shippen verantwortlich, sondern fürs Herausfinden, gemeinsam Entscheiden und fürs Wegwerfen. Gerade Letzteres ist die ersten Male schmerzhaft, spart aber viel Zeit (und damit Geld). 

Was hat sich für euch bisher bewährt, um als Scrum-Team gemeinsam und effektiv ein Produkt zu entwickeln?

Das Wichtigste zuerst: Experimente! Und zwar sowohl bzgl. des Produkts als auch bzgl. des Arbeitsmodus. Wir haben beispielsweise zu Beginn jedes Scrum Meeting stumpf dupliziert und für die Discovery ebenfalls eingeführt. Mit dieser Doppelung aller Termine war der Terminkalender dicht und das Team frustriert. 

Die Integration von Discovery in den Scrum-Alltag statt einer strikten Trennung der Phasen halten wir dennoch für essentiell. Dabei ist es wichtig, dass ihr die bisherigen Rollenverantwortungen aufbrecht und ausprobiert, wer was gut kann und mag. Yes, Devs führen prima Interviews! Apropos Interviews, wir bei sipgate haben eine zusätzliche Rolle in unsere Produktteams integriert: Research. Durch die Fähigkeiten dieser weiteren Person sitzen wir u.a. direkt an der Quelle für Methoden für die Discovery und haben eine:n Sparringspartner:in für die POs.

Was sich für uns wirklich lohnt: Einen wöchentlichen Discovery Review Termin abhalten, an dem alle Teammitglieder teilnehmen und die Erkenntnisse und Ideen aus der Discovery feedbacken. So bleiben alle in den Prozess involviert, wenn ein Teil des Teams teilweise in der Discovery arbeitet, während die anderen Teammitglieder in der Delivery arbeiten. Denn nicht jede Person im Team macht beides. Es hat sich ein Mix aus verschiedenen Rollen (bei uns z.B. Design, Research, PO, teilweise Dev) als Discovery-Quartett bewährt. 

Zuletzt noch ein Satz zum Thema Transparenz: Es ist für den Erfolg der Discovery-Initiative essentiell, sowohl innerhalb als auch außerhalb des Teams transparent und visuell zu kommunizieren, an welchen “Opportunities” (Möglichkeiten) das Team gerade arbeitet. Wir benutzen bei uns das Tool miro in Kombination mit dem von uns adaptierten Opportunity Canvas von Jeff Patton. 

Und jetzt hört in den Podcast rein, da gibt es noch ein paar Tipps on Top! 😉 

Danach noch Fragen? Kontaktiert uns gern einfach über Linkedin. 

Im Podcast diskutiert

Product Discovery Bücher

Über diese beiden Bücher hatten wir in der Folge gesprochen. Wir hoffen, sie helfen euch die Idee, Product Discovery besser zu verstehen und so eine Idee zu entwickeln, wie man beides gut verbinden kann.

Newsletter

Halte dich auf dem Laufenden

Community Events

Wir organisieren regelmäßig Events in denen wir gemeinsam Themen aufarbeiten und uns Austauschen wollen.

Ralf Kruse