Close

Erzielung von Produktergebnissen mit Ideen – vom Grundgedanken bis zur Auslieferung

In Jira Product Discovery sind "Ideen" das Hauptobjekt, mit dem du in deinem Produkt-Backlog arbeitest. Um einen kontinuierlichen Validierungs- und Lernprozess zu unterstützen, verwenden wir Ideen als langlebige Objekte. Eine Idee verschwindet zwar aus dem Backlog, wenn die Entwicklung beginnt, setzt sich aber in allen Iterationen der Ideenfindung und Auslieferung fort, bis sie die erforderliche Wirkung erzielt.

Erfolgreiche Produktteams verfolgen einen experimentellen Ansatz: Sie überarbeiten die Idee im Laufe der Zeit immer wieder, indem sie ihr mehr Kontext, Benutzerfeedback, Spezifikationen und Design hinzufügen. In jeder Phase des Ideenlebenszyklus bewerten sie, was funktioniert hat und was nicht. Sie beantworten wichtige Fragen und validieren ihre Annahmen, um sicherzustellen, dass ihre Investitionen dem Feedback und der Bestätigung angemessen sind, die sie erhalten.


Ideen von groß bis klein

Obwohl der Name des Objekts, das du in Jira Product Discovery verwendest, "Ideen" lautet, kann es sich dabei um Produktideen, Chancen, Probleme, Lösungen und mehr handeln. Ein Produkt-Backlog kann so gestaltet werden, dass es Ideen unterschiedlicher Art und Granularitätsstufen enthält.

Es ist wichtig, diese Kategorien zu definieren und dafür zu sorgen, dass sich alle am Prozess Beteiligten darauf einigen. Dadurch wird verhindert, dass das Produkt-Backlog eine Mischung aus Elementen enthält, von supergroß bis superklein, ohne Klassifizierungs- und Vergleichsrahmen.

Felsbrocken, Steine und Kieselsteine: eine Möglichkeit, Ideen zu klassifizieren

Im Jira Product Discovery-Team organisieren wir Ideen in drei Ebenen: Felsbrocken, Steine und Kieselsteine.

Felsbrocken, Steine und Kieselsteine

Felsbrocken, Steine und Kieselsteine

  • Felsbrocken: eine große Investition, die sich potenziell auszahlt, aber auch ein hohes Maß an Ungewissheit birgt
    • Beispiel: großes neues Vorhaben, neue Produktsäule, großes Entwicklungsprojekt
  • Steine: mittelgroße Investitionen mit weniger Risiken
    • Beispiel: Neue Funktionen, neue Onboarding-Experimente, Designänderungen auf der Grundlage von Feedback
  • Kieselsteine: Kleine, in der Regel unkomplizierte Investitionen
    • Beispiel: Kleine UX-Verbesserungen, einfache Fehlerbehebungen

Unser Team verwendet separate Ansichten, um diese verschiedenen Kategorien von Ideen zu besprechen:

Ansicht von Felsbrocken in Jira Product Discovery

Ansicht von Felsbrocken in Jira Product Discovery

Ansicht von Steinen in Jira Product Discovery

Ansicht von Steinen in Jira Product Discovery

Ansicht von Kieselsteinen in Jira Product Discovery

Ansicht von Kieselsteinen in Jira Product Discovery


Attribute einer Idee

In Jira Product Discovery umfasst jede Idee eine einzeilige Zusammenfassung, eine detaillierte Beschreibung, Einblicke wie Kundenfeedback und Links zu Jira-Tickets für die Umsetzung der Idee.

Eine Idee in Jira Product Discovery

Eine Idee in Jira Product Discovery

Umsetzungsbereich für eine Idee in Jira Product Discovery

Umsetzungsbereich für eine Idee in Jira Product Discovery

Um so nützlich und umsetzbar wie möglich zu sein, sollte jede Idee im Produkt-Backlog über diese Attribute verfügen:

Attribut

Worum geht es?

Zusammenfassung

Worum geht es?

Ein Einzeiler über die Idee.

Beschreibung

Worum geht es?

