Ustalanie priorytetów dla pomysłów w celu efektywnego rozwoju produktu
Efektywne ustalanie priorytetów jest jedną z najważniejszych umiejętności menedżera produktu. To supermoc skutecznych zespołów produktowych, umożliwiająca im szybkie działanie i skupianie się na aktywnościach o największym wpływie.
Jednak ustalanie priorytetów rzadko jest jednoznaczne lub proste; menedżerowie produktów muszą działać w sposób celowy i dokonywać ostrożnych osądów. Biorą oni pod uwagę sprzeczne priorytety i względy, takie jak bieżące potrzeby biznesowe, długoterminowa strategia, żądania klientów, konkurencja i zmieniające się warunki rynkowe.
Z drugiej strony, gdy ustalanie priorytetów nie jest oparte na analizach i powiązane z wynikami, może stać się koszmarem. Dyskusje przeradzają się w konflikt, brakuje jasnego sposobu na osiągnięcie konsensusu, a wybory dokonywane są w oparciu o przeczucie lub najdobitniej wygłaszane opinie.
RUF: niezawodność, użyteczność, nowe funkcje
Zalecamy inwestowanie w różne nowe funkcje produktu, doskonalenie obecnego interfejsu i wzmocnienie technicznych podstaw produktu pod kątem niezawodności.
Struktura, którą wiele zespołów firmy Atlassian wykorzystuje do równoważenia inwestycji, nazywa się RUF:
RUF = niezawodność + poprawa użyteczności + nowe funkcje
Pomyśl o strukturze RUF jako o piramidzie:
| Niezawodność | 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 |
|---|---|---|---|
| Niezawodność | 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.
Wyraźne określenie oczekiwań
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
Przypisanie ról i obowiązków
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.
Rola | Who they are | Obowiązki |
|---|---|---|
| autorów | Who they are The core product team across product, engineering, design, research. | Obowiązki Drive the product, the prioritization process, and the ideas from beginning to end. |
| Kontrybutorzy | Who they are Points of contact within the sales, support, customer success, marketing and other field teams. | Obowiązki Participate in the prioritization process and provide key insights: customer requests, support problems, etc. |
| Interesariusze | Who they are The rest of the company, typically separated in 2 roles: leadership, and everyone else. | Obowiązki Need visibility on priorities, progress and decisions and ways to provide feedback. |
Review priorities continuously for incremental improvement
Nieskuteczna, choć powszechna częstotliwość ustalania priorytetów to raz lub dwa razy w roku — metoda „big bang”.
To podejście nie działa, ponieważ nie pozwala zespołowi dostosować się do nieustannie zmieniających się czynników. Twój produkt musi odpowiadać m.in. na warunki rynkowe, rozmowy z nowymi klientami oraz wdrożenia, które stają się bardziej złożone niż oczekiwano.
Ustalanie priorytetów metodą „big bang” prowadzi również do wielkich debat, podczas których każda podjęta decyzja wywiera ogromny wpływ. Wywołuje to presję i oczekiwania, które mogą powodować napięcia w dyskusjach dotyczących priorytetów. Ludzie się martwią, że uzależnią się od złej alokacji zasobów, ponieważ nie chcą utknąć z wynikami tej decyzji na wiele miesięcy.
Zamiast tego zalecamy częste dyskutowanie z zespołami i interesariuszami o ustalaniu priorytetów — przynajmniej raz na dwa tygodnie lub miesiąc, a najlepiej co tydzień poświęcać chwilę na zastanowienie się nad tym, czego się dowiedzieliście. Czy na podstawie tego, czym się obecnie zajmujecie, to coś zmienia?
Konfiguracja backlogu produktu pod kątem obsługi tych dyskusji
Aby zapewnić wszystkim jasność co do ich ról i pomóc im w podejmowaniu właściwych decyzji, zalecamy skonfigurowanie backlogu produktu w następujący sposób:
- Autorzy biorą udział w projekcie Jira Product Discovery. Określają jego konfigurację (np. pola, widoki) oraz tworzą pomysły, widoki i analizy i nimi zarządzają.
- Współautorzy są dodawani do projektu, ale z ograniczonym zestawem pierwotnych funkcji współpracy. Mogą dodawać głosy, analizy, komentarze i reakcje.
- Interesariusze nie są dodawani do projektu. Zamiast tego autorzy publikują widoki tylko do odczytu, które im udostępniają.
Zalecamy tworzenie oddzielnych widoków dla każdej grupy odbiorców:
W Jira Product Discovery istnieją trzy widoki dla różnych ról:
Te specyficzne dla danej roli widoki zapewniają, że każda grupa otrzymuje potrzebne informacje w odpowiedni dla siebie sposób. Od razu będzie jasne, jak zespół produktowy ustala priorytety, które pomysły są omawiane i jak wnieść swój wkład. Istnieją kanały, które pozwalają wyrazić brak zgody w produktywny sposób.
Takie podejście pomaga każdej grupie odbiorców skutecznie się angażować, usprawniając współpracę i koordynowanie działań na wszystkich poziomach.
Techniki wspólnego ustalania priorytetów w Jira Product Discovery
Gdy wszyscy mają jasność co do warunków, ustalanie priorytetów staje się wspólnym, przejrzystym procesem. Wtedy można zacząć uczestniczyć w samych dyskusjach.
Twój backlog produktu w Jira Product Discovery to idealna przestrzeń, aby przekształcić ustalanie priorytetów we wspólne ćwiczenie. W tej sekcji przedstawimy różne sposoby konfigurowania backlogu produktu do obsługi tych rozmów.
Wiele z tych metod wykorzystuje liczby, np. oceny 1–5. Są one z natury subiektywne — ważnym elementem jest pytanie, dlaczego ocena jest taka, a nie inna. Liczy się to, że wszyscy rozumieją je w ten sam sposób, co ułatwia omawianie względnego priorytetu każdego pomysłu. Przykładowo poinformuj wszystkich, co jest uważane za „duży wysiłek” lub „niski wpływ”.
Zorganizuj grę o 10 USD, aby zachęcić do myślenia z uwzględnieniem ograniczeń
Gra o 10 USD to wciągający sposób nakłonienia ludzi do oceny znaczenia pomysłu przy jednoczesnym uwzględnieniu ograniczeń.
W przypadku braku ograniczeń dotyczących czasu i zasobów zespół produktowy mógł zrobić wszystko. Ale w rzeczywistości i czas, i zasoby są ograniczone. I tu pojawia się gra o 10 USD. To ćwiczenie z myślenia jak menedżer produktu, które pomaga graczom docenić, jak ciężka jest ta praca.
Gra o 10 USD w Jira Product Discovery
Metoda jest prosta: każdy uczestnik otrzymuje budżet w wysokości 10 USD, który może „wydać” na pomysły, które uważa za najważniejsze. Może postawić na pomysł tyle, ile chce, np. przeznaczając 5 USD na 2 pomysły lub 3 USD na 3. Oczywiście może również użyć budżetu innego niż 10 USD.
Następnie uczestnicy przedstawiają uzasadnienie swoich wyborów. Dlaczego uznali, że pewne pomysły są ważne lub obiecujące? Takie podejście zachęca do aktywnego uczestnictwa i dyskusji, zapewniając uwzględnienie wszystkich opinii.
Spróbuj użyć gry o 10 USD na początku cyklu ustalania priorytetów, aby zrozumieć, co myśli każdy uczestnik. Albo zagraj na końcu, aby sprawdzić, czy wszyscy jesteście zgodni.
Wykorzystanie macierzy relacji wpływu i nakładu pracy w rozmowach między zespołami produktowymi i inżynierskimi
Macierz relacji wpływu i nakładu pracy ustala priorytety dla pomysłów zarówno na podstawie ich potencjalnego wpływu na firmę, jak i nakładu pracy potrzebnego, aby je zrealizować.
Ta macierz to prosty, ale skuteczny sposób na uporządkowanie rozmów między menedżerami produktu a inżynierami.
Inżynierowie są zachęcani do dzielenia się swoim spojrzeniem na złożoność dostaw. Pomaga to menedżerom identyfikować możliwe szybkie korzyści lub najważniejsze założenia i określić, dlaczego konkretne pomysły powinny mieć priorytet nad innymi.
Macierz relacji wpływu i nakładu pracy w Jira Product Discovery
Uwzględnienie poziomów zaufania za pomocą RICE (zasięg, wpływ, zaufanie, nakład pracy)
Ramy RICE wykorzystują cztery czynniki, aby pomóc w ustaleniu priorytetów dla pomysłów: zasięg, wpływ, zaufanie i nakład pracy. Jest to popularne narzędzie do zarządzania produktami, gdyż formułuje te ważne czynniki w sposób zrozumiały dla większości interesariuszy.
Większość współautorów jest przyzwyczajonych do oceny wpływu, zasięgu i nakładu pracy, jaki będzie potrzebny do realizacji pomysłu. Jednak ramy RICE mają tę zaletę, że do rozmowy wnoszą też zaufanie.
Czy zespół produktowy jest przekonany, że ten pomysł jest dobrą inwestycją? A może potrzebują oni dalszych badań i weryfikacji produktu lub weryfikacji technicznej, aby zyskać pewność?
Ułatwia to zespołowi poinformowanie, dlaczego pomysł jest sprawą zamkniętą lub dlaczego może wymagać dalszych badań.
Proszenie zespołów mających kontakt z klientami o tagowanie klientów pod kątem pomysłów odpowiadających ich potrzebom
Wiele zespołów korzystających z Jira Product Discovery zdecydowało się na takie podejście: konfigurują widok z listą pomysłów, który ma być udostępniany zespołom mającym kontakt z klientami.
Kiedy klienci dzielą się potrzebami dotyczącymi jednego z pomysłów, pracownik działu sprzedaży/wsparcia otagowuje ich w odniesieniu do pomysłu. Następnie każdy pomysł można ocenić na podstawie liczby otagowanych klientów.
Jeśli klienci zaliczają się do segmentów o różnym znaczeniu, zespoły produktowe i klienckie mogą zechcieć przypisać różne wagi różnym klientom — w poniższym przykładzie klienci są podzieleni na segmenty Enterprise, MŚP i Startup.
To prosty, ale bardzo skuteczny sposób na ułatwienie produktywnych rozmów między zespołami produktowymi a zespołami mającymi kontakt z klientami.
Stosowanie wag do segmentów klientów w oparciu o cele firmy
Przypisywanie wag kluczowym klientom w celu ustalenia priorytetów
Można to zrobić bardziej wymyślnie (ale raczej nie warto)
Istnieje wiele innych metod, które zespoły mogą wykorzystać do omawiania priorytetów.
Naprawdę to Ty decydujesz, która jest odpowiednia dla Twoich potrzeb — ale na ogół okazuje się, że im prostsza metoda, tym lepsze rozmowy.
Prawdopodobnie przesada: najkrótsza ważona praca jako pierwsza (Weighted Shortest Job First — WSJF).
Niektóre zespoły mają obsesję na punkcie znalezienia „właściwego” modelu ustalania priorytetów. Ale ramy są tylko środkiem do osiągnięcia celu. Mają Ci pomóc w realizacji celów, a nie zajmować czas i uwagę. Pamiętaj — zarządzasz swoim produktem, a nie ramami ustalania priorytetów!
Korzystanie z metody, która się sprawdza
W końcu to wszystko tylko sugestie. Nie ma dwóch takich samych projektów Jira Product Discovery, ponieważ nie ma dwóch takich samych firm ani zespołów. W różnych kanałach wszystkie te metody służą do stworzenia zrównoważonego widoku:
- celów firmy;
- oczekiwań potencjalnych klientów;
- potrzeb klientów i użytkowników;
- sposobu na ograniczenie obciążenia zespołu wsparcia;
- sposobu na umożliwienie rozmów sprzedażowych;
- oraz innych kwestii, w zależności od firmy i produktu.
W oparciu o unikalne potrzeby i produkt Twojego zespołu zalecamy stworzenie własnej kombinacji widoków, które pomogą Ci ustalać priorytety według własnego uznania. Na tej podstawie tylko Ty możesz decydować, jakie powinny być Twoje priorytety: co zaakceptujesz, a czego nie.
Efektem tych dyskusji jest Twój harmonogram.
Co dalej?
Ustalanie priorytetów to jedyny sposób na powiązanie decyzji z pożądanymi wynikami produktowymi. Efektywne ustalanie priorytetów oznacza dobre harmonogramy, które odpowiedzialnie przydzielają zasoby, utrzymując zespoły produktowe na dobrej drodze do osiągania celów biznesowych i zaspokajania potrzeb klientów.
Teraz jesteśmy gotowi na ostatnią część tego podręcznika. Zbierzemy wszystko, czego się nauczyliśmy do tej pory, aby:
Utwórz harmonogramy, wokół których zespoły i interesariusze mogą się skupić.
Podamy przykłady, jak robimy to w zespole Jira Product Discovery, korzystając z Jira Product Discovery i innych produktów.
Informacja zwrotna i analizy
Dowiedz się, w jaki sposób integracja analiz z procesem rozwoju produktu może usprawnić podejmowanie decyzji, dostosować się do potrzeb klientów i zapewnić pomyślne wyniki.
Tworzenie harmonogramów
Dowiedz się, jak opracowywać skuteczne harmonogramy produktów, które dostosowują priorytety, usprawniają komunikację i wspierają cele strategiczne w zespołach.
