Həcm 321 səhifə
2018 il
Kitab haqqında
Если вы продакт-менеджер в технологической компании или только мечтаете им стать, обновленное издание книги известного специалиста по продакт-менеджменту Марти Кагана поможет вам выбрать верный путь в деле создания высокотехнологичных продуктов. В нем представлены принципы проектирования, исследования и запуска прорывных продуктов, а также рекомендации по управлению ими, применимые в разных контекстах.
Книга будет полезна инвесторам, продакт-менеджерам, маркетологам, разработчикам, стартаперам.
Вот зря эту книгу адресовали продактам.
Я ни разу ни продакт, а читаю книгу взахлеб.
Просто завораживающе написано про масштабирование.
Причем книга интересна не только для высокотехнологичного бизнеса, как мне кажется.
А для любого растущего и развивающегося бизнеса.
Очень много воды. Не понимаю почему ее советуют читать как полезный материал для продакт-менеджеров. Очень идеалистичный взгляд на процессы.
мне не понравился стиль, но книга все равно интересная и полезная , я рекомендую к прочтению каждому, кто связан с разработкой продуктов в IT
Автор Марти начинал карьеру в HP, где был разработчиком в течение 10 лет. Затем он работал в Netscape, и был VP Product в eBay, после чего основал Silicon Valley Product Group — консалтинговую компанию по продуктовому развитию.
Тезисов выписал немного, но они важные для меня * Что нужно поменять в своём подходе к работе над продуктами: 1. Взвешивать риски ДО, а не ПОСЛЕ. Что продуктом могут не пользоваться, могут не понимать, что не принесёт ценности бизнесу 2. Продукт создаётся совместно командой, а не последовательно: продакт, дизайнер, аналитик и т.п. 3. Мы решаем проблемы, а не фичи выкатываем
* Стадия Product Discovery должна заканчиваться отвалидированным бэклогом, а именно с фичами, отвечающими на вопросы: — Будет ли пользователь это использовать, покупать? — Сможет ли он понять, как этим пользоваться? —Смогут ли наши инженеры это реализовать? — Могут ли наши стейкхолдеры поддерживать этот продукт?
* В качестве бенчмарка: сильные команды тестируют 10-20 гипотез в неделю (!!!), не на проде, а на прототипах, конечно, но в этом и суть
* Самое важное — команда, остальное наживное
* Понравилась мысль: «Я понимаю, что это немного oldfashioned, но collocated team will always outperform a dispersed one». Команда, сидящая вместе, всегда превзойдёт распределённую.
* Надо собрать team of missionaires, а не team of mercenaries. Первые защищают продукт, мыслят проактивно, заинтересованы в его развитии. Вторые просто делают то, что им говорят.
* Почти невозможно собрать team of missionaires, если люди участвуют в командах по-проектно (!!!) PRODUCT MANAGER Должен иметь потрясающее знание своего клиента. Это его основная роль в компании. Станьте главным экспертом по клиентам. Пусть все, у кого есть вопросы про ваших пользователей, идут с ними к вам.
* Со стейкхолдерами надо встречаться по одному и показывать все не на презентациях, а на hifi prototypes (!!!)
Общее впечатление Это натурально настольная книга продакта. Очень конкретные рекомендации, без воды. Покрываются все аспекты управления цифровым продуктом.
очень злит, что перевод всех терминов сделан без проверки, как эти термины используются реальными русскоязычными практиками. перевод художественный, а не технический
Главная цель исследования продукта заключается в устранении следующих рисков: • Купит ли (нашу идею) покупатель, решит ли он (ее) использовать? ( Риск ценности. ) • Сможет ли пользователь понять, как это работает? ( Риск юзабилити. ) • Можем ли мы это разработать? ( Риск технической реализуемости. ) • Принесет ли это решение пользу нашему бизнесу? ( Риск бизнес-жизнеспособности.)
Глава 10. Менеджер продукта Эта книга о том, как стать отличным продакт-менеджером, а в данной главе я вам расскажу, что же это означает на самом деле. Но для начала немного суровой правды ради вашей же пользы. Менеджер продукта может выбрать один из трех подходов к работе, но, по моему глубокому убеждению, только один из них ведет к успеху: 1. Он может переводить любую проблему и решение на уровень высшего руководства компании. В этом случае менеджер продукта, в сущности, просто администратор бэклога . По словам многих СЕО, в такой модели они со временем и оказываются, и это не имеет никакого отношения к масштабированию. И если вы думаете, что должностные обязанности менеджера продукта изложены в сертификацированном тренинге для работы по Scrum «Владелец продукта», то почти гарантированно попадаете в эту категорию. 2. Он может организовывать совещания всех заинтересованных сторон и позволять им спорить до победного конца, пока не будет выработано решение. Такой подход называется разработкой комитетом и крайне редко дает результат выше посредственного. В этой модели, к сожалению, чрезвычайно распространенной в крупных компаниях, менеджер продукта на самом деле просто администратор дорожной карты. 3. Он может сам выполнять свою работу.
10. И наконец, пока мы сильно заняты этим процессом и крайне непродуктивно тратим время и деньги, наибольшей нашей потерей обычно становится цена упущенной возможности, то есть того, что наша организация могла и должна была сделать вместо этого. А это время или деньги, которых уже не вернешь.
1. Риски нужно учитывать в самом начале, а не в конце работы над идеей или продуктом. В лучших современных командах стараются максимально избавиться от рисков до принятия решения о начале работы. Речь идет о риске ценности (будут ли люди покупать это), риске юзабилити (удобства использования) (смогут ли пользователи понять, как это работает), риске реализуемости (осуществимости) (смогут ли инженеры создать то, что нужно, с учетом времени, навыков и технологий, имеющихся в распоряжении) и риске бизнес-жизнеспособности (будет ли это решение полезным для разных аспектов бизнеса: продаж, маркетинга, финансов, юридических вопросов и так далее).
User Story Mapping: Discover the Whole Story, Build the Right Product 13 Джеффа Паттона.
Rəylər, 18 rəylər18