10-etapowy cykl zarządzania produktem

Wstęp

Pewnego dnia zapytano mnie, jak my w Amazon myślimy o zarządzaniu produktem i cyklu tworzenia oprogramowania. Jakich mechanizmów potrzeba, aby stworzyć powtarzalny proces? Kto jest właścicielem każdego kroku i kto powinien być zaangażowany? Jak rozwijasz pomysły? Jak ustalasz priorytety? Jak utrzymać proces na właściwym torze? Po napisaniu całego przepływu zdałem sobie sprawę, że po raz pierwszy zapisałem go na jednej kartce papieru. Pomyślałem, że może to być pomocne dla innych i dlatego chciałem się z tobą podzielić tutaj. Grupa docelowa tego przeglądu to przede wszystkim nowi menedżerowie produktu, ponieważ są to pierwsze główne koncepcje. Doświadczeni PM znają te kroki dokładnie, ale mam nadzieję, że dla nich też jest kilka samorodków. Chcę również wyjaśnić, że nie uważam tego za „przepływ” rozwoju produktu — istnieją niewątpliwie alternatywy i wymagane są określone modyfikacje w zależności od branży lub sytuacji. Dlatego nie uważam tego za wyczerpujący przegląd, ale za ogólny plan. Ten „plan” dotyczy pojedynczego programu lub funkcji, dlatego istnieją mechanizmy, które znajdują się na szczycie tego cyklu dla celów długoterminowych inwestycji strategicznych. Niektóre organizacje będą miały również inną kolejność lub grupowanie działań, co jest oczywiście całkowicie w porządku. Ważną rzeczą jest zbudowanie silnych mechanizmów dla każdego z tych działań: stwórz jasną własność, opracuj cele i oczekiwania dotyczące wyników oraz regularnie sprawdzaj i ulepszaj swoje mechanizmy. Podsumowałem 10 kroków na rysunku 1 poniżej,

Rysunek 1: 10-etapowy cykl rozwoju produktu

Krok 1: Pomysły na produkty i funkcje

Co więc powinniśmy budować dla klientów? Istnieje wiele potencjalnie powtarzających się mechanizmów, których można użyć do opracowania pomysłów na zupełnie nowy produkt dla klientów, produktów na poziomie platformy obsługujących wielu klientów wewnętrznych lub zewnętrznych, rozszerzeń funkcji dla istniejących produktów, refaktoryzacji istniejących produktów lub po prostu naprawić błędy. Pomysły te można następnie wykorzystać jako część rocznych/kwartalnych cykli inwestycyjnych i planistycznych lub do przedstawienia nowych pomysłów, które wymagają dodatkowego zatrudnienia. Zbudowaliśmy kilka mechanizmów ułatwiających ten cykl: roczne planowanie strategii i inwestycji, kwartalne planowanie priorytetów, dwutygodniowe przeglądy statusu i planowanie sprintu. Dzielimy się tymi możliwościami również z interesariuszami, w tym klientami (zwłaszcza w świecie Business to Business), wewnętrznymi i zewnętrznymi zespołami partnerów, sprzedawcami/dostawcami, i przywództwa. Prawdziwe pytanie, na które próbujemy odpowiedzieć w przypadku nowych możliwości produktowych, brzmi: Jakie jest najcenniejsze doświadczenie, jakie możemy zapewnić klientom? I jakie jest najcenniejsze doświadczenie, jakie możemy zapewnić naszym dostawcom/sprzedawcom (lub wstawić tutaj innych kluczowych interesariuszy). Wartość jest definiowana przez organizację i prawdopodobnie jest różna w różnych branżach lub tam, gdzie organizacja znajduje się w fazie dojrzałości rozwojowej. Ogólnie rzecz biorąc, polecam najlepsze proxy dla przyrostowych długoterminowych wolnych przepływów pieniężnych. Długoterminowe wolne przepływy pieniężne obejmują zarówno krótkoterminową wartość transakcyjną (w tym reklamę), jak i długoterminową wartość w postaci subskrypcji, długoterminowego zaangażowania/konwersji lub „odblokowywania” wartości w innym miejscu organizacji (tj. możliwości sprzedaży/dosprzedaży lub odkrywania nowych produktów i usług). Długoterminowe wolne przepływy pieniężne są motorem wzrostu, są dostosowane do inwestorów i nie poświęcają długoterminowych zysków na rzecz krótkoterminowych ulepszeń. Jedną z koncepcji, która jest kluczowa, ale bardzo trudna do przewidzenia, jest przyrostowość. Przeprowadziliśmy niezliczone eksperymenty, z których dowiedzieliśmy się, że nowy produkt generuje wartość, ale może zrównoważyć wartość z innego miejsca lub nawet zasadniczo zmienić zachowanie klienta. To nowe doświadczenie może zatem nie być całkowicie akrecyjne. W miarę jak produkty i usługi organizacji stają się coraz bardziej złożone, konieczne jest konsekwentne wbudowywanie tego w równanie wartości. I równie ważne, jeśli nie ważniejsze, aby uwzględnić je w swoich działaniach marketingowych. Jedną z koncepcji, która jest kluczowa, ale bardzo trudna do przewidzenia, jest przyrostowość. Przeprowadziliśmy niezliczone eksperymenty, z których dowiedzieliśmy się, że nowy produkt generuje wartość, ale może zrównoważyć wartość z innego miejsca lub nawet zasadniczo zmienić zachowanie klienta. To nowe doświadczenie może zatem nie być całkowicie akrecyjne. W miarę jak produkty i usługi organizacji stają się coraz bardziej złożone, konieczne jest konsekwentne wbudowywanie tego w równanie wartości. I równie ważne, jeśli nie ważniejsze, aby uwzględnić je w swoich działaniach marketingowych. Jedną z koncepcji, która jest kluczowa, ale bardzo trudna do przewidzenia, jest przyrostowość. Przeprowadziliśmy niezliczone eksperymenty, z których dowiedzieliśmy się, że nowy produkt generuje wartość, ale może zrównoważyć wartość z innego miejsca lub nawet zasadniczo zmienić zachowanie klienta. To nowe doświadczenie może zatem nie być całkowicie akrecyjne. W miarę jak produkty i usługi organizacji stają się coraz bardziej złożone, konieczne jest konsekwentne wbudowywanie tego w równanie wartości. I równie ważne, jeśli nie ważniejsze, aby uwzględnić je w swoich działaniach marketingowych. W miarę jak produkty i usługi organizacji stają się coraz bardziej złożone, konieczne jest konsekwentne wbudowywanie tego w równanie wartości. I równie ważne, jeśli nie ważniejsze, aby uwzględnić je w swoich działaniach marketingowych. W miarę jak produkty i usługi organizacji stają się coraz bardziej złożone, konieczne jest konsekwentne wbudowywanie tego w równanie wartości. I równie ważne, jeśli nie ważniejsze, aby uwzględnić je w swoich działaniach marketingowych.

