Q&A – pytania o analizie w produktach

Jakie masz pytania w temacie analizy w produktach?

Zbierałam je w trakcie ostatniego live’a, pytałam w mailu, ale też mam sporo pytań czekających od zeszłego roku. Dzięki za wszystkie z nich.

Q: Jaka jest różnica między produktem zwinnym a rynkowym?

Pytanie: Cześć. Mam wrażenie, że rozgraniczenie między produktem w rozumieniu zwinnym i produktem w rozumieniu rynkowym nie wybrzmiało wystarczająco wyraźnie. Warto o tym wspomnieć choćby w kontekście wyceny:) – Kon rad

Bardzo dobra uwaga, dzięki Konrad.

Produkt w sensie zwinnym. Przywykliśmy dzięki Scrumowi do mówienia o PRODUCT Ownerach, PRODUCT backlogach, PRODUCT incrementach. Aby pracować przy “produkcie” wystarczy zatem pracować w scrumie, bez względu na to, nad czym dokładnie pracujemy.

Produkt w sensie rynkowym. Oznacza, że wykonujemy produkt, który będzie kupowało wielu klientów. Takimi produktami są np. baton Snickers, telefon iPhone 11 Pro, lampa Ikea Sigvard. Robimy coś raz, a potem sprzedajemy wielu klientom. Ze świata IT produktami są np. Slack, MS Excel, Enterprise Architect. Mają one postać na tyle ogólną, żeby zaspokoić potrzeby wybranych segmentów klientów. Firma nie zmienia działania MS Excela w odpowiedzi na każde indywidualne żądanie każdego klienta. Excel jest jaki jest. Możesz go wziąć lub nie (ewentualnie skonfigurować, zrobić szablony, nie wykorzystać funkcji,z którymi nie jest Ci po drodze).

Dla odróżnienia mamy usługi świadczone przez firmy. Są to rzeczy, które możemy zrobić w określonym czasie z wykorzystaniem wiedzy, narzędzi czy czasu posiadanego przez firmę. Firma może realizować zamówienia na wyprodukowanie czegoś – tzw. oprogramowanie na zamówienie.

Wskazówka Kondara ze zwróceniem uwagi na sposób rozliczania pomoże tu w rozróżnieniu. Jeśli klient płaci za wykonywane godziny zespołu czy firmy, to prawdopodobnie mamy do czynienia z projektem. Zazwyczaj projekty wycenia się indywidualnie, tworzy plan, harmonogram lub szacowanie (dla mniejszych zmian).

Koszty produktu rozkładają się na wielu klientów, zazwyczaj mamy do czynienia z cennikiem znanym na rynku. Czasem produkt może być bardziej skomplikowany, zawierać wiele wariantów konfiguracji, czy wyposażenia, jak na przykład w przypadku samochodów, więc cenę trzeba opracować pod daną konfigurację produktu. Nadal mówimy jednak o produkcji masowej.

Q: Czy rozwój produktu dotyczy modułu czy całego produktu?

Bardzo dobre pytanie. Często w IT mówimy o produkcie mając na myśli kawałek oprogramowania, którym zarządza product owner, dla którego pracuje zespół nad product backlogiem. Czy to znaczy, że jest to produkt w rozumieniu rynkowym? Nie.

Powstaje wtedy pytanie, czy to, co produkujesz, sprzedaje się klientom czy jest to część czegoś większego, co dopiero pojawia się w ofercie? Dla komponentów trudno określić strumienie przychodów, bo ten moduł nie jest sam w sobie sprzedawany, nie generuje wartości w oderwaniu od reszty.

Rozwój produktu dotyczy całego produktu w sensie rynkowym, bo to on przechodzi przez cykle: wprowadzanie na rynek, wzrost, dojrzałość, spadek sprzedaży.

Komponenty same w sobie też mogą stanowić produkty. Na przykład w rowerze mamy koła. Jeśli te koła są sprzedawane osobno jako oddzielny produkt i ludzie mający rowery po prostu dokupują takie koła, możemy mówić o kole jako osobnym produkcie. Ale jeśli głównie koła te sprzedaje się “w pakiecie” z konkretnymi modelami rowerów, to wtedy nie interesują nas “podzespoły”, a patrzymy na sprzedaż całego produktu.