Eine detailliertere Beschreibung der Chance, des Problems und der Lösung.

Felder

Worum geht es?

Die verschiedenen Facetten der Idee: zu welchem Ziel sie beiträgt, ihre Phase, welchen Teil des Produkts sie betrifft, Informationen zur Priorisierung, z. B. Wirkung oder Aufwand, Links zu Spezifikationen oder Designs.

Einblicke

Worum geht es?

Einblicke, die über alle Kanäle erfasst werden: wichtige Erkenntnisse aus Benutzerfeedback, Auszüge aus Kundengesprächen und Forschungsberichten oder Produktanalysen, die klar formulieren, warum diese Idee wichtig ist.

Delivery

Worum geht es?

Links zu Umsetzungstickets in Jira (Epics oder Initiativen), damit die Umsetzungsarbeit die Produktidee tatsächlich voranbringt.

Es kann eine Weile dauern, all diese Informationen für jede Idee zusammenzutragen. Zunächst wird eine Idee möglicherweise nur mit einer einzeiligen Zusammenfassung in dein Backlog aufgenommen, zum Beispiel mit einem Einblick aus einem Kundengespräch. Im Laufe der Zeit werden mehr Einblicke gesammelt, basierend auf Interviews mit Benutzern, Feedback von Vertrieb oder Support oder Änderungen der Unternehmensstrategie.

Ein Einzeiler mit Benutzerfeedback

Ein Einzeiler mit Benutzerfeedback

Mit Benutzerfeedback und Analyse möglicher Auswirkungen

Mit Benutzerfeedback und Analyse möglicher Auswirkungen

Mit einer validierten Lösung und der Umsetzung in vollem Gange

Mit einer validierten Lösung und der Umsetzung in vollem Gange

Es gibt zwei Möglichkeiten, Ideen zu beschreiben: direkt in Jira Product Discovery oder durch die Verknüpfung von Confluence mit dem Jira Product Discovery-Projekt deines Teams.

Gib in Jira Product Discovery eine Zusammenfassung oder Definition in das Beschreibungsfeld der Idee ein. Verwende eine der bereitgestellten Vorlagen oder erstelle deine eigene, um eine einheitliche Formel für die Beschreibung von Problemen, Lösungen, Hypothesen und weiteren Informationen zur Idee vorzugeben.

Beschreibung einer Idee in Jira Product Discovery

Beschreibung einer Idee in Jira Product Discovery

Wenn dein Team auch Confluence verwendet, kannst du die Idee mit Confluence-Seiten verknüpfen: entweder in der Beschreibung der Idee oder mithilfe benutzerdefinierter Hyperlink-Felder. Der Vorteil dieses Ansatzes ist, dass du alle Funktionen von Confluence für die Zusammenarbeit nutzen kannst, zum Beispiel Inline-Kommentare.

Der Inhalt der Beschreibung hängt von der Art der Idee und ihrer Phase ab.

Beschreibung einer Idee auf einer verlinkten Confluence-Seite

Beschreibung einer Idee auf einer verlinkten Confluence-Seite


Der Ideen-Lebenszyklus

Die Entwicklung einer Idee im Laufe der Zeit ist genauso wichtig wie ihr Inhalt. Deshalb sollten für jede Idee klare Phasen definiert werden, die sie während ihres Lebenszyklus durchläuft. Ein gemeinsames Vokabular zur Beschreibung dieser Phasen macht Gespräche produktiver, sei es innerhalb des Teams oder mit Stakeholdern.

Bei Atlassian verwenden wir vier Phasen: Überlegen, Erkunden, Machen und Resultat. Jeder weiß, was diese einzelnen Phasen bedeuten. Für jede Phase wissen wir, mit welcher Art von Arbeit das Team beschäftigt ist, welche Art von Fragen es stellen muss und welche Art von Hilfe das Team möglicherweise benötigt. Diese Konsistenz gilt für Gespräche innerhalb des Teams, mit anderen Teams oder mit Führungskräften.