Oto kilka mechanizmów, które warto wziąć pod uwagę podczas opracowywania nowych pomysłów dla klientów i interesariuszy:

Bezpośrednie opinie klientów

Definiuję bezpośrednie opinie klientów jako wyraźne sygnały mające na celu przekazanie opinii na temat produktu.

1. Badania użyteczności: zwykle stosowane na wczesnym etapie rozwoju produktu, prowadzisz sesję z około 10 klientami, aby uzyskać informacje zwrotne na temat konkretnych wyborów dotyczących przepływu i projektu. Możesz wykorzystać prototyp produktu całego przepływu, a nawet wykorzystać makiety, jeśli inwestycja jest duża, aby stworzyć prototyp. Klienci podają niezliczone sugestie i możliwości dalszego badania. Moja sugestia polega na tym, aby przyjąć 5-kierunkowe podejście: klienci rzadko udzielają odpowiedzi — lub nawet jasno wyrażają, czego chcą. Kontynuuj kopanie, aby znaleźć ich prawdziwą motywację.

2. Grupy fokusowe / dzienniki klienta: ten mechanizm jest pomocny, aby głębiej zrozumieć, dlaczego klient robi to, co robi (lub nie robi). Możesz chcieć wiedzieć, dlaczego klient uwielbia konkurencyjną funkcję, dlaczego nie korzysta z niektórych funkcji, dlaczego przestał używać produktu itp. Ten krok nie ma na celu uzyskania istotności statystycznej i uporządkowania najważniejszych problemów, ale raczej zbuduj listę najważniejszych zagadnień wraz z hipotezą uporządkowania. Bardzo pomocne są również dzienniki, w których prosi się klienta o zapisanie za każdym razem, gdy robi X, dlaczego to zrobił, co próbował osiągnąć i co chciał, żeby było inaczej. Może to być pomocne w odkryciu zachowań, które są automatyczne lub podświadome.

3. Ankiety konsumenckie: Po zapoznaniu się z najważniejszymi zagadnieniami z grup fokusowych/dzienników można użyć ankiety konsumenckiej, aby zbliżyć się do istotności statystycznej i uporządkować najważniejsze możliwości.

4. Recenzje klientów / recenzje w sklepie z aplikacjami: klienci, którzy zazwyczaj piszą recenzje w sklepie z aplikacjami lub recenzje klientów, są naprawdę bardzo zirytowani. Zwykle nie jest łatwo przekazać informację zwrotną, dlatego są gotowi przeskoczyć przez obręcze, aby to zrobić. Chociaż niekoniecznie zalecam to do tworzenia „najważniejszych” numerów, są one doskonałym źródłem „nieoszlifowanych diamentów” dla nowych pomysłów i oczywiście błędów lub uszkodzeń w istniejącym doświadczeniu.

5. Aplikacje panelowe / beta: warto wcześnie uzyskać opinie na temat produktów, zwłaszcza podczas tworzenia bardziej złożonych funkcji lub usług, których ukończenie zajmie miesiące. Aby uzyskać tę informację zwrotną, możesz utworzyć panel klienta (zwłaszcza jeśli masz dużych, ważnych klientów) lub aplikację beta, w której klienci są pasjonatami Twojego produktu i chcą wypróbować nowe funkcje. Oczywiście musisz wziąć te dane z przymrużeniem oka, biorąc pod uwagę, że źródło jest stronnicze, ale da ci to cenne wczesne wskaźniki.

6. Wyraźne sygnały lub opinie klientów: można je wbudować w sam produkt, aby uzyskać reakcję klientów na to doświadczenie. Można to wdrożyć na kilka różnych sposobów, od prostego „kciuk w górę / kciuk w dół” po umożliwienie klientowi wypełnienia formularza opinii. W przypadku informacji zwrotnych od klientów najbardziej przydatne jest, gdy klient ma natychmiastowy problem, ponieważ wtedy może najlepiej go wyrazić i jest zmotywowany do przekazywania informacji zwrotnych. Aby to osiągnąć, można zbudować mechanizm, który umożliwi klientowi przekazywanie informacji zwrotnych w dowolnym miejscu przepływu (np. włączenie jednej z makrofunkcji systemu operacyjnego, takich jak „wstrząsnąć”).

Pośrednie opinie klientów

Pośrednią informację zwrotną definiuję jako ukryte sygnały wskazujące na rezonans klienta z produktem.

Oprócz bezpośredniego proszenia klienta o opinię, możesz również odpowiedzieć na pytanie: „Z czym rezonują klienci poza Twoją organizacją?” Oczywiście gromadzenie tych samych danych, co w przypadku doświadczeń wewnętrznych (tj. danych dotyczących retencji, informacji finansowych, a nawet po prostu współczynników klikalności), jest trudnym zadaniem, ale istnieją sposoby gromadzenia danych, aby zorientować się, czy należy wziąć pod uwagę te doświadczenia. Gorąco zachęcam również do powstrzymania się od bezpośredniego benchmarkingu — z mojego doświadczenia wynika, że ​​w zdecydowanej większości przypadków poświęcasz nieproporcjonalnie dużo czasu na gromadzenie danych, porównywanie ich z własnymi danymi i próby łączenia lub zrozumienia różnic, i co prawie zawsze prowadzi do ślepego zaułka i zmarnowanego wysiłku. Kuszące jest (zwłaszcza dla kierownictwa wyższego szczebla lub inwestorów), aby spróbować zrozumieć „dlaczego nie osiągamy wyników w X?” Ale diabeł zawsze tkwi w szczegółach, a te szczegóły zwykle nie są dostępne. Mieliśmy wystarczająco dużo wyzwań, porównując nasze własne dane wewnętrzne!

7. Dane behawioralne klientów: jest to jeden z najbardziej oczywistych sposobów zrozumienia doświadczenia klienta z istniejącym produktem. Jak myśleć o tym temacie, moglibyśmy poświęcić cały artykuł. Niektóre przykłady obejmują wskaźniki, takie jak wskaźnik klikalności, wskaźniki retencji w czasie, współczynniki konwersji, współczynniki rezygnacji itp. Jednym z najskuteczniejszych sposobów zrozumienia tych danych jest analiza kohort w czasie, aby zobaczyć, jak i dlaczego zmienia się zachowanie klienta .