Oczywiście części roweru, tak samo jak części oprogramowania można łączyć w inne konfiguracje. Z innego połączenia części mogą powstawać inne całości, które będą prezentowane klientom na rynku jako osobny produkt.

Q: Czy zbieranie informacji zwrotnej od klientów jest techniką omawianą w Guide to Product Ownership Analysis?

Zbieranie informacji zwrotnej od klientów to podstawa. Ten aspekt nie jest ujęty w jedną tylko technikę, ale znajdziemy go w kilku miejscach. Poświęcony jest temu cały obszar wiedzy “Cultivate customer intimacy” – kultywuj bliską współpracę z klientem. “Make an impact” mówi o dobrym dopasowaniu produktu do klienta. W “deliver often” kładziemy nacisk na częstym dostarczaniu fragmentów produktu, a wszystko to po to, aby uzyskiwać od klientów informację zwrotną. “Learn fast” pozwala nam oceniać feedback od klientów w sposób bardziej mierzalny, a “Obsessed with value” dba o to, by pojawiała się wartość dla klientów.

Można powiedzieć, że całe opracowanie jest przesiąknięte informacją zwrotną od klientów.

W wielu technikach również wpleciony jest aspekt informacji zwrotnej od klientów. Pozwalają na to: gry współpracy, mapa ścieżki użytkownika/klienta (customer journey map), analiza decyzji, mapa empatii, grupy focusowe, projektowanie skoncentrowane na interakcji z człowiekiem, job stories, analiza kano, MVP, persona, definicja problemu, product market fit, przeglądy, value modelling, value proposition canvas. Aby poprawnie i rzetelnie wykonać te techniki bardzo wartościowym lub wręcz niezbędnym wkładem jest informacja zwrotna od klientów.

Q: Ile trwają fazy cyklu życia produktu?

Nie da się tego jednoznacznie określić. Zależy to bardzo od dynamiki rynku i cech produktu. Niektóre produkty zmienia się jak rękawiczki – dziś jest fajny, jutro się nudzi. Można go zainstalować i odinstalować jednego dnia, np. narzędzie do edycji zdjęć na telefonie. Szybko zmienia się dynamika wzrostu, zakupów, pojawia się nowa konkurencja. Z miesiąca na miesiąc czy kwartału na kwartał można obserwować zmiany w dynamice zakupów.

Inne działają w środowisku potrzebującym więcej czasu, np. system do rocznych rozliczeń podatkowych, czy system do planowania lotów (przygotowania i zmiany systemów w dużych organizacjach potrafią trwać miesiącami, w niektórych dużych przedsięwzięciach nawet latami). Zanim po rynku rozniosą się wieści o produkcie, zanim pojawiają się pierwsze polecenia, zanim niezadowoleni wycofają się z systemu – miną lata, jak nie dekady.

Q: Czy praca nad aplikacją jest projektem czy produktem?

Pytanie: Czy praca analityczna w obszarze nad aplikacją mobilną oraz web, rozumiemy w kontekście projektu czy produktu? – Marcin. W.

Nie ma znaczenia czy pracujemy nad aplikacją mobilną, webową, koncepcją, makietą czy czymkolwiek innym. Ważniejsze jest w jakim trybie pracujemy.

Projekt to unikatowa inicjatywa ograniczona w czasie dostarczająca określony rezultat. Produkt rozwijamy w sposób ciągły. Jeśli pracujesz w środowisku takim, że aplikacja jest wytwarzana i przekazywana klientowi, a projekt wtedy uznajemy za zakończony, to pewnie pracujecie w układzie projektowym. Ta inicjatywa ma miejsce tylko raz i kończy się.

O ciągłym rozwoju produktu mówimy wtedy, kiedy rozwijana aplikacja zostaje z nami. Pracujemy nad kolejnymi wydaniami, udoskonalamy ją, coraz lepiej dostosowujemy do potrzeb rynku, odbiorców, użytkowników.

Często można to rozpoznać po tym komu sprzedajemy aplikację – kto ją odbiera. Czy było to indywidualne zamówienie dla danego klienta/organizacji? Wtedy raczej powiemy o projekcie. Kiedy samodzielnie rozwijamy aplikację, z której korzysta wielu klientów, a nazwisk czy nazw firm jeszcze nie znamy, do dołączą czy kupią produkt później – wtedy mówimy o produkcie.