Продакт менеджер vs. продакт овнер? Історія продуктової біполярочки
Всім привіт. Мене звати Марк Опанасюк, я є автором продуктового телеграм каналу Product Market Fat та ведучим однойменного подкасту про продакт менеджмент. Ця публікація — це мої думки та вільний переказ статті Anthony Murphy про “The Collision of Product Management and Product Ownership”. Також, про щось подібне я з Іваном Чайкою говорили на подкасті: PMF S2 E1 — Як З’явилася І Еволюціонувала Професія Продакт Менеджера?
Вступ
Я став продактом в 2018 році завдяки навчанню в Genesis IT School та подальшій роботі на продуктових позиціях в Genesis — business analyst acting as product owner, потім став product manager (коли наш продакт в Genesis Media пішов і звільнилося місце — додалося ще трохи роботи). У нас вся продуктова робота велася по скраму, і наш СТО — Слава Одиноков радив мені багато різного прикольного аджайльного контенту — типу Scrum Guide, Scrum and XP from Trenches, Evidence Based Management, Agile Manifesto Principles.
Моє розуміння скраму теж мінялося — з буквального розуміння та формального виконання всіх ритуалів і вимог скрам фреймворку до більш глибоко розуміння принципів та ідей agile, які були в його основі.
З самого початку в мене були питання до неймінгів — Product Owner vs. Product Manager. Genesis позиціонував продакт менеджерів як CEO of product, розвиваючи логіку знаменитого ессе від A16Z — який відповідає за його успіх, в тому числі і за команду, яка його будує. А продакт овнер, це лише член скрам команди, який відповідає за її беклог — це не CEO продукту — це більш низька роль. Але чи це вірна інтерпретація?
Працюючи в Genesis та потім в EPAM, я ще нормально вчив продуктову теорію — поскладав різні продуктові сертифікації: Data-Driven Product Management (by GoPractice), PSM I, PSPO I, PSPO II, SAFe PO/PdM, CPM by AIPMM, та й інші. А потім минулого року я читнув статтю від Anthony Murphy та мав з ним дзвінок-консультацію. Його думки співпали з моїми думками пазликами про продакт менеджмент в єдину картину. Він дав згоду на перевикористання та переклад статті. Про цю колізію ролей Product Manager vs. Product Owner і є ця публікація!
Перші ідеї скраму, як альтернативу ватерфолу, були описані ще в 1986 році у статті “The New New Product Development Game”. Agile Manifesto був написаний в 2001 році. Скрам був вперше системно впроваджений в 1993 році та описаний в 1995 Джефом Сазерлендом та Кеном Швабером. Вони створювалися в часи, коли waterfall та PRINCE2 в розробці були нормою, а софт створювався та записувався на фізичні носії, поширювався офлайновими способами (диски, флешки, дискети). Ідеї continuous integration / continuous deployment тоді навіть не існували, інтернет був у зародковому стані, а смартфони ще навіть не були концепцією. Принципи, що лежали в основі аджайл маніфесту та скраму, були в спрямовані на виправлення організаційних косяків в процесах при тогочасній розробці та мали мету полегшити роботу розробникам.
З часу створення Скраму, як фреймворку, з девяностих він та його ролі — Скрам Майстр та Продакт Овнер стрімко набули популярності. Наразі Скрам це досі самий популярний фреймворк:
З появою Скраму багато тогочасних Продакт Менеджерів замислилися над тим, чи варто їм бути Продакт Овнерами, і так само багато Продакт Овнерів почали замислюватися над тим, яке місце вони займають відносно своїх колег Продакт Менеджерів. А відповідь лежить десь між минулим, теперішнім і майбутнім цих двох ролей — як вони з’явилися і з багатьох причин еволюціонували до сьогодення.
Звідкіля взялися продакт менеджери?
Більш менш точно, можна стверджувати, що історія продакт менеджменту бере початок у 1931 році, коли Ніл МакЕлрой написав коротке мемо про “Brand Men” та їх роль в просуванні та управлінні тогочасних офлайнових продуктів. Випереджаючи свій час, він також описав, що найкращі Brand / Product Managers роблять це шляхом:
- проведення експериментів та
- взаємодії з кінцевими користувачами.
Трішки пізніше в 40-хх, будучи радником у Стенфордському університеті, Ніл МакЕлрой вплинув на двох підприємців — Білла Х’юлетта та Девіда Паккарда — які впровадили ідеологію “Brand Men” в свою компанію і зробили процеси прийняття рішень максимально наближені до взаємодії з споживачами. Вони побудували компанію, яку ми знаємо сьогодні як Hewlett-Packard. Протягом наступних 50ти років Hewlett-Packard стабільно зростали щороку біля +20% year-over-year.
Як випливає з назви Brand Man, витоки продакт-менеджменту були з маркетингу. Здебільшого обмежуючись цією сферою, Продакт Менеджери того часу зосереджувалися на продажах продукту, використовуючи рекламні, цінові та маркетингові важелі, залишаючи розробку продукту технологам та інженерам. Цей поділ продовжувався, і з розвитком технологій та методологій розробки, таких як PRINCE2. Продакт-менеджери збирали вимоги та потім передавали їх оформлені в якусь Product Requirements Documentation “через паркан” технологічним командам, які потім вже створювали продукт відповідно до цих специфікацій — smells like a waterfall.
Такий поділ можна спостерігати і сьогодні в багатьох компаніях, де менеджери продуктів розглядаються як ті, хто “знає” ринок і клієнтів, а ІТ-відділ чи команди розробників з аналітиками — це делівері машина, яка виконує їхні запити згідно вимог.
Цей підхід працював більш менш добре, коли цифрові продукти реалізовувалися офлайновими способами (диски, дискети, флешки), нечасто змінювалися, але з приходом цифровізації та інтернету, складність та швидкість розробки зростала. Потреба у швидкому отриманні та впровадженні зворотного зв’язку від користувачів та експериментах стала першочерговою — це вимагало нового мислення і нового способу створення продуктів. Це і стало поштовхом до розвитку Scrum та аджайл фреймворків.
Як вигадали Scrum та роль Product Owner?
Намагаючись вирішити організаційні проблеми відірванності та дистанції між тими, хто створює продукт, і тими, хто спілкується з клієнтами, Джефф Сазерленд і Кен Швабер запропонували новий спосіб створення продуктів — структуру, яка сприяє швидким циклам зворотного зв’язку — вони створили те, що ми знаємо сьогодні як Scrum.
Скрам переосмислював традиційну роль Продакт Менеджера, та розширював сферу застосування цієї ролі, ще більше наблизивши її до команди та взаємодії з клієнтами — так з’явилася роль Продакт Овнера. Ось пряма цитати Джефа Сазерленда:
“When I created the Product Owner role, I gave it more responsibility for product strategy and revenue generation than a Product Manager. I specifically pulled the best Product Manager our Easel Corporation had out of Product Marketing and retrained him. It also has more responsibility for directly working with engineering 50% of the time to assure that the product fits customer needs. So it is a broader role in that sense but usually does not include Product Marketing (sales collateral, shows) or long term Competitive Analysis although it needs to support those efforts. The goal was to eliminate the common Product Manager failing of throwing requirements over the wall only to have the customer receive something that they didn’t want.” — Jeff Sutherland
Scrum набув ще більшої популярності після 2001 року, коли група з сімнадцяти топових девелоперів того часу створила Agile Manifest. З появою інтернету, смартфонів та стрімкого технічного прогресу, багато старих великих компаній, які не змогли адаптуватися, перестали існувати, а ті, що залишилися, відчайдушно шукали способу трансформуватися.
В результаті, тисячі компаній по всьому світу визнали необхідність гнучкості та адаптації до нових умов, і ці компанії вскочили на рельси аджайлу, найняли всіляких сертифікованих аджайльних тренерів, коачів, скрам майстрів, створили нові посади керівників вищої ланки, які відповідали за інновації та трансформації, такі як директор з цифрових технологій (Chief Digital Officer), директор з інновацій (Chief Innovation Officer) тощо, і оголосили світові про те, що вони проходять “трансформацію”. Але сам процес трансформації, на практиці, навідміну від гарних пресс-релізів, виглядав не так гарно і красиво. Сова на глобус налазила, але дуже тяжко…
Поширення аджайлу та аджайл трансформацій призвело до того, що більшість сучасних тайтлів Продакт Овнер юзаються в організаціях, які є лише дотичні до продуктової айтішки — це традиційні ентерпрайзи в різних доменах, які пройшли діджитал трансформацію і мають власні айті служби чи департаменти. На жаль для Продакт Овнерів, багато з цих трансформацій або провалилися, або прижилися у вигляді спотвореної версії ролей і буквального виконання фреймворку Scrum. Замість продуктових команд, які разом з продакт овнером дійсно несуть відповідальність за продукт, виникли численні feature teams, які пилять щось і навіщось з причин відомих лише ключовим стейкхолдерам або топ-менеджменту. У більшості продакт овнерів зв’язані руки, через величезну кількість залежностей, обтяжені організаційною складністю та десятиліттями технічної заборгованості. При спробі вирішити ці проблеми або насправді спробувати стати власником продукту, багато хто наштовхується на опір, а спроби будь-яких bottom-up позитивних продуктових змін часто губилися на менеджменті середньої ланки. Рідко який продакт овнер дійсно міг еволюціонувати до значної впливової фігури в таких організаціях.
Дивна фігня відбувалася з компаніями, які активно впроваджували в себе Scrum. На відміну від того, що, початково очікували Джефф і Кен, роль Продакт Овнера в більшості випадків не замінювала роль Продакт Менеджера, а скоріше розглядалася як додаткова роль для співіснування з колегою Продакт Менеджером.
Враховуючи, що багато з цих компаній вже мали традиційну роль Продакт Менеджера, який був доволі віддалений від розробки, хибне уявлення про те, що скрам і аджайл призначені лише для ІТ та розробників, дозволило компаніям виправдати залишення традиційної функції Продакт Менеджера фактично без змін.
Багато компаній ввели додатково роль продакт овнера поруч з вже існуючою ролюю продакт менеджера, але автори скраму Джеф та Кен зовсім не те мали на увазі, коли придумали скрам...За іронією долі, це призвело до того, що в багатьох великих компаніях Продакт Овнер фактично став пішаком для Продакт Менеджера, який конвертує вимоги від Продакт Менеджера в щось зрозуміле для розробників (описує скоуп, щоб він був Ready for Development).
Продакт Овнер став ще однією передаточною ланкою в дуже довгому ланцюгу, який відділяє кінцевого користувача від тих, хто насправді створює продукт.
Десь приблизно ось так, ринок зараз розуміє різницю між продакт менеджерами та продакт овнерами. Хоча задум авторів скрам гайду був, що продакт менеджери будуть виконувати роль продакт овнерів для команд по скрам фреймворку, як частина їх розширених функцій.Уявлення про те, що Продакт Овнер — це виключно член ІТ-команди по скраму, звузило розуміння того, яку роль він може відігравати у життєвому циклі продукту. Наприклад, на ранніх стадіях розробки продукту ви можете визначати відповідність продукту ринку, можливо, стратегію продукту або проводити дослідження ринку — все це має вирішальне значення для створення успішних продуктів, але не стосується ІТ і, безумовно, є чимось, що ви хотіли б вирішити ще до того, як доторкнетеся до рядка програмного коду. Evidence Based Management від авторів скрам гайду прямо визначає ці активності як частина роботи Продакт Овнера.
Можна казати, що немає жодної причини, чому Scrum-команда не може будувати стратегію продукту або проводити маркет рісерч, але часто ці поняття швидко відкидаються в дискусіях через те, що Scrum є фреймворком для розробки програмного забезпечення і не регулює ці питання. Якщо поглянути на дванадцять принципів Agile Manifest, то побачите лише слова “софт”, “делівері”, та “девелопери” повсюди, але ні слова про кастдев, стратегію продукту, чи маркет рісерч! Тому, твердження, що побудова стратегії продукту та проведення досліджень ринку відповідає аджайл принципу “Працююче програмне забезпечення є основним мірилом прогресу”, може теж здатися притягнутим за вуха до скрам команди…
Потім з’явився Scaled Agile Framework (SAFe), який якраз типу допомагає трансформувати старі ватерфольні процеси ентерпрайзів та зробити їх більш аджайл. Але SAFe якраз заохочує це хибне уявлення про поділ ролі на стратегічну роль продакт менеджера (тих, хто має доступ до користувачів) та тактичну роль продакт овнера (тих, хто пише скоуп девелоперам). SAFe описує менеджера продукту як зовнішню роль, спрямовану на клієнта — ту, яка спілкується з клієнтами, визначає бачення та напрямок розвитку продукту. Залишаючи власника продукту суто внутрішньою роллю — тим, хто працює з розробниками щодня, застрягший на рівні солюшена та його імплементації, далеко від клієнта — не більше, ніж проксі для штампування нових фіч у великій фічер фабриці (feature factory).
Модні консультанти по SAFe ще більше забетонували розподіл на продакт менеджерів та продакт овнерів розділивши ролі тих, хто має доступ до кастомерів та тих, хто пише скоуп для девелоперів.Цей підхід пояснює частково популярність SAFe у великих компаніях. Роль продакт менеджера по SAFe так схожа, на традиційну роль, і так легко створити ще одну роль продакт овнера, замість реальних змін чи вирішення існуючих проблем в організації. За іронією долі, через 20 років спроба Джеффа і Кена вирішити організаційну проблему відірванності розробки від кінцевих користувачів та ринку шляхом розширення ролі менеджера продукту призвела до прямо протилежного результату…
Еволюція продакт менеджменту
Хоча багато традиційних компаній, навіть сьогодні, отримують вигоду від навіть спотворенного прийняття гнучкого мислення та фреймворку Scrum, однак, якщо ви подивитеся на стартапи та компанії-лідери, які виникли не так давно, то побачите, що багато з них не мають потреби у впровадженні таких фреймворків, як Scrum,— подивіться на Amazon, Spotify, Atlassian тощо жодна з них не має сьогодні Scrum-майстрів. Ці компанії не обтяжені рівнями середнього менеджменту, традиційними управлінськими методологіями, легасі кодом та старими практиками розробки, мали можливість визначити свою культуру, структуру та людей з нуля.
“Today (at Atlassian), many agile teams combine practices from a few different frameworks, spiced up with practices unique to the team. Some call this heresy. We call it practical. It’s not about “Agile” — it’s about agility.” — Atlassian on agile
Як і Atlassian, Spotify починав зі Scrum і з часом еволюціонував з нього, як пояснює Thaisa Fernandes:
Spotify is a 100%-Agile company that started with the Scrum framework, but as their teams were growing, they noticed some things on the Scrum framework that weren’t working well for them. So, they decided to break some Scrum roles, artifacts, and events. According to the video, these things were getting in the way, so they decided to make the Scrum roles, artifacts, and events optional. — Thaisa Fernandes
Ні Скрам Майстрів, ні суворих гнучких фреймворків, де ж тоді залишається продукт? Цікаво, що всі вони мають Продакт Менеджерів, так, вони використовують назву “Продакт Менеджери”, а не “Продакт Овнери”, але на відміну від багатьох великих організацій, вони мають лише одну продуктову роль, а не обидві. AirBnB взагалі сумістив ролі Продакт Менеджера та Продакт Маркетинг Менеджера (Продакт Овнерів в них теж немає), щоб зробити продукт ближче до кінцевих користувачів та ринку.
Традиційний Продакт Менеджер з маркетинг домену, став більш орієнтований на продукт — це означало залучення його до щоденної розробки продукту. Тепер, охоплюючи весь життєвий цикл продукту, ці продуктово-орієнтовані компанії підтримували цих новостворених Продакт Менеджерів, створювали структуру бізнес процесів орієнтовану на продукт. Це означало, що маркетинг, продажі, розробники, юридичний відділ тощо тісно співпрацювали щодня. Продакт Менеджер у таких випадках ставав не стільки менеджером, скільки лідером — тим, хто допомагав об’єднати все це разом і підпорядкувати єдиному баченню. По мірі того, як компанії впроваджували такі методи, як lean, дизайн-мислення та той самий agile, змінився і продакт-менеджмент — дизайн-мислення, lean, та agile стали стандартними способами пошуку, створення та доставки продуктів, і всі вони тепер вважаються основною діяльністю для Продакт Менеджера.
Хоча загальний консенсус полягає в тому, що ролі Продакт Менеджера і Продакт Овнер фактично однакові, ринок більше звик до назви “Продакт Менеджер”. Можливо, просто тому, що вона не несе в собі багажу фреймворку Scrum. Можливо, справжня іронія полягає в тому, що роль Продакт Овнера не зовсім вдало вписалася в продуктово-ринковий контекст, оскільки вважалося, що роль Product Owner і Scrum йдуть в одному пакеті. Скрам, як ми його знаємо сьогодні, є агностичним фреймворком, однак спочатку він був описаний як “спосіб розробки програмного забезпечення”, і навіть сьогодні існує думка, що Скрам є необхідною умовою для прийняття цієї ролі.
“if you take Scrum away as a process for your organization, you are still a Product Manager. Product Management and Scrum work together well, but Product Management is not dependent on Scrum. It can and should exist with any framework or process.” — Melissa Perri
Іншими словами, сталося так, що Продакт Менеджер це професія, а Продакт Овнер це лише твоя роль для скрам команди в Scrum фреймворку. Доречі, по скраму, роль Продакт Овнера, може грати будь хто в команді, якщо у вас немає Продакт Менеджерів.
Яким боком тут Скрам Майстри до сучасних Продактів?
Роль Продакт Овнера спочатку була настільки відповідальною, що Джефф Сазерленд подумав, що це буде забагато для однієї людини, і вирішив розділити цю роль на дві — так народилася роль Скрам Майстра.
Скрам Майстер, хоча спочатку був створений як роль формального виконавця і менеджера фреймворку Скрам, з тих пір ця роль теж еволюціонувала. Як ми знаємо, сьогодні це позиціонується як роль лідера-служителя (servant leader в команді) — роль, яка зосереджена на людях і керівництві процесом. Великі Скрам Майстри навчають людей, створюючи середовище, в якому самоорганізовані команди виконують дивовижну роботу — великі Скрам Майстри в кінцевому підсумку прагнуть виховати більше лідерів і створити самодостатню команду. Вони активно працюють над тим, щоб процеси і люди працювали прекрасно і без їх активного залучення.
Чи має бути Скрам Майстер окремою позицією в команді? Це велике питання… На мою думку та на думку Anthony Murphy — ні. Якщо не брати до уваги можливу постійну роботу аджайл коучингу та культивування культури гнучкості, то не потрібно визначати конкретну роль. Бути аджайл лідером чи servant leader який допомогає команді слідувати скрам, може будь хто в команді. В мене в одній з команд скрам майстром був наш дуже відповідальний та досвідчений QA. Якщо вже на те пішло, то це роль кожного в організації — особливо тих, хто займає “лідерську” позицію, або, краще сказати, позицію впливу. Можливо, Джефф і Кен побачили ще одну дисфункцію в організаціях — відсутність сильного лідерства — я знаю з власного досвіду роботи в традиційних організаціях, що в них є багато менеджерів, але є дуже мало лідерів — справжніх лідерів.
Здається, те що колись було розділене на дві ролі (Продакт Овнер та Скрам Майстр), тепер знову об’єднується в одну (Product Manager = CEO of product, product leader). Це важливо відзначити, тому що, оскільки роль Продакта сьогодні еволюціонує до коучингу та лідерства в команді, а де тоді місце ролі скрам-майстра? Насправді Брендон Чу використав дуже доречну аналогію, щоб описати роль Продакта сьогодні як таку, що можна порівняти з тренером спортивної команди — де він є лідером, тренером для команди і, безумовно, не їх менеджером. Тому варто задатися питанням, чи термін “Продакт Менеджер” все ще є доречною назвою — керувати чим саме? За спостереженнями Anthony Murphy та спостереженнями багатьох інших, таких як Брендон, ця роль перетворилася на роль лідера —чи може термін “Product Leadership” бути більш точним для позначення цієї ролі сьогодні? Ми більше не керуємо продуктом, а намагаємося бути лідерами — ми забезпечуємо лідерство продукту та продуктової команди.
Якщо ви подивитеся на оцінювання продакт-менеджерів від Silicon Valley Product Group, то побачите, що вони розбивають цю роль на три складові: Продукт (Product), Люди (People) та Процес (Process). Ці три стовпи мають разючу схожість з двома ролями Скраму — Продакт Овнером та Скрам Майстром. Якщо Продакт Овнер зосереджується на стовпі Product, то Скрам Майстер — на стовпах People та Process. За іронією долі, Джефф і Кен свого часу прибрали з ролі Продакт Овнер стовпи People і Process, оскільки вважали, що це занадто багато для однієї людини, але з огляду на те, що багато Продакт Менеджерів сьогодні займаються всіма трьома, виникає питання, чи були вони праві з цим припущенням чи ні. Багато компаній, як зазначалося раніше, такі як Atlassian, Spotify тощо, дійсно показали, що це можливо, і є прикладами компаній, які переросли фреймворк Scrum. Можливо, такі ролі, як Скрам Майстр, просто відслужили своє і стали непотрібними, або, можливо, через 20 років ми просто переросли Scrum.
Продакт Менеджмент та Продакт Овнершіп — це дійсно одне і те ж, але оскільки ринок тяжіє до використання назви Product Manager як стандартної практики, то одного дня вона може затьмарити всі інші назви для цієї ролі. Поява таких посад, як Chief Product Officer, свідчить про постійну еволюцію та важливість цієї ролі — таку важливість, що я замислився, чому ми не бачимо такої еволюції для таких гнучких ролей, як Scrum Master та Agile Coach — ніхто не вирішив найняти Chief Agility Officer (можливо, варто було б?), або, можливо, питання лідерства та створення середовища з належними умовами для високопродуктивних команд зараз вирішується деінде, але лідерство в управлінні продуктом все ще залишається більщ важливим.
В США тайтл Продакт Менеджера повністю майже повністю витіснив Продакт Овнера. В Європі та в Україні ще зустрічаються посади Овнерів поруч з Менеджерами. Загальна думка, що Продакт Менеджер — це більш сексі ніж Продакт Овнер. В сервісних компанія ще існують так звані Проксі Продакт Овнери — коли з боку Замовника є нормальний Продакт, але з командою розробки тісно працює бізнес аналітик, який виконує фактично роботу Продакт Овнера в скрам команді.Примітки:
- Продакт Овнер = Продакт Менеджер — це ті самі персони — так початково задумувалося, але сприйняття цих ролей ринком з часом почало дуже відрізнятися, як і функціональні обов’язки (типу продакт овнер — це продакт менеджер на мінімалках для команди — типу і володіє беклогом, але без згоди вищого продакт менеджера не може менеджерити повноцінно роадмапу, або є і інші конотації інтерпретації).
- Організації в яких вже поруч існують продакт менеджери і продакт овнери не повинні стрімко бігти і міняти свої процеси чи перейменовувати ролі. Ця публікація має на меті лише прояснити ситуацію. Але, на мою думку, мати тайтли продакт овнерів та менеджерів в одній компанії — це трохи недолуго (sorry SAFe, але ти дивний фреймворк…). Є різні грейди і рівні сеніорності продактів — продакти нижчого рівня можуть більше працювати з дев командою і овнити лише беклог команди, а більш сеніорні продакти можуть їх менеджерити та овнити стріми, окремі частини продукту, весь продукт.
- Не сприймайте цю публікацію, як маніфест, що скрам фігня і вам не треба скрам майстри (бо це не посада, а лише роль в скрам гайді, яку може виконувати будь-який член команди, крім продакт овнера). Скоріше навпаки, якщо ви не аджайльна прогресивна стартап продуктова команда, а якийсь олдскульний ентерпрайз-завод, де у вас досі все пахне ватерфолом чи вертикальними зверху-вниз директивами, повільними процесами, без сильного продуктового лідерства, то скрам майстри як аджайл тренери та лідери, які будуть фултайм навчати організацію скраму можуть вам допомогти здійснити аджайл трансформацію та стати більш еффективними та продуктово-центричними.
- Продакт менеджмент — це лідерська роль. Наразі продакти активно включаються в C-level борди та рухають компанії в напрямку продукто-центричності. Але якщо компанія не має продукто-центричності, то продакт, який намагається все заменеджерити, що від нього очікується, часто є перенавантаженим — роботи більше ніж одна людина може витягнути. Тому і з’являються всілякі ускладнення та поділ функцій — продакт овнери, продакт менеджери, продакт маркетинг менеджери. Класно, якщо над цим всім все одно є спільний продуктовий лідершіп в продуктовій організації — типу якогось СРО, який оркеструє цих різних продуктових людей.
Корисні лінки по темі:
- Оригінальна Стаття “The Collision of Product Management and Product Ownership” by Anthony Murphy;
- Гайд про “Evidence Based Product Management” від Scrum.org та авторів Scrum Guide;
- Scrum Guide by Jeff Sutherland and Ken Schwaber (last update in Nov, 2020);
- Product Manager role by Scaled Agile Framework;
- Product Owner role by Scaled Agile Framework;
- HBR article by Hirotaka Takeuchi & Ikujiro Nonaka — The New New Product development Game (Jan, 1986) — тут ще 1986 році розписано ітеративну розробку, як альтернативу ватерфолу, та згадано слово Scrum (задовго до Scrum Guide)
- Original “Brand Men” memo — written by Neil H. McElroy (1931) — Роль “Brand Manager” фактично є батьком ролі “Product Manager”
- Quora answer by Jeff Sutherland on the difference between Product Management and Product Ownership — What’s the difference between Product Management and Product Ownership? Can both of them be run without Scrum, or is Product Ownership specifically just for Scrum? (Mar 2019)
- Agile Manifesto (2001) & Agile Manifesto Principles — головні ідеї аджайл методологій в розробці софту.
- Medium post Spotify Squad framework — Part I by Thaisa Fernandes — (Mar 7, 2017)
- Medium post Product Manager vs Product Owner by Melissa Perri, founder and CEO of Produx Labs and Product Institute (Jun 29, 2017)
- Medium post The First Principles of Product Management, by Brandon Chu, GM of Product at Shopify (Jan 8, 2018)
- Evolution of Scrum Master by Ron Eringa (June 29, 2016)
- Evolution of Product Owner by Ron Eringa (June 17, 2016)
- SVPG Product Coaching Tools — The Assessment (Apr 8, 2019)
- How to Get Scrum Right on First Attempt by Takeshi Yoshida (July 17, 2019)
- Medium post No, Airbnb Is Not Killing The Product Function by Product Dave (July 2, 2023)
- A16Z essay: Good Product Manager / Bad Product Manager by Ben Horowitz
- Scrum and XP from the Trenches — 2nd Edition
Product Market Fat:
Давайте товаришувати? Підписуйтеся на Product Market Fat в соціальних мережах:
Автор:
- LinkedIn: Марк Опанасюк
- Telegram: mark_is_here
#productowner #productmanager #scrum #agile #productownership #productmanagement #brandman