8. Obsługa klienta: to doskonałe źródło informacji o błędach i usterkach w istniejących produktach. Współpracownicy obsługi klienta są również doskonałym źródłem wiedzy, aby zrozumieć, co najbardziej przeszkadza klientom i uzyskać samorodki, takie jak „dlaczego nie mogę po prostu zrobić X?”

9. Agregatory danych: uznaliśmy, że warto szukać agregatorów danych, które zbierają dane w spójny sposób. Nie jest to również „czyste” i prawdopodobnie nieporównywalne z danymi wewnętrznymi, ale jest względne, a zatem różnice i trendy mogą być wnikliwe. Dlatego dane bezwzględne nie są przydatne, ale delty i zmiany w czasie tak. Niektóre przykłady agregatorów danych to data.ai (dawniej App Annie), Sensor Tower, Appfigures, Quantum Metric. Organizacje te śledzą zachowania klientów korzystające z aplikacji na iOS i Androida i mogą dostarczać informacji na temat tego, które aplikacje klienci najczęściej pobierają, utrzymywania różnych aplikacji, względnego rozmiaru i tego, jak zmieniały się one w czasie. Oprócz witryn śledzących aplikacje, podobneweb i Statista udostępniają informacje na różne tematy, które można wykorzystać do oceny wielkości rynku.

Pomysły zespołu lub interesariuszy

10. Zespół: umożliwiamy członkom zespołu stworzenie jednostronicowego „dokumentu prezentacji” i ocenę tych pomysłów w ramach przeprowadzanego co dwa lata procesu podobnego do „zbiornika z rekinami”, aby sprawdzić, czy jakieś pomysły zostaną uwzględnione w planie działania — lub — czy zostać przedstawione kierownictwu wyższego szczebla w celu uzyskania dodatkowego finansowania. Intencją jest umożliwienie członkom naszego zespołu udziału w procesie generowania pomysłów w stosunkowo lekki sposób. Pomysł może pochodzić z danych, które zebrali, czegoś, czego doświadczyli w innej aplikacji lub rekomendacji od znajomego. Naszym jedynym kryterium jest to, że pomysł ma pewne podstawy w danych — artykuł wskazujący na zalety pomysłu. Zachęcamy wszystkich członków zespołu do udziału, w tym inżynierów bezpośrednio po szkole. Jeśli pomysł zostanie wybrany, będziemy mieć partnera autora wraz z Product Managerem, aby rozwinąć pomysł w pełni rozwinięty PRFAQ (więcej na ten temat w kroku 2 poniżej). Trzy inne mechanizmy, które stosujemy (podobnie jak wiele innych organizacji) to 1) Hackathon: umożliwianie członkom zespołu współpracy w celu stworzenia prototypu każdego interesującego ich pomysłu oraz 2) Dni twórcy: dwa razy w roku poświęcamy jeden sprint, aby umożliwić członkowie zespołu mogą pracować nad czym tylko zechcą — od czyszczenia kodu po pracę nad nowym pomysłem, 3) Spacer po sklepie: raz w miesiącu PM przejmie inicjatywę, prowadząc zespół krok po kroku przez istniejące doświadczenie klienta , tak jak zrobiłby to klient. Powinno to odbywać się na żywo (w miarę możliwości), przy jednoczesnym klikaniu przez kierownika projektu i umożliwianiu członkom zespołu zadawania pytań. W większości przypadków uwydatni to wiele możliwości poprawy istniejącego doświadczenia,

11. Przyjmowanie przez zespół partnerski: jeśli inne zespoły w Twojej organizacji korzystają z Twoich usług lub Twoje produkty mają na nie wpływ, możesz zabiegać o ich własne pomysły. Zwykle tworzymy prosty szablon (tj. pomysł, dlaczego klienci go pokochają i wszelkie dane wskazujące, dlaczego będzie to pomocne dla klientów, wysoki poziom długoterminowego wpływu wolnych przepływów pieniężnych).

Krok 2: Praca z dokumentem wstecz

Kiedy już zdecydujesz się na najlepsze pomysły na produkt lub funkcję, musisz szczegółowo opisać minimalne przyjemne doświadczenie klienta (krótko- i długoterminowe), biznesplan, logowanie, strategię dotyczącą danych i wskaźników oraz ryzyko, jakie poniesiesz napotkać i jak je złagodzisz. Wszystko to można udokumentować w dokumencie, który nazywamy dokumentem działającym wstecz, na przykład dokumentem, który wyraża pełne kompleksowe doświadczenie, które dostarczymy klientom, dlaczego klienci pokochają produkt, jak z niego korzystają, oraz gdzie mogą to znaleźć. Poziom szczegółowości opisany w tym dokumencie będzie różny, ale jest z grubsza skorelowany z kwotą inwestycji. Jeśli inwestycja jest wysoka, np. jeden lub więcej dwuosobowych zespołów pizzowych na ponad sześć miesięcy (organizujemy się wokół dwuosobowych zespołów pizzowych, który jest zespołem, który ma dobrze zdefiniowany i konkretny cel i składa się z około 6–8 inżynierów, kierownika produktu i kierownika ds. rozwoju oprogramowania. Razem wystarczą dwie pizze, aby je nakarmić), a następnie dostarczymy w pełni rozwiniętą informację prasową wraz z często zadawanymi pytaniami (PRFAQ). Wiele już napisano na temat PRFAQ Amazona, więc nie będę tutaj wchodził w szczegóły, ale na wysokim poziomie komunikat prasowy to zazwyczaj tylko strona, napisana w celu opisania, jakie będą wrażenia podczas premiery, dlaczego klienci to pokochają , jak z niej korzystają i jak klienci mogą ją znaleźć. Często zadawane pytania mają zwykle od trzech do pięciu stron, a cały dokument nie przekracza sześciu stron, chociaż można dodać dodatek z makietami interfejsu użytkownika (tj. zrzuty ekranu przedstawiające krok po kroku doświadczenia klienta) lub inne istotne informacje. Nie mogę wystarczająco podkreślić, jak ważne jest udokumentowanie z góry doświadczenia klienta i kluczowych decyzji biznesowych przed rozpoczęciem procesu tworzenia oprogramowania. Stworzenie tego dokumentu umożliwia zakomunikowanie strategii interesariuszom, w tym członkom własnego zespołu. Umożliwia wyartykułowanie przepływu klientów i przedyskutowanie, jeśli to konieczne, kluczowych decyzji z góry. Jeden z dyrektorów Amazon wysokiego szczebla powiedział nam kiedyś: „Zawsze zaczynamy od PRFAQ przed napisaniem jednej linii kodu. To pozwala nam dostosować się do doświadczenia i przedyskutować kluczowe kwestie przed przedstawieniem go klientowi”. Stworzenie tego dokumentu umożliwia zakomunikowanie strategii interesariuszom, w tym członkom własnego zespołu. Umożliwia wyartykułowanie przepływu klientów i przedyskutowanie, jeśli to konieczne, kluczowych decyzji z góry. Jeden z dyrektorów Amazon wysokiego szczebla powiedział nam kiedyś: „Zawsze zaczynamy od PRFAQ przed napisaniem jednej linii kodu. To pozwala nam dostosować się do doświadczenia i przedyskutować kluczowe kwestie przed przedstawieniem go klientowi”. Stworzenie tego dokumentu umożliwia zakomunikowanie strategii interesariuszom, w tym członkom własnego zespołu. Umożliwia wyartykułowanie przepływu klientów i przedyskutowanie, jeśli to konieczne, kluczowych decyzji z góry. Jeden z dyrektorów Amazon wysokiego szczebla powiedział nam kiedyś: „Zawsze zaczynamy od PRFAQ przed napisaniem jednej linii kodu. To pozwala nam dostosować się do doświadczenia i przedyskutować kluczowe kwestie przed przedstawieniem go klientowi”.

