Product Manager vs Product Owner (Polski)

To ciekawe pytanie, które wymaga czasu na rozpakowanie. Przyjrzyjmy się, skąd wzięły się te terminy i dyscypliny i jak wyjaśniają je niektóre wspólne ramy.,

Kiedy zaczynałem karierę, nazywano mnie analitykiem biznesowym. Zrobiłem bardzo mało „analiz biznesowych”, jak przyjrzelibyśmy się temu w tradycyjnych firmach IT. Szczerze mówiąc, zrobiłem bardzo niewiele z tego, czego teraz uczę jako Zarządzanie produktem. Miałem za zadanie zebrać wymagania ze sprzedaży, wymyślić rozwiązanie, zaprojektować je, a następnie wysłać dokument specyfikacji do rozwoju do budowy.

pracowałem jako analityk biznesowy w bankach i innych firmach świadczących usługi finansowe. Nie zostałem nazwany menedżerem produktu, dopóki nie wyciągnąłem z tego i nie wylądowałem w startupie., To była ta sama praca, którą robiłem wcześniej, ale teraz miała inną nazwę. Podobało mi się to imię. „Product Manager” wydawał się mieć do tego powagę, a kiedy spojrzałem na inne firmy technologiczne w Dolinie, widziałem wyraźną ścieżkę kariery wyrytą dla mnie, podczas gdy analitycy biznesowi byli różni w każdej firmie.

o określeniu Product Owner słyszałem dopiero po latach. Kiedy pierwszy raz usłyszałem ten termin, zapytałem kogoś, co on oznacza. Powiedzieli mi, że to to samo, co menedżer produktu, ale to termin używany w Scrum., Scrum używaliśmy od lat, ale wciąż nazywano mnie Product Managerem, więc fakt, że będą one wymienne, miał dla mnie sens. Rzadko o tym myślałem.

to było, dopóki nie miałem pierwszego doświadczenia w nauczaniu zarządzania produktem w firmie przy użyciu bezpiecznego frameworka. Robiłem warsztaty dla bardzo dużego banku, kiedy jeden z uczestników zadzwonił.

„uczysz nas rozmawiać z użytkownikami, ale ja jestem właścicielem produktu. Product Manager rozmawia ze wszystkimi użytkownikami i mówi nam, jakie są wymagania., Cały mój czas poświęcam na pisanie historii użytkowników i pracę z zespołem nad rozwiązaniem. Jestem zdezorientowany.”

właśnie wtedy zacząłem grzebać w różnicach między tymi dwoma rolami i w tym, jak uczą ich różne filozofie. W celu zrozumienia, jak się tutaj

Zarządzanie produktem można prześledzić do 1931 roku. Hewlett Packard była jedną z pierwszych firm technologicznych, które wdrożyły tę pracę i zorganizowały się według produktów w latach 40., Większość firm z Doliny Krzemowej miała menedżerów produktów od samego początku, a wielu moich przyjaciół, którzy pracowali tam w latach 80. i 90., było rzeczywiście Product Managerami. Tak więc ta dyscyplina nie jest nowa, ale szybko się rozwija, ponieważ coraz więcej firm zaczyna przenosić się do organizacji programistycznych i zaczyna organizować się wokół produktów.

Scrum pojawił się na scenie tuż przed napisaniem manifestu Agile w 2001 roku. Wprowadził pojęcie Product Ownera. Była to osoba, która była pełnomocnikiem klienta i mówiła deweloperom o wymaganiach dotyczących tego, co należy zbudować., W pierwszych dniach, kiedy wielu twórców tych procesów pracowało jako konsultanci w firmach, Product Owner był klientem-wewnętrzną osobą w firmie, która siedziała z zespołem i priorytetowała zaległości w pracy. W rzeczywistości cele szkoleniowe z 2017 roku dotyczące certyfikacji certyfikowanego Scrum Product Owner przez Scrum Alliance: „uczą, że rolę Product Ownera zazwyczaj odgrywa klient lub przedstawiciel klienta, taki jak menedżer produktu.,”

kiedy spojrzysz na rolę Product Ownera w większości literatury Scrum, ich trzy główne obowiązki obejmują:

• Zdefiniuj zaległości produktu i twórz praktyczne historie użytkowników dla zespołów programistycznych. (Kto tworzy historie użytkowników różni się w zależności od szkolenia Scrum)
• Akceptuj ukończone historie użytkowników, aby upewnić się, że praca spełnia kryteria.,

podczas gdy program nauczania zmienia się między nauczycielami a organizacjami, są to rzeczy, na których głównie koncentrują się podczas dwudniowych kursów certyfikujących właścicieli produktów. Podczas gdy Scrum ma wiele informacji na temat procesów i rytuałów, co robić jako właściciel produktu, pozostawia wiele pytań, które są ważne dla tworzenia udanych produktów bez odpowiedzi. Te głównie skupiają się wokół „skąd wiemy, że budujemy właściwą rzecz?”

tutaj wkracza Zarządzanie produktem., Dobry Product Manager nauczy się, jak ustalać priorytety pracy w oparciu o jasne cele zorientowane na wyniki, Jak odkrywać i potwierdzać rzeczywistą wartość dla klienta i biznesu oraz jakie procesy są potrzebne, aby zmniejszyć niepewność, że produkt odniesie sukces na rynku.

bez tego doświadczenia w zarządzaniu produktem, ktoś może skutecznie przejść przez ruchy Product Owner roli w Scrum, ale nigdy nie może być skuteczne w upewnieniu się, że budują właściwą rzecz.,

Jeśli odbierzesz swój zespół Scrum, jeśli odbierzesz Scrum jako proces dla swojej organizacji, nadal jesteś menedżerem produktu. Zarządzanie produktem i Scrum dobrze ze sobą współpracują, ale zarządzanie produktem nie jest zależne od Scrum. Może i powinna istnieć w każdej strukturze lub procesie.

