Priorisierung von Ideen für eine effektive Produktentwicklung
Effektives Setzen von Prioritäten gehört zu den wichtigsten Kompetenzen eines Produktmanagers. Effektive Priorisierung ist eine Superkraft erfolgreicher Produktteams, die es ihnen ermöglicht, schnell zu handeln und sich auf die wichtigsten Aktivitäten zu konzentrieren.
Allerdings ist die Priorisierung selten eindeutig oder einfach. Produktmanager müssen bewusst vorgehen und sorgfältige Ermessensentscheidungen fällen. Dabei müssen sie widersprüchliche Prioritäten und Überlegungen wie unmittelbare Geschäftsanforderungen, langfristige Strategien, Kundenwünsche, Wettbewerb und sich ändernde Marktbedingungen abwägen.
Wenn die Priorisierung nicht erkenntnisbasiert und nicht mit Ergebnissen verknüpft ist, kann es sehr unangenehm werden. Diskussionen münden in Konflikte, es gibt keine klare Möglichkeit, einen Konsens zu erreichen, und Entscheidungen werden nach Bauchgefühl getroffen oder richten sich nach den am lautesten geäußerten Meinungen.
RUF: Zuverlässigkeit, Benutzerfreundlichkeit, neue Funktionen
Wir empfehlen, gleichmäßig in neue Produktfunktionen, die Verbesserung des aktuellen Produkts und die Stärkung der technischen Grundlagen für eine hohe Zuverlässigkeit zu investieren.
Ein Framework, das viele Teams bei Atlassian dazu verwenden, heißt RUF:
RUF = Zuverlässigkeit + Verbesserung der Benutzerfreundlichkeit + neue Funktionen (Reliability + Usability improvements + new Features)
Du kannst dir das Framework als Pyramide vorstellen:
| Zuverlässigkeit | The first thing users expect from your app is that whenever they open it, and it just works. |
| Usability improvements | The longer you’ve worked on a product, the more features it likely has. Feature bloat is the silent killer of many apps. |
| New Features + Ideas | With a strong foundation in place, you can add new features. Everyone knows what we’re talking about here 😉 |
The 3 Bucket Planning Guide for prioritizing new ideas
Even when it comes to new product ideas, take a balanced approach to set your product up for success.
🛑 You can’t just build whatever features customers ask for, as you risk only helping your current user base.
🛑 You can’t only focus on improving key business metrics like revenue growth, as you might ignore important customer needs.
🛑 You can’t only ship new revolutionary ideas either, or you put reliability and usability at risk
Adam Nash, former VP product and growth at Dropbox, suggested looking at 3 buckets (source: “the 3 bucket planning guide”):
A view of 3 bucket feature planning in Jira Product Discovery
- Metrics Movers are product initiatives that directly contribute to business goals by improving key metrics: sign-ups, conversion, retention, active users, referrals, revenue, etc. Growth initiatives typically fall in this category.
- Customer Requests are what customers ask for, both net-new features and improvements to current experiences. Addressing these helps keep customers happy, reduce support load, and ensure that your product nails its key jobs.
- Delighters are where your product innovates. These are the features your customers didn’t know they wanted, but can improve their lives by changing how they work. Delighters differentiate you from competition and build a moat around your product.
Allocating budget across investments
It’s important to be intentional in how you invest in each of these buckets. Otherwise, your velocity might drop because your team spends 80% of their time fixing bugs, or the growth of your product slows down, because you’re not thinking strategically. Shipping as many new features as possible is unlikely to fix that.
The right budget allocation for each bucket depends on many things, but in particular the stage of your product: pre-PMF (Product Market Fit), post-PMF, or mature product.
In practice, budget allocation could look like this:
| | Pre-PMF | Post-PMF | Mature |
|---|---|---|---|
| Zuverlässigkeit | Pre-PMF 10 % | Post-PMF 30 % | Mature 50 % |
| Usability improvements | Pre-PMF 20 % | Post-PMF 20 % | Mature 20 % |
| Customer requests and delighters | Pre-PMF 70 % | Post-PMF 30 % | Mature 10 % |
| Growth initiatives | Pre-PMF
| Post-PMF 20 % | Mature 20 % |
Remember, this should never be set in stone. For example, you might decide to invest more in new features for a few months, then go back and focus on UX improvements or addressing technical debt.
But as you allocate and re-allocate, it’s important to keep in mind the different aspects that are required to make your product successful, and to balance your investments over time.
There are different ways to manage these investments: you can have teams dedicated to one or the other bucket, you can make sure that each team has one initiative from each bucket at each time, or you can have each team pick work from each of the buckets in a round-robin fashion. There are pros and cons to each approach but it’s a lot more about delivery planning so we won’t cover them here.
Balancing investments at Jira Product Discovery
Here’s how we configured our investment allocation on the Jira Product Discovery team over a six-month period.
Investments across all squads
We have 4 main themes: pricing and packaging, growth, jobs-to-be-done and engineering initiatives. In each of these themes, we have a number of bets.
These bets are distributed amongst the JPD teams: 5 product squads and 1 engineering squad (Sirius, Horizon, Aurora, Juno, Pulsar, X-flow).
Product squads
Each product squad is required to allocate their time with the following split:
- 60% on product initiatives. For this they create a roadmap with two sections: one for new features, and one for improvements to the current product experience.
- 20% on RtB - Run the Business: on-call, bugs, etc.
- 20% on fixing tech debt
While we don’t strictly enforce this allocation, each team discusses keeping this balance during their sprint planning and monthly reviews. Typically, it does hold true over time.
For product initiatives, we keep a watch on feedback we receive from users and discuss every week with all product managers. We separate the feedback into “Boulders,” XL investments, and “Rocks,” large investments.
We have a separate list for “Pebbles,” small improvements fixing “paper cuts” in the UX. These are difficult to prioritize since you can’t compare their impact to L and XL investments. But, their impact compounds over time. The expectation is that each squad has one Pebble fix in progress at any point in time.
Engineering squads
Each engineering squad has a similar split. But instead of product initiatives they focus on pure engineering projects to improve system resilience and scale.
Setting the stage for productive prioritization discussions
There are many people at your company who have insights into business and customer needs your product should help with.
If you can harness this collective knowledge, you can build more confidence in your product decisions and mitigate the risk of making the wrong bets.
But this is easier said than done. We’ve heard of product teams being swamped with asks from leadership and sales teams, then constantly interrupted with requests for updates: “when is my request going to ship?”
Done right, you can get a lot of value from turning prioritization into a team sport. A collaborative prioritization process creates clarity of mission, vision and purpose, getting teams across the business working towards shared goals.
Here are a few principles to follow for productive, collaborative prioritization.
Festlegung klarer Erwartungen
Setting expectations is crucial for everyone to collaborate effectively. People must understand what prioritization actually entails, and how they should contribute.
Here are a few key ingredients:
- Everyone’s roles and responsibilities in the conversation
- Shared goals and ways to measure success
- Designated vocabulary and framework for prioritizing
- Established communication channels and feedback loops
Rollen und Zuständigkeiten zuweisen
For prioritization to be a positive experience for everyone, you want to make it clear how they should contribute.
To help with this, we designed Jira Product Discovery around 3 roles: creators, contributors and stakeholders.
Where creators, contributors, and stakeholders fit into the prioritization process.
Rolle | Who they are | Zuständigkeiten |
|---|---|---|
| Ersteller | Who they are The core product team across product, engineering, design, research. | Zuständigkeiten Drive the product, the prioritization process, and the ideas from beginning to end. |
| Beitragende | Who they are Points of contact within the sales, support, customer success, marketing and other field teams. | Zuständigkeiten Participate in the prioritization process and provide key insights: customer requests, support problems, etc. |
| Stakeholder | Who they are The rest of the company, typically separated in 2 roles: leadership, and everyone else. | Zuständigkeiten Need visibility on priorities, progress and decisions and ways to provide feedback. |
Review priorities continuously for incremental improvement
Ein ineffektiver, aber dennoch gängiger Rhythmus für das Setzen von Prioritäten ist ein- oder zweimal im Jahr – das ist der "Urknall"-Ansatz.
Dieser Ansatz kann nicht funktionieren, weil die Teams damit nicht auf volatile Einflussfaktoren reagieren können. Dein Produkt muss fortlaufend an Marktbedingungen, Erkenntnisse aus Kundengesprächen, unerwartet komplexe Implementierungen usw. angepasst werden.
Die Prioritätensetzung nach dem "Urknall"-Prinzip führt zu Diskussionen, bei denen jede Entscheidung enorme Auswirkungen hat. Es entstehen Druck und Erwartungen, was zu spannungsgeladenen Auseinandersetzungen um die Prioritätensetzung führen kann. Die Sorge kann entstehen, dass Ressourcen der falschen Sache verbindlich zugewiesen werden und dass man monatelang an die Ergebnisse dieser Entscheidung gebunden sein wird.
Besser, du führst stattdessen regelmäßigere Diskussionen zur Prioritätensetzung mit deinen Teams und Stakeholdern – mindestens einmal alle vierzehn Tage oder einmal im Monat. Idealerweise spricht man jede Woche ein bisschen darüber: Was haben wir gelernt? Ändert sich etwas, basierend auf dem, worauf man sich gerade konzentriert?
Richte das Produkt-Backlog auf diese Diskussionen aus
Damit sich jeder über seine Rollen im Klaren ist und Entscheidungen zuverlässig umgesetzt werden, empfehlen wir, das Produkt-Backlog wie folgt zu konfigurieren:
- Ersteller sind Teil des Jira Product Discovery-Projekts. Sie legen die Konfiguration fest (Felder, Ansichten usw.) und erstellen und verwalten Ideen, Ansichten und Erkenntnisse.
- Beitragende werden dem Projekt hinzugefügt, allerdings mit einem begrenzen Funktionsumfang für die Zusammenarbeit. Sie können abstimmen und Einblicke, Kommentare und Reaktionen hinzufügen.
- Stakeholder werden dem Projekt nicht hinzugefügt. Stattdessen veröffentlichen Ersteller schreibgeschützte Ansichten, die sie mit ihnen teilen.
Wir empfehlen separate Ansichten für jede Zielgruppe:
In Jira Product Discovery gibt es drei Ansichten für verschiedene Rollen
Die rollenspezifischen Ansichten stellen sicher, dass jede Gruppe die benötigten Informationen auf eine für sie relevante Weise erhält. So wird sofort klar, wie das Produktteam Prioritäten setzt, welche Ideen besprochen werden und wie man dazu beitragen kann. Wenn eine Gruppe anderer Meinung ist, gibt es Kanäle, um dies auf produktive Weise mitzuteilen.
Dieser Ansatz hilft jeder Zielgruppe, sich effektiv einzubringen und verbessert die Zusammenarbeit und Abstimmung auf allen Ebenen.
Techniken für die kollaborative Priorisierung in Jira Product Discovery
Sobald sich alle über die Bedingungen im Klaren sind, wird die Priorisierung zu einem gemeinsamen, transparenten Prozess. Dann können die tatsächlichen Diskussionen losgehen.
Dein Produkt-Backlog in Jira Product Discovery ist der perfekte Ort, um die Priorisierung in eine gemeinsame Übung zu verwandeln. In diesem Abschnitt stellen wir verschiedene Möglichkeiten vor, um das Produkt-Backlog so zu konfigurieren, dass es diese Gespräche unterstützt.
Viele dieser Methoden verwenden Zahlen, wie Bewertungen von 1 bis 5. Diese sind von Natur aus subjektiv – der wichtige Teil ist das "Warum" hinter einer Zahl. Jeder muss sie auf dieselbe Weise verstehen, damit man leichter über die relative Priorität jeder Idee diskutieren kann. Zum Beispiel müssen sich alle darüber einig sein, was als "hoher Aufwand" oder "geringe Auswirkung" angesehen wird.
Das 10-Dollar-Spiel fördert das Denken innerhalb von Grenzen
Mit dem 10-Dollar-Spiel kann man Teilnehmer auf ansprechende Weise dazu bringen, die Wichtigkeit einer Idee zu bewerten und dabei Einschränkungen zu berücksichtigen.
Angesichts unbegrenzter Zeit und Ressourcen könnte das Produktteam alles machen. Aber in Wirklichkeit ist beides begrenzt. Hier beginnt das 10-Dollar-Spiel. Bei dieser Übung muss man wie ein Produktmanager denken und die Spieler bekommen ein Gefühl dafür, wie schwer dieser Job ist.
Das 10-Dollar-Spiel in Jira Product Discovery
Die Regeln sind einfach: Jeder Teilnehmer erhält ein Budget von 10 $, das er für Ideen "ausgeben" kann, die ihm am wichtigsten erscheinen. Die Teilnehmer können so viel auf eine Idee setzen, wie sie wollen, zum Beispiel 5 $ auf 2 Ideen oder 3 $ auf 3 Ideen. Natürlich kann man auch ein anderes Budget als 10 $ festlegen.
Dann erklären die Teilnehmer die Gründe für ihre Entscheidungen. Warum hielten sie bestimmte Ideen für wichtig oder vielversprechend? Dieser Ansatz fördert eine aktive Teilnahme und Diskussion und stellt sicher, dass die Meinung aller berücksichtigt wird.
Versuche, das 10-Dollar-Spiel zu Beginn eines Priorisierungszyklus durchzuführen, um zu herauszufinden, wo sich alle gerade befinden. Oder warte bis zum Ende, um zu sehen, ob alle auf einer Linie sind.
Nutze die Aufwand-Wirkung-Matrix in Gesprächen zwischen Produkt- und Entwicklungsteams
Die Aufwand-Wirkung-Matrix priorisiert Ideen sowohl auf der Grundlage ihrer potenziellen Auswirkungen auf das Geschäft als auch dem Aufwand, der für die Umsetzung nötig ist.
Diese Matrix ist eine einfache, aber leistungsstarke Methode, um Gespräche zwischen Produktmanagern und Entwicklern zu strukturieren.
Entwickler sind eingeladen, ihre Sichtweise auf die Komplexität der Lieferung zu teilen. So können Manager mögliche schnelle Erfolge oder große Vorhaben identifizieren und bestimmen, warum bestimmte Ideen Vorrang vor anderen haben sollten.
Aufwand-Wirkung-Matrix in Jira Product Discovery
Berücksichtige das Zuversichtslevel mit RICE (Reach, Impact, Confidence, Effort)
Das RICE-Framework verwendet vier Überlegungen, um die Priorität einer Idee festzulegen: Reach (Reichweite), Impact (Wirkung), Confidence (Zuversicht) und Effort (Aufwand). Es ist ein beliebtes Produktmanagement-Tool, weil es diese wichtigen Faktoren so darstellt, dass die meisten Stakeholder sie verstehen können.
Die meisten Beitragenden sind es gewohnt, die für die Umsetzung einer Idee nötige Wirkung, Reichweite und den Aufwand zu bewerten. Das RICE-Framework hat aber auch den Vorteil, dass es Zuversicht ins Gespräch bringt.
Ist das Produktteam zuversichtlich, dass diese Idee eine gute Investition ist? Oder benötigt es weitere Recherchen und Produkt- oder technische Validierungen, um sicherzugehen?
So kann ein Team erklären, warum eine Idee beschlossene Sache ist oder warum sie möglicherweise noch genauer untersucht werden sollte.
Bitte Teams mit Kundenkontakt, Kunden bei Ideen zu markieren, die ihren Bedürfnissen entsprechen.
Viele Teams, die Jira Product Discovery verwenden, haben diesen Ansatz übernommen: Sie konfigurieren eine Ansicht mit einer Liste von Ideen, die mit den Teams mit Kundenkontakt geteilt wird.
Äußern Kunden Bedürfnisse, die für eine der Ideen relevant sind, markiert sie der Vertriebs-/Support-Mitarbeiter auf der Idee. So kann jede Idee anhand der Anzahl der markierten Kunden bewertet werden.
Fallen Kunden in Segmente von unterschiedlicher Bedeutung, möchten Produkt- und Kundenteams möglicherweise verschiedenen Kunden unterschiedliche Gewichtungen zuweisen. Im Beispiel unten sind die Kunden in Enterprise, SMB und Start-up unterteilt.
Diese einfache und doch effektive Methode ermöglicht produktive Gespräche zwischen Produkt- und Kundenteams.
Verwendung von Gewichtungen für Kundensegmente auf der Grundlage der Unternehmensziele
Wichtigen Kunden eine Gewichtung zur Priorisierung zuweisen
Es geht auch aufwendiger (aber das ist vielleicht nicht ratsam)
Es gibt noch viele weitere Methoden, mit denen Teams Prioritäten besprechen können.
Es ist wirklich ganz deine Entscheidung, welche Methode für deine Bedürfnisse die richtige ist – aber im Allgemeinen finden wir, dass Gespräche umso besser sind, je einfacher die Methode ist.
Wahrscheinlich übertrieben: Weighted Shortest Job First (Gewichtung des kürzesten Jobs an erster Stelle)
Manche Teams sind besessen davon, das "richtige" Priorisierungsmodell zu finden. Aber das Framework ist nur ein Mittel zum Zweck. Es soll dir helfen, deine Ziele zu verfolgen, und nicht all deine Zeit und Aufmerksamkeit in Anspruch nehmen. Denk daran – du verwaltest dein Produkt, nicht dein Priorisierungs-Framework!
Nutze die Methode, die für dich funktioniert
Letzten Endes sind das alles nur Vorschläge. Keine zwei Jira Product Discovery-Projekte sind gleich, weil keine zwei Unternehmen oder Teams gleich sind. Kanalübergreifend dienen all diese Methoden dazu, ein ausgewogenes Bild hiervon zu liefern:
- Die Ziele des Unternehmens
- Die Wünsche potenzieller Kunden
- Die Bedürfnisse von Kunden und Benutzern
- Wie man das Support-Team entlasten kann
- Wie sich Verkaufsgespräche anstoßen lassen
- Und vieles mehr, abhängig von deinem Unternehmen und Produkt
Wir empfehlen dir, basierend auf den individuellen Bedürfnissen und Produkten deiner Teams deine eigene Kombination von Ansichten zu erstellen, damit du Prioritäten setzen kannst, wie du es möchtest. Auf dieser Grundlage kannst nur du entscheiden, was deine Prioritäten sein sollten: zu was du "Ja" sagen wirst und zu was "Nein".
Aus diesen Diskussionen geht deine Roadmap hervor.
Was kommt als Nächstes?
Priorisierung ist die einzige Möglichkeit, Entscheidungen mit den gewünschten Produktergebnissen zu verbinden. Effektive Priorisierung bedeutet starke Roadmaps, die Ressourcen verantwortungsbewusst zuweisen und die Produktteams auf Kurs halten, um Geschäftsziele zu erreichen und auf Kundenbedürfnisse einzugehen.
Jetzt sind wir bereit für den letzten Abschnitt dieses Handbuchs. Wir werden bisher Gelernte zusammenführen, um:
Erstellung von Roadmaps, an denen sich dein Team und deine Stakeholder orientieren können
Wir geben dir Beispiele dafür, wie wir das im Jira Product Discovery-Team mit Jira Product Discovery und anderen Produkten machen.
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.
Roadmapping
Erfahre, wie du wirkungsvolle Produkt-Roadmaps entwickeln kannst, die Prioritäten aufeinander abstimmen, die Kommunikation verbessern und strategische Ziele teamübergreifend unterstützen.
