Что я понял за 18 месяцев работы в качестве Product Owner-а

Последние 18 месяцев для меня были чем-то вроде безумной поездки. Переход от инженерии к управлению продуктом был непростым. Я люблю технологии. С моим интересом к бизнес-идеологии я считаю, что лучше внесу свой вклад в технологии, используя свои креативные навыки, чем навыки программирования. Хотя техническое знание было благом, трудовая жизнь и книги, которые я прочитал за последние несколько месяцев, изменили мой взгляд на управление продуктами. Вот отражение того, что я узнал.

1. Разнообразие опыта делает продуктовую организацию хорошей

Если все в организации думают одинаково, то это противоречит цели ее создания. Понимание бизнеса и рынка является критически важным продуктовым навыком. Так же как и понимание технологий, финансов и маркетинга. Трудно найти людей, которые разбираются во всем этом. Но можно создать продуктовую организацию в которой навыки людей дополняют друг друга. Если мы внимательно присмотримся, то поймем, что каждому продукту/команде может потребоваться свой тип Product Owner-а. Некоторым командам лучше работать с высокотехнологичным PO, в то время как другим организациям может понадобиться кто-то, кто лучше разбирается в маркетинге и электронной коммерции. Продуктовые организации работают лучше, когда в них входят члены с разным профессиональным опытом, поскольку наш опыт сильно влияет на то, как мы думаем.

2. Технические решения напрямую связаны с успехом продукта, но PO обычно не имеет к ним никакого отношения

Это наиболее актуально, когда речь идет о выборе стороннего продукта, платной услуги, библиотеки с открытым исходным кодом или поставщика консалтинговых услуг. Когда сторонний объект выбирается из пула аналогичных объектов, доступных на рынке, сделанный выбор может существенно повлиять на циклы разработки. Любые ограничения, связанные с этой сущностью, должны быть приняты такими, какие они есть. Изменение выбора, особенно после длительного срока использования, требует геркулесовых усилий.

3. Либо создайте продукт, который нужен рынку, либо создайте продукт, который создаст рынок

Создание функций, которые никому не нужны, просто сожжет бюджет. Выясните, нужна ли рынку, пусть и неявно, указанная фича. В качестве альтернативы изучите, может ли функция или продукт в целом явно создать новый рынок (например, как Pop-it создал свою клиентскую базу среди детей). Если предлагаемый продукт или функция не попадает ни в одну из этих категорий, то лучше не продолжать.

4. «Процессы» заставляют колеса вращаться. В то же время тяжелые процессы могут быть плохими. Должен быть баланс

Разработка продукта — очень динамичное пространство. Идеи иногда теряются при переводе (Product English != Engineering English). Отслеживание так же сложно, как и сама задача. И великие лидеры приходят и уходят. Головной боли, порождаемой этими тремя факторами, можно избежать, если организация ориентирована на процесс.

Вначале в большинстве компаний принятие решений будет сильно зависеть от определенных лиц. Но когда компания растет, процессы необходимы для того, чтобы колесо прогресса продолжало вращаться. Кроме того, легче согласовать повседневную работу со стратегией, если существуют процессы.

При этом слишком много процессов может повредить таким вещам, как обнаружение продукта и его маркетинг. Должен быть правильный баланс.

5. Каждый PM-фреймворк актуален по-своему

От знаменитых команд Spotify до GIST-планирования — у каждой системы управления проектами есть свой уникальный способ создания продукта, который продается. Все они работают до тех пор, пока они правильно адаптированы к правильным обстоятельствам.

Метод Amazon working backwards доказал, что для компании он творит чудеса, но не все стартапы, которые скопировали этот подход в его нынешнем виде, получили такие же превосходные результаты. JTBD (Job-to-be-done) работает, сосредотачиваясь на пользовательских сценариях, в то время как Прагматический маркетинг фокусируется на персонажах пользователей. Вопрос о том, следует ли придавать значение сценариям или персонам, зависит от решаемой бизнес-задачи. MVP хорошо работает, когда есть чему поучиться в процессе разработки продукта. Дизайн-спринты, вероятно, лучше всего подходят для интерактивных платформ (Medium и Slack известны тем, что их используют).

Строго следовать одному из этих существующих фреймворков может быть не лучшей идеей. Создание рецепта путем заимствования концепций из соответствующих областей будет работать лучше. Каждая организация отличается. Каждая команда внутри организации отличается. Как правило, нет единого решения, подходящего для всех. Я считаю, что обязанность продуктовой команды — совместно выяснить, что хорошо работает для организации.

6. SaFe — это замаскированный водопад. Тем не менее, иногда это работает

Истинные сторонники Agile редко бывают поклонниками SaFe (Scaled Agile Framework). Тем не менее, многие руководители высшего звена голосуют за SaFe из-за той заметности, которую он им дает. В случае с SaFe существует определенное ожидание того, что произойдет в конце PI. Даже если все цели PI не достигнуты из-за непредвиденных ситуаций (вспомните log4j), он все равно может служить контрольной точкой для согласования со стратегией продукта.

SaFe действительно лишает разработку значительной степени гибкости. Для многих продуктов недостаточная гибкость является проклятием. Вопрос о том, будет ли работать SaFe или нет, зависит от потребностей продукта и культуры организации.

7. Рассылки — хороший способ мотивировать внутренние команды и привлекать внешних клиентов

Когда я был техническим руководителем, я удивлялся, почему в моей старой компании было много шума из-за рассылок. Каждую пятницу командам внутренних разработчиков рассылались письма о поставках, достижениях, с разделом «что я сделал на прошлых выходных» и несколькими забавными интервью. Каждый квартал клиентам присылали очередную рассылку о продукте, о том, что будет дальше, запросы на обратную связь и тому подобное. Характер обоих писем был тщательно продуман авторами контента. Сейчас я скучаю по этим информационным бюллетеням о продуктах и ​​осознал, насколько они могут изменить мотивацию внутренних команд.

Успех продукта

Короче говоря, наличие разнообразной продуктовой организации и следование фреймворку, который соответствует потребностям и культуре организации, имеет важное значение для долгосрочного успеха любого продукта. Хотя есть несколько вещей, таких как инженерные решения, которые не контролируются продуктом, доверие к команде и поддержание их мотивации — это то, как продукт должен двигаться вперед. Согласование работы команды со стратегией является одной из основных функций Product Owner-а, а создание видения продукта, целей и стратегии, настроенных на успех, является основной функцией продуктового лидерства.