Product Lunch am 19. Mai. Viele von Euch kennen sipgate sicher schon, denn das Unternehmen hat sich nicht nur als Internet-Telefonie-Anbieter einen Namen gemacht, sondern auch als Vorreiter bei agilen Arbeitsweisen. Umso spannender einmal zu schauen, welche Erfahrungen sipgate beim Thema Product Discovery gemacht hat und was wir davon lernen können – liebe Juliana Brell, nochmals vielen Dank für die hautnahen Einblicke und Tipps :).

Unser Produkt – weiß jemand, warum wir das hier gerade entwickeln?

Um wirklich gute Produkte zu erschaffen, muss das Scrumteam mitdenken können und benötigt auch Informationen über das „Warum und Wofür“. Sollte eigentlich klar sein? Gerade in größeren Unternehmen und größeren Projekten ist das längst nicht immer der Fall. So bleiben beispielsweise folgende Fragen unbeantwortet:

• Zu welchem strategischen Ziel leisten wir einen Beitrag?
• Welches Problem lösen wir für die Nutzer?
• In welchem Kontext wird unser Produkt benutzt?

 

Wenn auch der Product Owner über diese Infos nicht verfügt, resultieren bei den Scrumteams oft suboptimale Entscheidungen.

Und dann? Genau hier kann die Product Discovery anknüpfen:

Tipp 1: Berücksichtige vier Risiken bei der Product Discovery

Wenn die Teams folgende vier Risiken nach Marty Cagan berücksichtigen und Inhalte und Antworten dazu haben, lässt sich das Risiko erheblich reduzieren, am „Ziel vorbei“ zu entwickeln:

1. Value (Wert und Nutzen für die Kunden schaffen)
2. Usability (Bedienbarkeit und Verständlichkeit)
3. Feasibility (Machbarkeit)
4. Business Viability (Beitrag zur Strategie und für neue Erlöse)

 

Tipp 2: Product Discovery verorten und Verantwortliche(n) finden

Um die Product Discovery erfolgreich einzubinden und Antworten und Lösungen für die vier Risiken zu finden, hat das interdisziplinäre Scrumteam rund um Juliana folgendes Experiment gestartet:

Product Owner + UX-Research + Teile der Designer und Developer nehmen sich jede Woche einen ganzen Tag + x für die Product Discovery. Unterstützt wird das Team aktuell von einem Discovery Coach. Die Idee, das Thema in einem eigenen Sub-Team anzugehen, schont Ressourcen und vermeidet, dass die Delivery leidet.

Und was macht der Product Lead?

Kurz gesagt bereitet er den Weg vor, dass der Product Owner und die Developer gute Entscheidungen treffen können. Er ist die Schnittstelle zur Strategie und den übergeordneten Themen und sein Fokus liegt beim Opportunity Space (dieser beantwortet, welche Chancen bestehen, die von Wert sind und Bedürfnisse der Kunden bedienen). Der Product Lead beschäftigt sich also nicht mit Backlogs und Inhalten. Das machen die Developer und der Product Owner, wobei letzterer auch primäre Schnittstelle zum Product Lead ist.

Tipp 3: So könnt Ihr die Product Discovery durchführen

Und hier kommen die Schritte, wie das Team rund um Juliana bei sipgate aktuell vorgeht:

• Canvas als Startpunkt nutzen. Hierfür eignet sich etwa der Opportunity Canvas (vgl. bspw. https://www.jpattonassociates.com/opportunity-canvas/). Diesen bearbeiten Product Lead und Product Owner gemeinsam und identifizieren dabei Outcome und die Opportunity/-ies, wozu dann Lösungen entwickelt werden sollen
• Stakeholder (bspw. Salesteam, Kundenbetreuung, Kunden etc.) interviewen und Feedbacks einfließen lassen
• Lösungsideen für die (wichtigste) Opportunity finden und als Opportunity Solution Tree (also als Baumdiagramm) abbilden
• Effort Impact Matrix: Lösungsansätze nach Aufwand und Wirkung bewerten und beste Lösung auswählen
• Annahmen testen, Experimente machen:
  • Beantwortet dabei vorab zwei Fragen: “Was ist die im Experiment zu prüfende Hypothese?” und “Wie messen wir deren Erfolg?”
  • Und so könnt Ihr beispielsweise testen:
    • Rapid User Test: “Wie verhalten sich Leute bei Nutzung des Prototypen, wo würden sie etwa zuerst hinklicken?”
    • (Qualitative) Interviews mit Kunden, die das Produkt ganz neu nutzen
    • Prototypen intern verproben – bspw. mit neuen Mitarbeitern, die sich mit dem Thema noch nicht auskennen

 

Tipp 4: Infos kommunizieren und vernetzen

Juliana beschreibt den aktuellen Stand bei sipgate wie folgt:

So kommen Insights aus der Discovery zum Scrumteam

1. Die Product Discovery führen Mitglieder des Scrumteams durch (siehe auch Tipp 2)
2. Discovery-Themen werden in Scrum-Events integriert
3. Zudem gibt es einen Slack-Chanel zur Kommunikation, bspw. von Insights über Kunden

und so erfolgt die teamübergreifende Kommunikation 

1. Strategiethemen werden via Townhalls kommuniziert, dort können auch Fragen gestellt werden
2. Es gibt einen öffentlichen Slack-Chanel, wo Fragen an Product Leads gestellt werden können
3. Canvas-Montag: Product Leads und Product Owner tauschen sich über aktuelle Opportunies und deren Synergien und Schnittmengen aus
4. Zudem gibt es weitere Communities – bspw. treffen sich die die UXler jeden Montag und tauschen sich über Aktuelles aus. So gibt es also auf jeder Ebene Vernetzung und Austausch über die aktuelle Arbeit

 

Tipp 5: Damit gelingt ein erfolgreicher Einstieg

• Macht zuerst eine Bestandsaufnahme: Haben wir Leute mit Kenntnissen über das Thema Customer Research, haben wir Leute mit Discovery-Erfahrung etc. – was können wir schon, was fehlt?
• Findet idealer Weise Unterstützung aus dem Management – bspw. wenn es darum geht …
  • Product Owner / Product Manager zu befähigen und zu coachen, gerade wenn sie neu im Thema sind
  • Outcomes mit “oben” abzustimmen – wichtig ist eine Antwort auf die Frage “Worauf zahlt unser Handeln gerade ein?”. Entsprechend zu vermeiden sind kleingeschnittene Vorgaben, bei denen das Team nicht weiß, wofür das getan werden soll und wie das Gesamtbild aussieht
• Findet Verbündete, die sich mit dem Thema beschäftigen wollen und bereit sind, sich Wissen anzueignen – bspw. mit Hilfe des Silicon Valley Product Newsletters oder des Buches von Teresa Torres: Continuous Discovery Habits
• Entwickelt ein Bewusstsein für Fragen wie “Wo kommen Ideen und Entscheidungen für das Produkt her?”, “Wo hängt es gerade und was läuft schief?”, “Warum glauben wir, dass Product Discovery jetzt das Richtige ist (vielleicht wäre aktuell bspw. eine stabile Delivery wichtiger)?”
• Macht kleine Experimente und startet ggf. mit einem Pilotteam. Akzeptiert, dass nicht alles sofort super funktioniert
• Geht mit anderen in Austausch – bspw. während eines Spaziergangs mit Telefonat in der Mittagspause

 

Tipp 6: Mut zum Experimentieren und zur Lücke

Habt Mut zum Experimentieren und lasst Euch von Unsicherheiten nicht irritieren – sowohl die Einführung der Product Discovery im Unternehmen als auch die Generierung von Insights sind kaum mit wissenschaftlicher Genauigkeit möglich. So betonte auch Juliana, dass sie das Thema laufend weiter entwickeln. Als Leitplanken für die Qualität der Discovery nannte sie folgendes

• Blick auf Usability
• Experimente durchführen und deren Erfolg messen (mit Traction Metrics)
• Qualitative Prüfung via Interviews

 

und ergänzte „Discovery ist max. 80% – dann machen wir weiter“. Eine exakte Antwort auf die Frage “Wie hätte es ohne Discovery ausgesehen?” wäre hingegen sehr schwer zu finden und allzu aufwändig. Und vielleicht stellt sich dabei auch Euch die Frage, ob eine genaue Messung wirklich immer sinnvoll und notwendig ist.

Fazit: Nutzt beim Experimentieren die oben genannten Tipps und Euer Bauchgefühl, testet schnell und justiert nach – und geht agil vor.