Bei der Entwicklung von Jira Product Discovery nutzte unser Team diesen Ansatz, um Ideen auszuarbeiten, zu validieren und umzusetzen. Wir erklären für jede Phase des Lebenszyklus, wie unser Team sie in die Praxis umgesetzt hat.

Überlegen, Erkunden, Machen, Resultat

Überlegen, Erkunden, Machen, Resultat

Bevor dieser Lebenszyklus losgeht, beginnt jede Idee auf dem "Parkplatz". In dieser Phase besteht sie normalerweise nur aus einzeiligen Zusammenfassungen mit einem Einblick, der zu ihrer Erstellung geführt hat. Diese Einblicke können aus einem Workshop, einem Forschungsbericht oder einem Kundengespräch stammen oder von einem Vertriebs- oder Supportmitarbeiter bereitgestellt werden.

Sobald eine Idee aktiv bearbeitet wird, folgt sie den vier Phasen:

  • Überlegen: Die Probleme oder Chancen besprechen, die die Idee lösen bzw. bieten könnte, auf wen sie sich auswirken und welche Bedeutung sie haben.
  • Erkunden: Potenzielle Lösungen ausdenken, bis eine davon durch Kundenfeedback bestätigt wird.
  • Machen: Die Lösung entwickeln und iterieren, bis sie die Anforderungen einer ausreichenden Anzahl von Kunden erfüllt.
  • Resultat: Die Lösung einführen, die Ergebnisse messen und kontinuierliche Verbesserungen vornehmen, bis das gewünschte Ergebnis erreicht wird.
Ideenphasen für das Sirius-Team in Jira Product Discovery

Ideenphasen für das Sirius-Team in Jira Product Discovery

Ideenphasen für alle Teams in Jira Product Discovery

Eine Board-Ansicht von Ideen in verschiedenen Phasen im Jira Product Discovery-Team

Dies ist kein Wasserfallmodell – diese Phasen sind nicht zwingend linear. Zum Beispiel kommt es sehr häufig vor, dass eine Idee aus der Erkunden-Phase wieder in die Überlegen-Phase zurückkehrt, wenn wir durch das Testen von Lösungen mehr über das Problem erfahren. Außerdem kann man davon ausgehen, dass einige Ideen aufgegeben werden, wenn nach ein paar Versuchen keine passende Lösung gefunden wurde.

In den folgenden Abschnitten veranschaulichen wir jede Phase, indem wir zeigen, wie unser Team sie bei der Entwicklung von Jira Product Discovery befolgt hat.

Noch mehr Details zu diesem Prozess erhältst du in diesem Vortrag:


Fragen

In der Überlegen-Phase geht es darum, ein Problem oder eine Chance zu validieren.

In dieser Phase führst du normalerweise qualitative Interviews mit Kunden durch. Aus dieser Recherche leitet dein Team die Vorteile und Ergebnisse ab, die mit der Idee erzielt werden sollen, gemessen am Wert für die Kunden und das Unternehmen. Außerdem stellt dein Team eine Hypothese dazu auf, wie der Erfolg gemessen werden kann.

Für Ideen in dieser Phase kannst du die Jira Product Discovery-Vorlage "Problemdefinition" verwenden oder deine eigene erstellen.

Vorlage "Problemdefinition" in Jira Product Discovery

Vorlage "Problemdefinition" in Jira Product Discovery

Halte Erkenntnisse aus Recherchen und Kundengesprächen in den Phasen "Überlegen", "Erkunden", "Machen" und "Resultat" im Bereich für Einblicke der jeweiligen Idee fest:

Der Bereich "Einblicke" für eine Idee in Jira Product Discovery

Der Bereich "Einblicke" für eine Idee in Jira Product Discovery

Überlegen-Phase in Aktion

So sah die Überlegen-Phase aus, als wir Jira Product Discovery entwickelten. Die ursprüngliche Idee für dieses Produkt stammte aus:

Interviews mit Produktmanagern, die Jira für die Softwarebereitstellung verwenden;

Analysen von Recherchen vom Research & Insights-Team bei Atlassian und von Analystenfirmen wie Gartner und Forrester;

Beispielen für Best Practices in der Produktentwicklung, z. B. Marty Cagans Blogs und Teresa Torres' Buch.

