- Brawa na Sprint Review — 06/09/2024
- Kanban — Jak zacząć? — 30/08/2024
- Definicja Ukończenia kontra Kryteria Akceptacji — 26/08/2024
Confidence Meter jako miernik pewności pomysłów na Product Backlog
W artykule na temat wykorzystania modelu RICE do porządkowania Product Backlogu pisaliśmy o elemencie pewności (ang. confidence) w formule. Pewność jest cześcią formuły RICE i oznacza stopień pewności co do szacunków zasięgu i wpływu. Wartość tego składnika jest określona procentowo i zasadniczo też oszacowana jako wysoka, średnia i niska. Dzięki narzędziu Confidence Meter możemy zwiększyć ilość punktów na skali i obiektywnie określić faktyczną pewność.
Model RICE czy ICE?
Autor narzędzia używa go w ramach modelu ICE. ICE score to metoda priorytetyzacji wynaleziona przez Seana Ellisa, znanego z pomocy w rozwoju firm takich jak DropBox i Eventbrite oraz z ukucia terminu “Growth Hacking”. Początkowo oceny ICE miały na celu priorytetyzację eksperymentów związanych z rozwojem, ale mogą być również stosowane do zwykłych pomysłów na produkty.
Wynik ICE = Impact * Ease * Confidence
- Impact (Wpływ) to szacunkowa ocena tego, jak bardzo dany pomysł pozytywnie wpłynie na kluczowy wskaźnik, który starasz się poprawić.
- Ease (Łatwość wdrożenia) to ocena tego, ile wysiłku i zasobów będzie potrzebne do realizacji tego pomysłu. Zazwyczaj jest to odwrotność wysiłku (w tygodniach roboczych) – mniejszy wysiłek oznacza większą łatwość.
- Confidence (Pewność) wskazuje, jak bardzo jesteśmy pewni wpływu pomysłu, a także w pewnym stopniu łatwości jego wdrożenia. Napisałem cały artykuł wyjaśniający, dlaczego priorytetyzacja oparta na wpływie i wysiłku nie jest wystarczająca. W skrócie: jesteśmy bardzo słabi w szacowaniu obu tych czynników i nie zdajemy sobie z tego sprawy. Wartości pewności są antidotum – pozwalają nam być uczciwymi wobec naszych założeń.
Czym to się różni od modelu RICE? Nie ma tutaj szacowanego zasięgu i zamiast dzielić przez wysiłek, mnożymy przez łatwość. Jak wygląda ICE na przykładach możesz przeczytać w artykule Idea Prioritization With ICE and The Confidence Meter
Confidence Meter — Miernik pewności
Miernik pewności (Confidence Meter) to proste narzędzie oparte na arkuszu kalkulacyjnym, które pomaga zespołom ocenić poziom pewności dotyczący pomysłu na produkt. Narzędzie to pozwala ocenić, na ile zebrane dowody wspierają dany pomysł, co jest szczególnie przydatne w procesie walidacji pomysłów. Zamiast polegać na intuicji, zespoły mogą teraz podejmować decyzje oparte na twardych dowodach. Waga tych dowodów może być różna.
Confidence Meter — Skala miernika
Miernik pewności (Confidence Meter) proponuje skalę z różnymi wagami, którą wykorzystujemy do obliczenia ICE (jak autor sugeruje w swoim oficjalnym poście) lub możemy zastosować w modelu RICE. Na skali nie ma liczby zero, ponieważ zero w każdym z równań da wynik całkowity zero i szczerze, jak w ogóle nie jesteśmy przekonani, to nie ma nawet o czym dyskutować. Minimalny mnożnik to 0.01 daje opinia “mi się podoba”. Maksymalnie jeśli mamy dane od realnych użytkowników, możemy uzyskać mnożnik 3, co wyraźnie przechyli szalę.
Poziom pewności jest określony następująco:
| Evidence | Dowód | Waga |
|---|---|---|
| Self conviction | Wewnętrzne przekonanie | 0.01 |
| Pitch deck | Prezentacja dla inwestora | 0.02 |
| Thematic support Aligns with: vision/strategy, current trends/buzzword, outside research, macro trends, product methodology |
Wsparcie tematyczne Zgodność z: wizją/strategią, aktualnymi trendami/słowami kluczowymi, zewnętrznymi badaniami, makrotrendami, metodologią produktu |
0.05 |
| Other’s opinion The team / management / external expert / investor / press think it’s a good idea |
Opinia innych Zespół / zarząd / zewnętrzny ekspert / inwestor / prasa uważa, że to dobry pomysł |
0.1 |
| Estimates & plans Back of the envelope calculations, Eng / UX feasibility evaluation, Project timeline,Business model Canvas… |
Szacunki i plany Szybkie kalkulacje, ocena wykonalności Eng / UX, harmonogram projektu, kanwy typu Business Model, Lean Canvas… |
0.3 |
| Anecdotal Evidence Support by a few product data points, sales request, 1–3 interested customers, one competitor has it … |
Dowody anegdotyczne Wsparcie przez kilka punktów danych o produkcie, prośby sprzedażowe, 1–3 zainteresowanych klientów, jeden konkurent to ma… |
0.6 |
| Market Data Supported by surveys, smoke tests, all competitors have it… |
Dane rynkowe Wsparcie przez ankiety, testy dymne, wszyscy konkurenci to mają… |
1.0 |
| User/Customer Evidence Supported by: lots of product data, top user request, interviews with 20+ users, usability study, MVP |
Dowody od użytkowników/klientów Wsparcie przez: wiele danych o produkcie, najważniejsze prośby użytkowników, wywiady z 20+ użytkownikami, badania użyteczności, MVP |
2.0 |
| Test Results Supported by longitudinal user studies, large-scale MVP, alpha/beta, A/B experiments… |
Wyniki testów Wsparcie przez długoterminowe badania użytkowników, MVP na dużą skalę, testy alpha/beta, eksperymenty A/B… |
3 |
Miernik Pewności jest teraz dostępny jako darmowy kalkulator w oparciu o arkusz kalkulacyjny – pobierz swoją darmową kopię tutaj.
Co oznacza niska pewność?
Niska pewność może być demotywująca, bo przy małym mnożniku nasze pomysły nie mają szansy przebicia. Ale to niekoniecznie oznacza, żeby pomysł zakopać. Wręcz odwrotnie. Trzeba zdobyć więcej danych. Tutaj będzie widać, czy warto zrobić badania UXowe. Więc może zróbmy ankietę, zróbmy eksperyment, zbudujmy prototyp. Pisaliśmy już o tym jak przeprowadzać eksperymenty. Tylko pozostaje pytanie, ile kosztuje pozyskanie danych i czy to się po prostu opłaca. Pamiętajmy też, że czas biegnie nieubłaganie i może zacząć nam rosnąć Cost of Delay. Pomysły są jak banany. Najpierw dojrzewają, ale później coraz mniej nadają się do spożycia.
Confidence meter na pewno pomaga lepiej ocenić pomysły na backlogu i doskonale pasuje do modeli, gdzie mamy oszacować swoją pewność. Usuwamy z równania subiektywne oceny interesariuszy, rozmawiamy o konkretach, więc może być mniej konfliktów i walki o miejsce na roadmapie produktu. Widzimy wynik “czarno na białym”.
Product Owner nie ma wszystkich danych, więc potrzebne są warsztaty z zespołami i interesariuszami. Praca z Product Backlogiem wymaga ciągłości i systematyczności. Liczby musza być przeglądane, a dane ciągle zbierane. Warto mieć określony proces z miernikami, regułami i spotkaniami cyklicznymi.