Jak wspomniano powyżej, możesz rozpocząć proces od „dokumentów prezentacji” lub ich wersji, aby nie wymagać od członków zespołu napisania sześciu stron przed rozmową. Jeśli pomysł jest cechą istniejącego produktu, możesz również przejść do kroku 5, aby szczegółowo opisać przypadki użycia i przełożyć je na specyfikacje techniczne.

Krok 3: Ustalanie priorytetów

Uwzględniam ustalanie priorytetów jako krok trzeci, ale ustalanie priorytetów ma miejsce w całym cyklu rozwoju produktu. Zamieszczam go tutaj, ponieważ kiedy już będziesz miał swoje najlepsze pomysły na produkty, z których większość będzie miała działające wstecz dokumenty, będziesz miał informacje potrzebne do podejmowania decyzji inwestycyjnych w ciągu roku lub kwartału (lub miesiąca lub sprintu). Decyzje dotyczące funkcji lub funkcji podrzędnych mogą ulec zmianie w trakcie procesu, gdy zbierzesz więcej informacji.

Aby ułatwić proces ustalania priorytetów, niezwykle przydatne jest posiadanie metryki lub zestawu metryk, które są zgodne z zespołami w całej organizacji. Istnieje wiele różnych wskaźników ustalania priorytetów, ale zazwyczaj obejmują one co najmniej trzy następujące elementy: 1) Wpływ na klienta lub działalność biznesową: można to postrzegać jako wskaźnik finansowy (np. wzrost przychodów, zysków), postrzegany jako wzrost zaangażowania (np. wizyty lub powtórne wizyty, czas oczekiwania) lub wzrost oceny/zadowolenia klientów z doświadczenia lub zmniejszenie liczby reklamacji. Będziesz musiał dokonać kompromisu między dokładnością pomiaru wartości dla klienta a prostotą posiadania jednego miernika, który dotyczy całej firmy. Osobiście opowiadam się za tym drugim rozwiązaniem, ponieważ zespół będzie coraz lepiej radził sobie z szacowaniem wpływu pojedynczego wskaźnika w czasie, 2) Czas wdrożenia: wyższa wartość, krótsze czasy wprowadzenia na rynek są oczywiście preferowane. Rozważając czas wprowadzenia na rynek, zadaj sobie pytanie, czy wersję doświadczenia można przedstawić klientowi, aby uzyskać szybsze oszacowanie wartości produktu. Będzie to zależeć od całości kosztów wytworzenia produktu; im wyższy koszt, tym bardziej powinieneś szukać tych możliwości, zanim w pełni zainwestujesz w tworzenie produktu, oraz 3) Ryzyko: czy istnieją wewnętrzne lub zewnętrzne czynniki, które mogą zablokować twoje wysiłki? Jak prawdopodobne są te scenariusze? Czy jest element doświadczenia, w którym zespół ma mniejsze doświadczenie, np. uczenie maszynowe? zadaj sobie pytanie, czy wersję doświadczenia można przedstawić klientowi, aby uzyskać szybsze oszacowanie wartości produktu. Będzie to zależeć od całości kosztów wytworzenia produktu; im wyższy koszt, tym bardziej powinieneś szukać tych możliwości, zanim w pełni zainwestujesz w tworzenie produktu, oraz 3) Ryzyko: czy istnieją wewnętrzne lub zewnętrzne czynniki, które mogą zablokować twoje wysiłki? Jak prawdopodobne są te scenariusze? Czy jest element doświadczenia, w którym zespół ma mniejsze doświadczenie, np. uczenie maszynowe? zadaj sobie pytanie, czy wersję doświadczenia można przedstawić klientowi, aby uzyskać szybsze oszacowanie wartości produktu. Będzie to zależeć od całości kosztów wytworzenia produktu; im wyższy koszt, tym bardziej powinieneś szukać tych możliwości, zanim w pełni zainwestujesz w tworzenie produktu, oraz 3) Ryzyko: czy istnieją wewnętrzne lub zewnętrzne czynniki, które mogą zablokować twoje wysiłki? Jak prawdopodobne są te scenariusze? Czy jest element doświadczenia, w którym zespół ma mniejsze doświadczenie, np. uczenie maszynowe? czy istnieją wewnętrzne lub zewnętrzne czynniki, które mogą blokować twoje wysiłki? Jak prawdopodobne są te scenariusze? Czy jest element doświadczenia, w którym zespół ma mniejsze doświadczenie, np. uczenie maszynowe? czy istnieją wewnętrzne lub zewnętrzne czynniki, które mogą blokować twoje wysiłki? Jak prawdopodobne są te scenariusze? Czy jest element doświadczenia, w którym zespół ma mniejsze doświadczenie, np. uczenie maszynowe?

Krok 4: Podział historii klientów