Diese Einblicke gaben uns folgende Überzeugungen:

  1. Die PMs hatten mehrere Probleme, von der effektiven Priorisierung bis hin zur Annahme ihrer Roadmaps durch die Mitarbeiter.
  2. Die PMs versuchten diese Probleme mit Jira zu lösen, waren dabei aber nur mäßig erfolgreich, weil Jira nicht für diesen Zweck konzipiert ist.
  3. Die PMs kamen bei der Umsetzung ins Stocken, da sie sich auf Ergebnisse wie die Bereitstellung von Funktionen konzentrierten, statt die Ideenfindung in den Mittelpunkt zu rücken und Resultate zu liefern.
  4. Das Produktmanagement wurde zu einer Schlüsselfunktion, nicht nur für Technologieunternehmen. Daher sahen wir darin eine große Chance und waren überzeugt, dass es eine starke Nachfrage nach einer Lösung geben würde.
Unsere Landingpage für Jira Product Discovery

Unsere Landingpage für Jira Product Discovery

Ein besonderes Augenmerk lag für uns darauf, unsere Hypothese zur Nachfrage zu bestätigen, da dies unsere riskanteste Annahme war. Wenn wir damit falsch lägen, würden wir ein Produkt entwickeln, das nur wenige Unternehmen kaufen würden.

Bevor wir also eine einzige Zeile Code schrieben, erstellten wir eine Webseite, um für das Produkt zu werben.

Die Ergebnisse bestätigten unsere Hypothese: Innerhalb von vierzehn Tagen hatten sich 3.000 Personen auf der Warteliste eingetragen.


Erkunden

In der Erkunden-Phase konzipieren, testen und validieren wir Lösungen für die in der Überlegen-Phase identifizierten Probleme oder Chancen.

Viele Produktideen scheitern – das ist einfach ein Teil des Prozesses. Um diese weniger aussichtsreichen Ideen früher zu erkennen und Platz für gute Ideen zu machen, sollten sich Produktmanager laut Marty Cagan mit vier Hauptrisiken befassen. Beachte diese Risiken, wenn du mögliche Lösungen für die Probleme und Chancen evaluierst, die du identifiziert hast.

  1. Ist die Lösung für Kunden nützlich? Wenn nicht – zum Beispiel weil sie bereits Zugang zu besseren Alternativen haben – riskierst du, dass deine Lösung nicht verwendet wird.
  2. Ist die Lösung nutzbar und intuitiv? Damit Benutzer von der Lösung profitieren können, muss sie einfach zu verwenden und zugänglich sein. Wenn die Hürde für die Wertschöpfung zu hoch ist, riskierst du, eine Funktion einzuführen, die wenig genutzt wird.
  3. Ist diese Lösung technisch machbar? Egal, wie vielversprechend eine Idee ist, müssen deine Engineers über die Fähigkeiten und Technologien verfügen, um sie erfolgreich umzusetzen. Andernfalls riskierst du, unnötig Ressourcen zu verschwenden.
  4. Ist die Lösung mit den Ressourcen und Auflagen des Unternehmens realisierbar? Es wird wahrscheinlich verschiedene Iterationen erfordern, bis deine Lösung perfekt ist. Du solltest sicherstellen, dass das Unternehmen bereit ist, zu investieren. Andernfalls riskierst du, Zeit für eine Idee aufzuwenden, die später verworfen wird.

Das Ziel deines Teams ist es, die Risiken so effizient wie möglich zu minimieren und zu vermeiden, dass du aufgrund eines Bauchgefühls zu viel investierst oder dich an einer Lösung festklammerst. Das kann passieren, wenn eine Funktion ausgeliefert und dann iteriert oder untersucht wird, was sie leistet. Nutze stattdessen Lower-Lift-Techniken wie das Erstellen von Prototypen in Figma und zeige sie den Kunden, um frühzeitig Feedback zu erhalten, bevor du mit dem Programmieren anfängst.

