«Вдохновленные» kitobidan iqtiboslar
Главная цель исследования продукта заключается в устранении следующих рисков: • Купит ли (нашу идею) покупатель, решит ли он (ее) использовать? ( Риск ценности. ) • Сможет ли пользователь понять, как это работает? ( Риск юзабилити. ) • Можем ли мы это разработать? ( Риск технической реализуемости. ) • Принесет ли это решение пользу нашему бизнесу? ( Риск бизнес-жизнеспособности.)
Глава 10. Менеджер продукта Эта книга о том, как стать отличным продакт-менеджером, а в данной главе я вам расскажу, что же это означает на самом деле. Но для начала немного суровой правды ради вашей же пользы. Менеджер продукта может выбрать один из трех подходов к работе, но, по моему глубокому убеждению, только один из них ведет к успеху: 1. Он может переводить любую проблему и решение на уровень высшего руководства компании. В этом случае менеджер продукта, в сущности, просто администратор бэклога . По словам многих СЕО, в такой модели они со временем и оказываются, и это не имеет никакого отношения к масштабированию. И если вы думаете, что должностные обязанности менеджера продукта изложены в сертификацированном тренинге для работы по Scrum «Владелец продукта», то почти гарантированно попадаете в эту категорию. 2. Он может организовывать совещания всех заинтересованных сторон и позволять им спорить до победного конца, пока не будет выработано решение. Такой подход называется разработкой комитетом и крайне редко дает результат выше посредственного. В этой модели, к сожалению, чрезвычайно распространенной в крупных компаниях, менеджер продукта на самом деле просто администратор дорожной карты. 3. Он может сам выполнять свою работу.
В мире, конечно, найдется совсем немного продуктовых команд, которые изменили свои дорожные карты продукта так, чтобы каждый их пункт формулировался как бизнес-проблема, обязательно требующая решения, а не как фича или проект, которые, возможно, решат эту проблему, а может быть, и нет. Такие документы называют дорожными картами, базирующимся на результате.
10. И наконец, пока мы сильно заняты этим процессом и крайне непродуктивно тратим время и деньги, наибольшей нашей потерей обычно становится цена упущенной возможности, то есть того, что наша организация могла и должна была сделать вместо этого. А это время или деньги, которых уже не вернешь.
1. Риски нужно учитывать в самом начале, а не в конце работы над идеей или продуктом. В лучших современных командах стараются максимально избавиться от рисков до принятия решения о начале работы. Речь идет о риске ценности (будут ли люди покупать это), риске юзабилити (удобства использования) (смогут ли пользователи понять, как это работает), риске реализуемости (осуществимости) (смогут ли инженеры создать то, что нужно, с учетом времени, навыков и технологий, имеющихся в распоряжении) и риске бизнес-жизнеспособности (будет ли это решение полезным для разных аспектов бизнеса: продаж, маркетинга, финансов, юридических вопросов и так далее).
User Story Mapping: Discover the Whole Story, Build the Right Product 13 Джеффа Паттона.
: «Никогда не говори людям, как надо делать. Скажи им, что делать, и они удивят тебя своей изобретательностью».
Стараясь угодить всем, почти гарантированно не угодишь никому
: «Нам нужны команды “миссионеров”, а не “наемников”». Наемники создают то, что от них требуют, что бы это ни было. Миссионеры же искренне верят в продукт и от всей души хотят решить проблемы потребителей
9. Самым большим недостатком устаревшей каскадной модели было и остается то, что все риски сосредоточены в самом конце процесса; иными словами, проверка продукта на потребителе происходит слишком поздно.