Korzystając z dokumentu roboczego wstecz, możesz uchwycić wszystkie zamierzone funkcje, które klient i/lub interesariusze chcieliby osiągnąć za pomocą tego produktu. Jest to zazwyczaj pisane z perspektywy odbiorcy wartości produktu. Na przykład stworzyliśmy produkt, który zapewnia artykuły eksperckie na temat produktów (np. od wydawców takich jak Wirecutter) dla klientów poszukujących informacji o recenzjach produktów (poza recenzjami klientów). Wbudowaliśmy jedną wersję tego w wyniki wyszukiwania Amazona, np. jeśli klient szukał „najlepszych telewizorów”, wyświetlaliśmy widżet w ramach wyszukiwania (lub dokładniej, oferowaliśmy wyszukiwarce Amazon możliwość wyświetlenia artykułu). Jedna z historii klientów brzmiała: „Jako klient chciałbym widzieć artykuły ekspertów na temat produktów, którymi jestem zainteresowany, kiedy szukam produktu. Chciałbym zobaczyć produkt, ocenę w gwiazdkach, który wydawca ma recenzję tego produktu, oraz informacje „na kęs” z artykułu, aby określić, czy chcę się zaangażować. Umożliwiło nam to również zaoferowanie klientom różnych interfejsów produktów. Innym przypadkiem użycia było „Jako klient chciałbym zobaczyć trzy najlepsze artykuły związane z produktem, którego szukałem”. Należy wziąć pod uwagę wszystkich interesariuszy związanych z tym produktem. W powyższym przypadku wydawcy są wyraźnym interesariuszem. Jednym z przypadków użycia było zatem „Jako wydawca chcę, aby moja marka była wyraźnie widoczna dla klienta”. Przykład zespołu partnerskiego może brzmieć: „Jako zespół ds. wyszukiwania wymagamy uszeregowanego zestawu widżetów artykułów przesłanych za pośrednictwem naszego interfejsu API w ciągu X milisekund”. Możesz również rozważyć inne zespoły partnerskie, takie jak dział prawny, finansowy, PR, operacyjny,

Następnie możesz nadać priorytet wszystkim przypadkom użycia, aby utworzyć minimalny produkt, który można polubić (MLP). Niektóre organizacje używają terminu „Minimum Viable Product (MVP)” jako pierwszej iteracji produktu. Było to intensywnie dyskutowane w Amazon i ustalono, że minimalny pasek to produkt, który klienci pokochają. Dlatego debatujemy, jakie funkcje powinny być częścią MLP, który będzie wtedy zbiorem funkcji P0. Aby ułatwić ustalanie priorytetów funkcji, możesz wykorzystać testy użyteczności, aby uzyskać dane na temat tego, co klienci uważają za krytyczne, a co przyjemne.

Krok 5: Dokument wymagań biznesowych

Celem dokumentu wymagań biznesowych jest wejście głębiej niż dokument roboczy wstecz i bycie kluczowym wkładem w projekt techniczny. Ten artefakt zagłębi się i przedstawi 1) dlaczego tworzymy ten produkt — dlaczego klient pokocha ten produkt i jakie jest uzasadnienie biznesowe?, 2) Zanurz się głębiej w doświadczenie klienta. Powinieneś mieć pełny przepływ klientów i kpiny dla każdego etapu podróży klienta — który będzie oparty na funkcjach P0 zidentyfikowanych w poprzednim kroku. Można to następnie wykorzystać do wyrażenia zamierzonej funkcjonalności i wyników dla klienta, a także do czego produkt nie jest przeznaczony. Zazwyczaj podczas tego procesu będziesz mieć kilka debat w zespole i z interesariuszami na temat projektu i funkcjonalności, 3) Zrozumieć, w jaki sposób zostaną rozwiązane wyjątki i błędy, 4) Szczegółowo opisz strategię, projekt eksperymentu i wszelkie krytyczne elementy, którymi należy się zająć (np. jak będzie przebiegać uruchamianie eksperymentu, aby zapewnić równy podział między leczeniem a kontrolą?). Ten dokument będzie głównym artefaktem, którego zespół techniczny użyje do opracowania projektu technicznego.

Krok 6: Projekt techniczny i podział techniczny

Ważne jest zaangażowanie zespołu technicznego przez cały cykl rozwoju produktu. Jeśli angażujesz zespół techniczny w kroku 6, istnieje bardzo duże prawdopodobieństwo, że MLP będzie inny (i lepszy dla klientów) dzięki ich wkładowi. Będą mieli wgląd, pytania i doświadczenie, aby pomóc określić, co jest łatwe, a co trudne do zbudowania dla klientów, co jest ryzykowne, i zadają trudne pytania, dlaczego klienci pokochają ten produkt. Podczas gdy Product Management jest właścicielem wykonania kroków 1–5 (a następnie wspólnie jest właścicielem kroków 8–10), zespół techniczny przejmie odpowiedzialność za kroki 6 i 7.

Na tym etapie ważne jest, aby kierownik produktu uzyskał działającą wstecz oś czasu dla ostatecznego projektu technicznego. Aby to osiągnąć, zespół napisze szkice projektu, dokona przeglądu z głównymi i starszymi inżynierami oraz w razie potrzeby nawiąże współpracę z zespołami partnerskimi. Będą również zawierały plan testowania i budowania w czasie, aby naprawić wszelkie blokujące błędy. Zespół powinien również omówić doskonałość operacyjną/inżynieryjną oraz projekt i konfigurację eksperymentu. Aby osiągnąć doskonałość operacyjną/inżynieryjną, zespół techniczny będzie potrzebował czasu na dokumentację, testowanie opóźnień, działania w zakresie bezpieczeństwa, prywatności, odporności (tj. zawodzi i w jakim stopniu. Pytanie do zespołu brzmi: ile z tego zespół wykonuje z góry przed rozpoczęciem eksperymentów? Naszym zdaniem istnieje kilka elementów stołów, których nie można cofnąć: bezpieczeństwo, prywatność, dostępność i metryki operacyjne. Wysiłki na rzecz odporności są szczególnie ważne w przypadku scenariuszy o dużym natężeniu ruchu, ale jeśli produkt nie zostanie uruchomiony (ponieważ nie przejdzie eksperymentu), wówczas te inwestycje mogą być pracą do wyrzucenia. W rezultacie sugeruję rozróżnienie między tym, co jest krytyczne dla eksperymentu klienta, a tym, co jest krytyczne dla dużego ruchu. Główne role Menedżera Produktu to: 1) Przygotowanie planu eksperymentów. Co należy przetestować — a nie tylko metryki skierowane do klienta, takie jak kliknięcia, przychody, reklamy, wartość długoterminowa itp. Są one oczywiście ważne, ale należy również mierzyć wszystkie metryki operacyjne, w tym opóźnienie między kliknięciami a malowaniem doświadczeń oraz gotowość dodatkowych punktów zaangażowania, liczbę błędów, których doświadcza klient i w jakim stopniu. Kierownik projektu będzie również odpowiedzialny za testy akceptacji użytkownika (UAT), podczas których przechodzisz przez kolejne kliknięcia, aby upewnić się, że działanie działa zgodnie z oczekiwaniami, w każdym regionie i w każdym języku. Sugerujemy napisanie dokumentu opisującego podejście do testowania i rekrutację członków zespołu z każdego regionu do pomocy w testowaniu. w każdej lokalizacji i każdym języku. Sugerujemy napisanie dokumentu opisującego podejście do testowania i rekrutację członków zespołu z każdego regionu do pomocy w testowaniu. w każdej lokalizacji i każdym języku. Sugerujemy napisanie dokumentu opisującego podejście do testowania i rekrutację członków zespołu z każdego regionu do pomocy w testowaniu.