Wenn du eine Funktion ausliefern möchtest, versuche, einen Live-Prototyp mit vielen Einschränkungen zu erstellen, ihn mit einer kleinen Gruppe von frühen Anwendern zu testen und schnell zu iterieren. Auf diese Weise musst du nicht alle Ausnahmefälle berücksichtigen. Wenn die Idee für sie nicht funktioniert, erfährst du die Gründe dafür viel schneller, und du kannst so lange Iterationen vornehmen, bis es klappt. Oder du verwirfst die Idee ganz, wenn sie nicht ankommt.

Wenn du große Unsicherheitsbereiche hast, führe im Rahmen der Explore-Phase einen technischen Spike durch. Diese Art der Implementierung soll dir helfen, die Einschränkungen deines Teams zu verstehen sowie nachzuvollziehen, was technisch machbar ist und welche Bereiche technisch komplex sind.

Für Ideen in dieser Phase kannst du die Jira Product Discovery-Vorlage "Problemdefinition" verwenden oder deine eigene Vorlage erstellen.

Vorlage "Problemdefinition" in Jira Product Discovery

Vorlage "Problemdefinition" in Jira Product Discovery

Verknüpfe in deinem Produkt-Backlog alle Dokumente, Spezifikationen und Designs, die sich auf jede Idee beziehen, sodass du sie immer zur Hand hast, wenn du die Idee mit deinem Team und den Stakeholdern besprichst. Wir empfehlen, für jede Idee Hyperlink-Felder zu erstellen, um den Überblick über jedes Asset (Einseiter, Design) zu behalten.

Eine Confluence-Seite, die als Einseiter in einer Idee verwendet wird

Hier findest du ein Video dazu, wie du dabei vorgehst:

Explore in Aktion

Für die Entwicklung von Jira Product Discovery haben wir die folgenden Techniken verwendet, um unsere Lösungen mit Kunden zu validieren:

Eine Folie, die wir verwendet haben, um Jira Product Discovery mit Kunden zu validieren

Eine Folie, die wir verwendet haben, um Jira Product Discovery mit Kunden zu validieren

Zunächst haben wir Produktmanagern Folien mit verschiedenen möglichen Lösungen gezeigt, um zu verstehen, welche am besten ankamen. Durch diese Gespräche haben wir nicht nur viel über die Probleme unserer Kunden gelernt, sondern auch darüber, worauf sie Wert legen. So wurde die "Priorisierung" zum ersten Grundpfeiler von Jira Product Discovery.

💡 Folien eignen sich hervorragend für diese Phase der Validierung, weil sie sich einfach erstellen, testen und ändern lassen.

Ein Figma-Prototyp aus einer früheren Explore-Phase

Ein Figma-Prototyp aus einer früheren Explore-Phase

Als Nächstes haben wir Prototypen in Figma erstellt, sie den Benutzern gezeigt und gefragt, wie die Lösungen ihnen helfen würden. Der erste Test-Prototyp war eine Lösung, mit der Produktmanager das Feedback der Stakeholder besser nutzen können sollten, um Prioritäten zu setzen.

Obwohl Interesse bestand, waren die Produktmanager der Meinung, dass die Einrichtung zu viel Aufwand erfordert, bevor sie einen Nutzen daraus ziehen könnten. Also haben wir die Idee verworfen.

Der erfolgreiche Figma-Prototyp für Jira Product Discovery

Der erfolgreiche Figma-Prototyp für Jira Product Discovery

Nachdem wir mehrmals Feedbacks gesammelt hatten, untersuchten wir die Lösung, die zu dem werden sollte, was Jira Product Discovery heute ist: ein kollaborativer Bereich, in dem Produktideen diskutiert werden können.

In dieser Phase haben sich die Gespräche mit Benutzern drastisch geändert. Viele fragten, wann sie Zugang bekommen könnten, da ihnen das Tool sehr helfen würde. Da wussten wir, dass wir auf dem richtigen Weg sind.

Nachdem wir mehrmals Feedbacks gesammelt hatten, untersuchten wir die Lösung, die zu dem werden sollte, was Jira Product Discovery heute ist: ein kollaborativer Bereich, in dem Produktideen diskutiert werden können.