Ostatnio przyszedł do mnie Product Owner, którego programiści zostali przeniesieni do innej części organizacji, ponieważ obawiali się, że nie mogą już być product person w tej firmie. Cała ich tożsamość zdawała się zależeć od zespołu programistów.,

jako menedżer produktu Twoje role i obowiązki będą się zmieniać w zależności od kontekstu i etapu produktu. Bez zespołu Scrum lub z mniejszym zespołem możesz wykonywać więcej strategii i walidacji dzięki wykrywaniu problemów w produkcie, który nie został jeszcze zdefiniowany. Z zespołem Scrum możesz być bardziej skoncentrowany na realizacji rozwiązań. Jako menedżer menedżerów produktów możesz przewodzić strategii dla większej części produktu i trenować swoje zespoły, aby odkrywać i dobrze wykonywać.,

SAFe framework uczy tego inaczej I myślę, że jest to jeden z najsłabszych punktów w całym frameworku. W SAFe menedżerowie produktów są menedżerami właścicieli produktów i są odpowiedzialni za zewnętrzne interakcje i pracę. Rozmawiają z klientami, określają wymagania i zakres produktów, które mają być budowane, i przekazują to właścicielom produktów. Właściciele produktów są wewnętrzni, definiują komponenty rozwiązania i współpracują z programistami, aby je wysłać.,

trenowałem dziesiątki drużyn, które używają bezpiecznego i nigdy nie widziałem, aby to działało dobrze. Właściciele produktów są odłączeni od swoich użytkowników i niezdolni do tworzenia skutecznych rozwiązań dla nich, które naprawdę rozwiązują ich problemy, ponieważ nie rozumieją problemów dobrze., Menedżerowie produktów zasadniczo ograniczają wymagania do nich, a zespoły nie mogą udowodnić, czy są to właściwe rzeczy do budowania, czy nie. Nikt nie pracuje nad walidacją.

wysłuchałem wielu argumentów, że właściciele produktów nie mają czasu na wykonywanie obu ról. W obecnym kontekście to prawda. Właściciele produktów, z którymi rozmawiam, spędzają 40 godzin tygodniowo na pisaniu historii użytkowników. W tym momencie musisz zadać sobie pytanie, czy te historie użytkowników są w ogóle wartościowe? Przed czym je ustalają? Skąd wiedzą, że to rozwiąże problem?,

Jeśli jedna osoba spędza tyle czasu na pisaniu historii użytkowników co tydzień, co tydzień, wpadasz w pułapkę budowania — koncentrując się na ilości wydawanych przedmiotów, a nie na jakości.

dzięki dobrym ramom strategicznym i bezwzględnemu ustalaniu priorytetów wokół kilku kluczowych celów, jedna osoba może skutecznie rozmawiać z klientami, rozumieć ich problemy i pomagać w definiowaniu rozwiązań z zespołem. Nawet Prezes Zarządu Scrum.org zgadza się, że może tak być, choć, jak się wydaje, żałośnie., Scrum Inc twierdzi również, że właściciel produktu powinien spędzać połowę czasu na rozmowach z klientami, a połowę na pracy z zespołem. Nie jestem w 100% za tym podziałem, ale kierunek jest dobry. Ilość pracy zewnętrznej vs wewnętrznej zmieni się w zależności od dojrzałości i sukcesu produktu. Nigdy nie powinieneś wykonywać tej całej pracy na raz.,

uczę moich klientów, że Product managerowie na wyższych stanowiskach (VPs lub Product Leads lub middle managerowie) koncentrują się na definiowaniu wizji i strategii dla zespołów w oparciu o badania rynku, zrozumienie celów i strategii firmy oraz spojrzenie na obecny stan sukcesu ich produktów. Menedżerowie produktów bez zespołów Scrum lub z mniejszymi zespołami (na przykład Projektant UX i jeden deweloper) pomagają w walidacji i przyczyniają się do realizacji tej strategii dla przyszłych produktów. Po zatwierdzeniu kierunku tworzymy większe zespoły Scrum wokół tych osób i opracowujemy rozwiązania.,

ważne jest, aby mieć tę elastyczność w wielkości zespołu, jak również w zależności od etapu produktu. Jeśli przekażesz menedżerowi produktu obszerne zaległości Zespołu Scrumowego, aby nadal je wypełniał, gdy jesteś w trybie discovery, zachowa on te zaległości. Ale będą również rozdarte między utrzymaniem pracy płynącej do programistów i próbą wykonania pracy w celu potwierdzenia kierunku. W rezultacie żadne z nich nie jest dobrze zrobione.

Jeśli chcesz tworzyć produkty, które tworzą wartość dla Twojej firmy i klientów, potrzebujesz dobrych podstaw zarządzania produktami w swojej firmie., Jeśli chcesz ścieżki kariery dla swoich ludzi, musisz dać im tę podstawę, aby mogli rozwijać się na bardziej starszych stanowiskach. Przypomnij więc swoim ludziom, że wszyscy są Product Managerami. Może przez większość dni pełnią rolę Product Ownera w zespole Scrum, ale nadal potrzebujemy ich do myślenia jak Product Manager i potwierdzania, że budujemy właściwe rzeczy.

— —

Melissa Perri jest dyrektorem generalnym Produx Labs, firmy doradczej, która pomaga organizacjom uczyć się i stosować dobre praktyki zarządzania produktami i przywództwa produktowego., Prowadzi szkołę online dla product managerów w Product Institute oraz dla product leaderów w CPO Accelerator. Jest starszym wykładowcą w Harvard Business School.

To było pierwotnie zamieszczone na melissaperri.com