Krok 7: Implementacja techniczna i testowanie

Jak wspomniano wcześniej, ten krok należy do zespołu technicznego. Kierownik projektu powinien ściśle współpracować z kierownikiem ds. rozwoju oprogramowania i odpowiednimi inżynierami, aby upewnić się, że wszystkie przepływy danych, podejście do testowania i podejście do eksperymentów są zgodne. Na potrzeby tej struktury cyklu rozwoju produktu ten krok obejmuje wszystkie testy techniczne, np. upewnienie się, że usługi odpowiadają poprawnymi danymi, środowiska są renderowane zgodnie z oczekiwaniami, usługi działają z oczekiwaną dostępnością i opóźnieniem.

Krok 8: Przepływ klientów i testy akceptacji użytkownika (UAT)

Równolegle z krokiem 7 kierownik projektu przejmie kontrolę nad przepływem klientów i UAT. Zazwyczaj przeprowadzamy „bug bash”, podczas którego członkowie zespołu przechodzą przez całe doświadczenie, klikając wszystko, co mogą, aby 1) upewnić się, że doświadczenie przebiega zgodnie z oczekiwaniami — nie tylko, że przepływ jest prawidłowy, ale także opóźnienia i wszelkie problemy awaryjne są również poprawne, 2) Spróbuj przerwać doświadczenie i przejść tam iz powrotem w trakcie przepływu, tak jak zrobiłby to klient. Po zidentyfikowaniu wszystkich problemów możesz ustalić priorytety na podstawie częstotliwości i skali każdego problemu. Możesz także określić, co jest krytyczne do naprawienia przed eksperymentowaniem, a co można naprawić po doświadczeniu, ale przed uruchomieniem produkcji.

Krok 9: Ostateczne poprawki i konfiguracja eksperymentów

Do tej pory kierownik projektu powinien mieć pełną listę priorytetowych poprawek błędów i szczegółowy plan eksperymentów. Ten krok ma na celu poświęcenie czasu na dokończenie wszelkich ostatecznych modyfikacji przed rozpoczęciem eksperymentów. Ważne jest, aby przedyskutować, czy i jak należy eksperymentować. Ogólnie rzecz biorąc, przeprowadzanie eksperymentów jest pomocne, kiedy tylko jest to możliwe, ponieważ: 1) Produkują dane wyjściowe, które reprezentują „wolę klienta”. Jestem wielkim zwolennikiem pozostawienia klientowi decyzji o tym, jaki będzie produkt i czy wniesie on wartość do jego doświadczenia. 2) Opracuj stopniową atrybucję, co oznacza, że ​​wszystko, co pokażesz klientowi, będzie wykraczać poza to, czego doświadcza dzisiaj — mierzone w sposób, który przypisuje prawdziwą atrybucję. Uznanie autorstwa to złożony temat, który może być osobnym artykułem. Eksperymenty jednak automatycznie i dokładnie przypisywać atrybucję. Są złotym standardem określania przyrostowych zachowań klientów. Chcę jednak jasno powiedzieć, że eksperymentowanie wiąże się z kosztami, aw niektórych przypadkach bardzo wysokimi kosztami. Ponadto otrzymanie naprawdę istotnych statystycznie — i poprawnych — wyników nie jest trywialne. Istnieje wiele sposobów, w jakie Twój eksperyment może powodować stronniczość, a tym samym nieprawidłowe wyniki, np. problemy z uruchamianiem eksperymentu, uprzedzenia klientów, uprzedzenia dotyczące doświadczeń (np. jeśli występują problemy z opóźnieniem w leczeniu lub kontroli). Ważne jest, aby skonsultować się ze statystykami, aby upewnić się, że wyniki są dokładne. W niektórych przypadkach eksperymentowanie może nie mieć sensu. Być może wprowadziłeś już produkt w 10 z 15 krajów. A może poprawiasz wydajność swojego produktu (np. opóźnienie),

Krok 10: Eksperymentowanie, opinie klientów i analiza

Oprócz przeprowadzenia eksperymentu warto rozważyć zebranie dodatkowych opinii klientów. Teoretycznie wyniki eksperymentu powinny powiedzieć, czy klient woli to nowe doświadczenie od kontroli — zakładając, że dysponujesz wszystkimi odpowiednimi wskaźnikami, aby dokładnie zmierzyć preferencje klienta. Rejestrowanie i analizowanie każdego parametru w eksperymencie jest jednak trudne i kosztowne. Przeprowadziliśmy eksperyment w aplikacji Amazon, aby ograniczyć wrażenia klientów w oparciu o to, czy są zalogowani w aplikacji. Zalogowanie się do aplikacji znacznie poprawia doświadczenie klienta — możemy zapewnić spersonalizowane doświadczenie w oparciu o jego wcześniejsze zachowanie związane z zaangażowaniem, możemy pokazać klientowi, co kupił, historię śledzenia zamówień itp. Wszystkie metryki z eksperymentu były skrajnie pozytywne — każda metryka, na którą patrzymy, kazała nam uruchomić to nowe doświadczenie. Jednak skontaktowaliśmy się z klientami, którzy brali udział w eksperymencie, aby zrozumieć ich reakcję. Ich odpowiedź nie mogła być jaśniejsza — pogardzali nowym doświadczeniem. Ale musieli to zrobić, aby zrobić zakupy, więc byli gotowi skakać przez obręcze, aby dostać to, czego potrzebowali. Pomimo wyników eksperymentu zdecydowaliśmy się nie uruchamiać nowego doświadczenia.