In dieser Phase haben sich die Gespräche mit Benutzern drastisch geändert. Viele fragten, wann sie Zugang bekommen könnten, da ihnen das Tool sehr helfen würde. Da wussten wir, dass wir auf dem richtigen Weg sind.

Make

In der Make-Phase erstellen und validieren Teams die Lösungen, auf die sie sich in der Explore-Phase geeinigt haben. Das ist der Zeitpunkt, zu dem der Großteil der Entwicklungsarbeit stattfindet.

Das Ergebnis dieser Phase ist eine funktionierende Software, etwa ein neues Produkt, eine neue Funktion oder Verbesserungen eines bestehenden Erlebnisses. Diese kann nachweislich die erwarteten Ergebnisse liefern, nachdem sie von genügend Kunden übernommen wurde, und ist für alle Kunden einsatzbereit.

Wenn die Umsetzung startet, entweder in dieser Phase oder während der Explore-Phase, verknüpfst du die Idee mit Umsetzungstickets in Jira (wir empfehlen die Epic-Ebene oder höher). Verfolge den Umsetzungsfortschritt in Jira Product Discovery und erhalte einen Gesamtüberblick über den Fortschritt aller Produktinitiativen und Teams.

Die Beziehung zwischen einer Idee und der Umsetzung in Jira

Die Beziehung zwischen einer Idee und der Umsetzung in Jira

Wenn mehrere Teams an der Umsetzung einer Idee beteiligt sind und sie an verschiedenen Jira-Projekten arbeiten, kannst du all ihre Umsetzungstickets mit der Idee in deinem Produkt-Backlog verknüpfen.

Eine Idee, die von drei verschiedenen Jira-Teams umgesetzt wurde

Eine Idee, die von drei verschiedenen Jira-Teams umgesetzt wurde

Du kannst dann den Stand der Umsetzung von JPD aus verfolgen und dir einen Gesamtüberblick über den Fortschritt aller Produktinitiativen und Teams verschaffen.

Dashboard für Produktaufgaben in Bearbeitung

Dashboard für Produktaufgaben in Bearbeitung

Weitere Informationen findest du in unserem Webinar "Ideenfindung und Umsetzung in Jira verbinden" im Abschnitt Ressourcen.

Denke daran, dass es sehr unwahrscheinlich ist, dass die Lösung sofort die erwarteten Ergebnisse liefert. Liefere stattdessen frühzeitig und häufig an Kunden aus und nimm so lange Iterationen vor, bis das Ergebnis gut genug ist. Füge der Idee immer wieder Einblicke aus Kundengesprächen hinzu, in denen du dazugelernt hast. Wie du den Erfolg misst, hängt von der Art der Idee ab, etwa zu einer neuen Funktion, einer Wachstumsinitiative usw. Stelle sicher, dass alle darüber Bescheid wissen und in deinen Plänen Iterationen berücksichtigt werden.

Make in Aktion

Als wir Jira Product Discovery entwickelten und wichtige neue Funktionen zum Produkt hinzufügten, haben wir die Ideen an immer größeren Kundengruppen getestet und validiert. In einigen Fällen dauerte dieser Vorgang ein paar Wochen, in anderen ein paar Monate.

0 → 10 Kunden
Nutzen nachweisen

Während der ErkundungspPhase haben wir mit einer kleinen Anzahl von vorab ausgewählten Kunden Iterationen durchgeführt. Wir haben sehr eng mit diesen Kunden zusammengearbeitet, um die Lösung gemeinsam zu entwickeln. Die Iterationen wurden so lange durchgeführt, bis wir von den Kunden die Bestätigung erhielten, dass das vorliegende Problem mithilfe der Lösung behoben werden konnte.

Zu diesem Zeitpunkt hat sich die Lösung bewährt, sie ist aber noch lange nicht ausgereift und berücksichtigt keine Ausnahmefälle.

10 → 100 Kunden
Funktion ausgereift machen

Wir haben dann schrittweise mehr Kunden Zugang gewährt. Dadurch konnten wir verschiedene Szenarien identifizieren, die wir anfangs nicht in Betracht gezogen hätten. Wir iterierten so lange, bis wir 100 aktive Kunden hatten, die die Lösung nutzten.

