Poniżej podaję kilka wybranych zagadnień. Po więcej, jak telemetria, sygnały, podejmowanie decyzji, zarządzanie ryzykiem i jeszcze wiele innych, zapraszam do dokumentu.
1. Wyjaśnienie różnicy: output, outcome, impact
- Output: co zostało wytworzone (np. funkcja, usprawnienie, release).
- Outcome: co zmieniło się u użytkownika/klienta (zachowanie, doświadczenie, wybór).
- Impact: co zmieniło się dla organizacji (trwały efekt biznesowy/społeczny: przychód, oszczędności, reputacja, udział w rynku).
Dokument pokazuje, dlaczego firmy mogą „produkować” świetne outputy i nadal nie osiągać outcome oraz impact.
2. Model logiczny i pętla uczenia się
Treść porządkuje myślenie w łańcuchu (często nieliniowym):
Inputs → Activities → Outputs → Outcomes → Impact
oraz podkreśla, że praca produktowa to przede wszystkim ciągłe uczenie się, a nie realizacja planu. Dlatego w modelu pojawiają się także Assumptions (założenia), aby jasno pokazać, że część decyzji jest podejmowana na podstawie hipotez. Założenia inicjują działanie, a kolejne kroki dostarczają sygnałów, które pozwalają je potwierdzić, skorygować albo odrzucić.
3. PDSA jako mikro-pętle w Scrum
Każdy Product Goal i Sprint Goal może działać jak mały cykl:
Plan – Do – Study – Act
Hipoteza → realizacja → pomiar → wnioski → adaptacja.
W skrócie: evidence beats opinion. O decyzji powinny rozstrzygać dowody, nie opinie.
4. „Meaningful checks” – mechanizmy weryfikacji w każdym Sprincie (redukcja ryzyka)
Dokument proponuje praktyczne mechanizmy weryfikacji, które ograniczają ryzyko budowania czegoś, co nie będzie wartościowe, potrzebne czy niedziałające. Nie musisz wdrażać wszystkiego na raz, sprawdź, czego brakuje w organizacji.
Kilka przykładów:
- spike / prototyp techniczny,
- przegląd kompetencji i pojemności,
- odkrywanie zależności,
- kryteria jakości zależne od ryzyka,
- jasne kill-criteria dla eksperymentów,
- compliance-by-design,
- gotowość telemetrii/obserwowalności i inne.
5. Zmiana kulturowa: mercenary → missionary. Najemnicy czy Misjonarze?
Dokument przywołuje koncepcję Marty’ego Cagana i Johna Doerra, dzielącą zespoły na dwa typy:
- Zespoły Najemników (Mercenaries): Budują to, co im kazano. Są profesjonalni, ale ich odpowiedzialność kończy się na wdrożeniu funkcji.
- Zespoły Misjonarzy (Missionaries): Są oddani strategii produktu i rozwiązywaniu problemów. Pytają: „Czy życie klienta się poprawiło?”. Biorą odpowiedzialność za cały łańcuch wartości – od pomysłu po impakt biznesowy.
Product Thinking pokazuje, jak przekształcić zespół w Misjonarzy, którzy zamiast pytać „czy zdążymy na czas?”, pytają „gdzie są dowody na to, że to działa?”.