Polecam również udokumentowanie wyników eksperymentu i opinii klientów. Zawsze powtarzam mojemu zespołowi, że jedyną porażką, jaką możemy osiągnąć, jest nieuczenie się. Być może nie uruchomimy nowej wersji w oparciu o wyniki eksperymentu i opinie klientów, ale uznam eksperyment za udany, jeśli dowiemy się więcej o tym, czego chcą klienci i co możemy zrobić inaczej w przyszłości. Te doświadczenia mogą następnie stanowić dane wejściowe do kroku 1 dla przyszłych funkcji produktu i nowych programów.

Poniżej znajduje się kilka dodatkowych pytań do rozważenia przez Ciebie i Twój zespół podczas tworzenia własnego cyklu rozwoju produktu oraz kilka przemyśleń/sugestii dla każdego z nich:

Kto jest właścicielem każdego etapu procesu?Aby być wszechstronnym, możesz stworzyć strukturę RASCI dla każdego etapu procesu. Te ramy określają, kto jest odpowiedzialny za każdy krok: tylko jedna osoba jest odpowiedzialna za krok i jest upoważniona do przydzielania zadań i terminów innym osobom, aby to zrobić. Osoba odpowiedzialna za zadanie to osoba odpowiedzialna za wykonanie zadania. W moich zespołach R i A to zazwyczaj te same osoby. Jest to nieco kontrowersyjne, ponieważ teoria RASCI sugeruje, że R i A powinny być oddzielnymi jednostkami. Kieruj się własnym osądem w oparciu o obecną sytuację. Osoba wspierająca wykonuje zadanie. Każdy krok powyżej ma wiele zadań i dlatego S może być wiele osób. Konsultowane osoby to osoby, które uczestniczą w zadaniu przed jego ukończeniem. Mogą to być eksperci (np Główni inżynierowie, starsi projektanci), którzy mogą przekazać informacje zwrotne przed oznaczeniem zadania jako ukończone. Osoby, które są poinformowane o zadaniu lub decyzji, to interesariusze, którzy muszą zrozumieć wyniki i wprowadzić zmiany lub aktualizacje we własnych procesach. Ogólnie rzecz biorąc, zwykle przypisuję R/A do danego kroku i to od tej osoby zależy, kto powinien być zaangażowany w ukończenie tego kroku.

Jakich powtarzających się mechanizmów używasz, aby utrzymać proces na właściwym torze?Po kroku 6 stworzymy działającą wstecz oś czasu dla każdego kluczowego etapu wdrożenia. Ta oś czasu obejmuje kluczowe kamienie milowe do ukończenia produktu, np. główne eposy techniczne (tj. agregację funkcji/usług spełniających kluczowe wymagania), przeglądy kluczowych interesariuszy, testy i eksperymenty. Następnie co dwa tygodnie lub co miesiąc wysyłamy biuletyn do wszystkich kluczowych interesariuszy, aby udostępniać aktualne informacje o statusie każdego kamienia milowego. Ponieważ jednocześnie pracujemy nad wieloma produktami, dysponujemy dodatkowym mechanizmem, który śledzi te kroki jako portfolio i umożliwia zespołowi wykrywanie zagrożeń dla dowolnego produktu na każdym etapie. Mamy co dwa tygodnie przegląd mapy drogowej, w którym sprawdzamy stan każdego produktu, a jeśli istnieje ryzyko, są one ujawniane tutaj. Jeśli uznamy to za konieczne, następnie organizujemy kolejne spotkanie w celu rozwiązania problemu, w jaki sposób wyeliminować ryzyko i/lub przywrócić projekt na oś czasu. Zespół techniczny będzie miał równoległy proces (tj. dwutygodniowe planowanie sprintu, retrospektywy, codzienne stand-upy), które ułatwią ukończenie Kroku 7.

Jakie potencjalne pułapki możesz napotkać i jak ograniczyć te zagrożenia? W trakcie tego procesu istnieje oczywiście wiele zagrożeń. Chcę podzielić się trzema najczęstszymi, z którymi się spotkałem, oraz przemyśleniami na ich temat.

1) Nie traktowanie danych jako produktu. Istnieją trzy rodzaje danych krytycznych dla każdego produktu a) Dane klienta: te dane wejściowe informują, ilu klientów angażuje się w produkt, w jaki sposób angażują się i jak głęboko. Przez klientów rozumiem każdego kluczowego interesariusza. Może to obejmować dostawców, wydawców, reklamodawców itp. b) Dane wyjściowe: zazwyczaj będą to wyniki finansowe, np. konwersje, przychody, wydarzenia długoterminowe itp. oraz c) Techniczne dane operacyjne: te dane informują o tym, jak dobrze usługi działają, gdzie występują problemy i jak wpływa to na klienta (częstotliwość i znaczenie problemu). Menedżerowie projektów powinni traktować te dane tak samo, jak samo doświadczenie — cofając się. Metryki to po prostu agregacja danych. Jakie wskaźniki poinformują, czy doświadczenie jest udane? Czy środowisko renderuje się zgodnie z oczekiwaniami? Następnie cofasz się od zdefiniowania kryteriów sukcesu na podstawie potrzebnych danych, jak często ich potrzebujesz i jakich fragmentów danych potrzebujesz (według kraju, segmentu klientów, typu urządzenia, systemu operacyjnego itp.), aby zrozumieć, w jaki sposób różni klienci reagują na produkt. Następnie upieczesz czas, aby zarejestrować poprawne dane, zbudować potoki w celu agregacji danych i zbudować pulpity nawigacyjne, aby wyświetlić metryki. Zbyt często produkt zaczyna działać, pojawia się problem i wszyscy patrzą na siebie nawzajem, aby uzyskać dane, aby lepiej zrozumieć, co dzieje się z klientem. Aby tego uniknąć, traktuj dane tak samo, jak doświadczenia klientów, i miej dedykowane strumienie pracy do prawidłowego rejestrowania i udostępniania danych.