Zu diesem Zeitpunkt ist die Lösung normalerweise mit allen Funktionen ausgestattet. Aber sie ist vielleicht nicht auffindbar und in Eigenregie ausführbar. Benutzer müssen möglicherweise ein Video-Tutorial ansehen, um zu verstehen, wie sie die Lösung richtig nutzen.

100 → 1000 Kunden
Self-Service-fähig machen

Dann haben wir mehr Kunden (bis zu 1000) Zugang gewährt. Wir schauten uns die Nutzungszahlen aus Produktanalysen, Support-Tickets und eingehendes Feedback an. Basierend auf den Ergebnissen haben wir die Benutzeroberfläche verbessert oder Fehler behoben. Wenn die Nutzungszahlen zu niedrig waren, um einen Nutzen zu bringen, betrachteten wir die Auffindbarkeit der Funktion.

Zu diesem Zeitpunkt sollte die Funktion in Eigenregie anwendbar sein, d. h. sie ist auffindbar, die Benutzererfahrung ist gut genug, die Dokumentation ist fertig usw.

Allgemeine Verfügbarkeit
Betriebsbereit machen

Schließlich haben wir das Support Enablement, das Sales Enablement, operative Dashboards, Leistungs- und Skalierbarkeitsverbesserungen startklar gemacht.

Zu diesem Zeitpunkt sollte die Lösung für den großen Auftritt bereit sein.

Wenn wir an solchen Lösungen arbeiten, gestalten wir sie normalerweise auf einer separaten Confluence-Seite, die wir "Live-Feature-Dokument" nennen. Das ist eine äußerst übersichtliche Seite, die wir jedes Mal öffnen, wenn wir uns als Team treffen, um den Umfang der aktuellen Iteration zu besprechen. Wir aktualisieren dieses Dokument regelmäßig, nachdem wir weitere Informationen darüber erhalten haben, welche Auslieferungen einfach oder schwierig sind. Es konzentriert sich nicht auf einzelne Aufgaben, sondern auf das die Nutzung des Produkts. Darüber sollen sich alle, von der Produkt- über die Design- bis hin zur Engineering-Abteilung, im Klaren sein.

Live-Feature-Dokument in Jira Product Discovery

Live-Feature-Dokument in Jira Product Discovery

Auswirkungen

Im Produktmodell dreht sich vom Anfang bis zum Ende alles um Ergebnisse. Die Teams priorisieren Ideen, damit sie Ergebnisse erzielen können, und nach der Umsetzung überwachen sie die Fortschritte bei der Erreichung dieser Ergebnisse weiter. Auf dieser Basis werden deine Ziele und Strategien neu gesetzt bzw. erstellt und deine nächsten Schritte priorisiert.

Selbst nachdem eine Lösung ausgeliefert wurde, ist sie nie wirklich "fertig": Sobald du eine Funktion einführst, ist sie Teil deines Produkts. Du musst sie kontinuierlich verbessern, um sicherzustellen, dass sie für die Benutzer einen Mehrwert bietet und weder verwirrend noch schwer zu benutzen ist. Behalte unbedingt im Auge, wonach Kunden fragen, was sie über neue Funktionen sagen und wie oft diese in Support-Tickets angesprochen werden.

Resultat-Phase in Aktion

Im Jira Product Discovery-Team machen wir das mit monatlichen und vierteljährlichen Bewertungen, in denen wir das Resultat mit dem vergleichen, was wir uns vorgenommen haben. Manchmal sind wir mit den Ergebnissen zufrieden und ändern kaum etwas, ein anderes Mal ändern wir die Roadmap, um etwas neues auszuprobieren.