2) Niedoszacowanie kosztów koordynacji. Ogólnie rzecz biorąc, wszyscy jesteśmy okropni w szacowaniu, ile czasu zajmie wykonanie zadania. Dodaj to do wszystkich zadań, a produkt będzie znacznie opóźniony. Daniel Kahneman i Amos Tversky nakreślili błąd planowania w swojej książce „Thinking Fast and Slow”, w której wyszczególnili swoje argumenty i dowody na to, że ludzie mają tendencję do niedoceniania ilości czasu potrzebnego do wykonania przyszłego zadania, częściowo z powodu polegania na nadmiernym optymistyczne scenariusze wydajności. Z mojego doświadczenia wynika, że ​​ryzyko znacznie wzrasta, jeśli Twój produkt opiera się na produkcie innego zespołu lub jest wkładem w produkt innego zespołu, tj. jesteś zależny od wkładu innego zespołu lub Twój produkt jest wkładem innego zespołu, jest całkiem możliwe, że pojawią się problemy, a rozwiązanie tych problemów może zająć dużo czasu. Spotkaliśmy się z tym niezliczoną ilość razy, a każda sytuacja była nieco inna. Kluczem do wszystkich tych działań jest najpierw określenie, gdzie mogą wystąpić problemy, a następnie uzyskanie jak najmniejszego opóźnienia między zidentyfikowaniem problemu a przekazaniem go kierownictwu (w razie potrzeby) w celu uzyskania rozwiązania. Strategia i protokół eskalacji są warte osobnego artykułu, ale na wysokim poziomie jedyne, czego potrzebujesz, to: czy obie strony mają pełne informacje? Jeśli nie, zdobądź to, czego potrzebujesz tak szybko, jak to możliwe, i podziel się tym tak szybko, jak to możliwe. Jeśli masz pełne informacje i nadal się nie zgadzasz, eskaluj. Zminimalizuje to martwy czas niewnoszący wartości dodanej i dostosuje oczekiwania. a następnie mieć jak najmniejsze opóźnienie między zidentyfikowaniem problemu a przekazaniem go kierownictwu (w razie potrzeby) w celu uzyskania rozwiązania. Strategia i protokół eskalacji są warte osobnego artykułu, ale na wysokim poziomie jedyne, czego potrzebujesz, to: czy obie strony mają pełne informacje? Jeśli nie, zdobądź to, czego potrzebujesz tak szybko, jak to możliwe, i podziel się tym tak szybko, jak to możliwe. Jeśli masz pełne informacje i nadal się nie zgadzasz, eskaluj. Zminimalizuje to martwy czas niewnoszący wartości dodanej i dostosuje oczekiwania. a następnie mieć jak najmniejsze opóźnienie między zidentyfikowaniem problemu a przekazaniem go kierownictwu (w razie potrzeby) w celu uzyskania rozwiązania. Strategia i protokół eskalacji są warte osobnego artykułu, ale na wysokim poziomie jedyne, czego potrzebujesz, to: czy obie strony mają pełne informacje? Jeśli nie, zdobądź to, czego potrzebujesz tak szybko, jak to możliwe, i podziel się tym tak szybko, jak to możliwe. Jeśli masz pełne informacje i nadal się nie zgadzasz, eskaluj. Zminimalizuje to martwy czas niewnoszący wartości dodanej i dostosuje oczekiwania. zwiększać. Zminimalizuje to martwy czas niewnoszący wartości dodanej i dostosuje oczekiwania. zwiększać. Zminimalizuje to martwy czas niewnoszący wartości dodanej i dostosuje oczekiwania.

3) Kultury niechętne złym wiadomościom i/lub pozbawione mechanizmów ujawniania zagrożeń. Słyszałem, jak ludzie określają status celu jako „arbuza”, tj. zielonego na zewnątrz i czerwonego w środku. To silny sygnał, że kultura jest niechętna ujawnianiu zagrożeń i problemów. Chociaż z pewnością naturalną ludzką tendencją jest niechęć do przekazywania złych wiadomości, nierozwiązywanie tych problemów może spowodować znacznie większy ból na drodze. Trudno jest zbudować kulturę, która nagradza ujawnianie złych wiadomości, a bardzo łatwo jest zbudować coś przeciwnego. Z punktu widzenia członka zespołu każda wskazówka, że ​​ujawnienie złych wiadomości zostanie odebrane negatywnie, doprowadzi do znalezienia sposobów na ukrycie problemów — lub — znalezienie danych, które przedstawiają bardziej różowy obraz niż to, co dzieje się w rzeczywistości. Rozwiązanie tego problemu jest podobne do rozwiązywania innych wyzwań kulturowych: przywództwo musi dawać przykład i stale go wzmacniać. Kultura jest budowana cegiełka po cegiełce, a każda cegiełka jest przełomowym momentem, w którym lider poświęca czas na wzmocnienie i wyjaśnienie, dlaczego decyzje są podejmowane w taki sposób. W takim przypadku liderzy muszą nagradzać członków zespołu za ujawnienie trudnych sytuacji i przypominać im, dlaczego jest to ważne. Liderzy muszą „być na łodzi” z członkami swojego zespołu, pomagając im w rozwiązywaniu problemów. Być może nadszedł czas, aby porozmawiać o tym, dlaczego problem pojawił się późno lub w niepełny sposób. Ale w podobny sposób jest to inny problem do rozwiązania. Nie gra w obwinianie i wstyd. gdzie każda cegiełka jest przełomowym momentem, w którym lider poświęca czas na wzmocnienie i wyartykułowanie, dlaczego decyzje są podejmowane w taki sposób, w jaki są. W takim przypadku liderzy muszą nagradzać członków zespołu za ujawnienie trudnych sytuacji i przypominać im, dlaczego jest to ważne. Liderzy muszą „być na łodzi” z członkami swojego zespołu, pomagając im w rozwiązywaniu problemów. Być może nadszedł czas, aby porozmawiać o tym, dlaczego problem pojawił się późno lub w niepełny sposób. Ale w podobny sposób jest to inny problem do rozwiązania. Nie gra w obwinianie i wstyd. gdzie każda cegiełka jest przełomowym momentem, w którym lider poświęca czas na wzmocnienie i wyartykułowanie, dlaczego decyzje są podejmowane w taki sposób, w jaki są. W takim przypadku liderzy muszą nagradzać członków zespołu za ujawnienie trudnych sytuacji i przypominać im, dlaczego jest to ważne. Liderzy muszą „być na łodzi” z członkami swojego zespołu, pomagając im w rozwiązywaniu problemów. Być może nadszedł czas, aby porozmawiać o tym, dlaczego problem pojawił się późno lub w niepełny sposób. Ale w podobny sposób jest to inny problem do rozwiązania. Nie gra w obwinianie i wstyd. Być może nadszedł czas, aby porozmawiać o tym, dlaczego problem pojawił się późno lub w niepełny sposób. Ale w podobny sposób jest to inny problem do rozwiązania. Nie gra w obwinianie i wstyd. Być może nadszedł czas, aby porozmawiać o tym, dlaczego problem pojawił się późno lub w niepełny sposób. Ale w podobny sposób jest to inny problem do rozwiązania. Nie gra w obwinianie i wstyd.