Hier ist eine Technik, die wir verwenden: Nachdem wir eine Lösung geliefert haben, erstellen wir eine Verbesserungsidee, in der wir Einblicke sammeln, darunter:

  • Eingehendes Feedback von Benutzern.
  • Durch Feedback, Umfragen und Interviews erhaltene Signale dafür, dass das Feature die Probleme, für die es entwickelt wurde, löst oder nicht.
  • Nutzungsdaten aus Produktanalysen, um zu verstehen, ob die Lösung tatsächlich verwendet wird. Wenn nicht, könnte es Probleme mit der Auffindbarkeit geben oder einfach weniger Begeisterung für das geplante Feature.
Ansicht zum Nachverfolgen von Kundenfeedback zu bereits gelieferten Ideen in Jira Product Discovery

Ansicht zum Nachverfolgen von Kundenfeedback zu bereits gelieferten Ideen in Jira Product Discovery.

Wir schauen uns diese Daten regelmäßig an und jedes Team weist ein Budget für Feature-Verbesserungen zu. Sowohl neue Ideen als auch Verbesserungen an bestehenden Ideen erscheinen auf der Roadmap jedes Teams:

Verbesserungen auf der Roadmap eines Teams in Jira Product Discovery

Der Fortschritt einer Idee

Jira Product Discovery bietet eine Reihe von Feldern, um den Status der Umsetzungstickets für eine Idee anzuzeigen. Wir glauben jedoch nicht, dass dies unbedingt der beste Weg ist, um Stakeholdern Fortschritte mitzuteilen. Ob die Tasks eines Epics zu 60 % oder 80 % erledigt sind, sagt nichts darüber aus, wie viel Fortschritt das Team wirklich macht.

Hier ist eine wirkungsvollere Methode, Stakeholder über Fortschritte zu informieren: Markiere jede Idee über ein Feld als "on track" (planmäßig), "at risk" (gefährdet) oder "off track" (nicht planmäßig) und schreibe einen Kommentar dazu (in der Beschreibung der Idee). Dieses sehr einfache Prinzip der Zusammenarbeit ist sehr effektiv, um Stakeholdern mitzuteilen, an welcher Stelle du Hilfe benötigst.

Ansicht der Kommunikation bezüglich Fortschritten an Stakeholder in Jira Product Discovery

Ansicht der Kommunikation bezüglich Fortschritten an Stakeholder in Jira Product Discovery.

Weitere Details zu einer Idee in der Fortschrittsansicht

Weitere Details zu einer Idee in der Fortschrittsansicht.

Wenn du Atlas-Kunde bist, kennst du diesen Ansatz bereits. Sieh dir im Abschnitt Ressourcen das Video an, wie du Jira Product Discovery-Ideen mit Atlas-Projekten verbinden kannst. Dort erhältst du bessere und genauere Informationen als in der Ansicht unten, in der Fortschritt als Prozentsatz der gelieferten Jira-Tickets gemessen wird:

Eine Jira Product Discovery-Ansicht, die den Fortschritt als in Jira gelieferte Tickets anzeigt

Eine Jira Product Discovery-Ansicht, die den Fortschritt als in Jira gelieferte Tickets anzeigt.

Weitere Details zu einer Idee in der Ticket-basierten Fortschrittsansicht

Weitere Details zu einer Idee in der Ticket-basierten Fortschrittsansicht.


Was kommt als Nächstes?

Produktteams, die Ideen als Mittel nutzen, um Lösungen von der Ideenfindung über die Validierung bis zur Umsetzung zu bringen, können ihre Mitglieder besser organisieren und sich voll auf die Zielerreichung konzentrieren.

Im restlichen Teil dieses Handbuchs erklären wir im Detail, wie ein Produkt-Backlog für Folgendes verwendet wird:

Wir geben dir Beispiele dafür, wie wir das im Jira Product Discovery-Team mit Jira Product Discovery und anderen Produkten machen.

Produkt-Backlog

Verwalte Produkt-Backlogs effektiv, um Ideen zu priorisieren, die Zusammenarbeit zu verbessern und die Produktentwicklung voranzutreiben.

Feedback und Einblicke

Erfahre, wie die Einbeziehung von Einblicken in deinen Produktentwicklungsprozess die Entscheidungsfindung verbessern, die Abstimmung auf die Kundenbedürfnisse optimieren und zu erfolgreichen Ergebnissen führen kann.