Жизненный цикл продукта: путешествие функции продукта

Это четвертая статья из пяти частей, которые я пишу с целью помочь начинающим продуктам войти в мир управления продуктами.

В своем последнем посте я разбил дисциплину «Управление продуктами» на четыре части, чтобы помочь кандидатам в управление продуктами понять траекторию своей карьеры в компании или в целом. В этом посте я расскажу о жизненном пути функции продукта, от идеи до отказа, чтобы помочь претенденту на управление продуктом получить 360-градусное представление о том, что включает в себя роль менеджера продукта.

Т – 30 дней

Говорят, что необходимость — мать изобретения. Это буквально тот случай, когда речь идет о рождении функции продукта. Все начинается с некоторого уровня дискомфорта.
Какой-то сотрудник в компании сталкивается с дискомфортом при выполнении одной из своих повседневных задач — возможно, пользовательская база увеличилась, и он не может справиться с ней со старыми процессами. Кто-то из руководителей компании смотрит на таблицу Excel и думает, что компания теряет слишком много денег, скажем, из-за большого количества отказов от продукта. Или, может быть, конкурент запустил функцию продукта, из-за которой клиенты отказываются от продукта указанной компании. Кто-то, просматривая воронку маркетинговой конверсии, заметил высокие потери на определенном этапе и решил, что оптимизация может помочь ему достичь квартальной цели. Или это может быть 100 различных причин, от большого количества жалоб клиентов на распространенную проблему до новой функции, востребованной большинством пользователей, опрошенных на прошлой неделе. Дело в том, что все начинается с определенного уровня дискомфорта.

Теперь этот дискомфорт доводится до сведения менеджера по продукту; или, может быть, первым это замечает менеджер по продукту. Это точка, которая запускает цепочку событий, которые могут привести к рождению новой функции.

Т – 25 дней

Пришло время менеджеру по продукту обдумать формулировку проблемы. Он идет и разговаривает с клиентами или внутренними заинтересованными сторонами, которые сообщили о дискомфорте, а затем с теми, кто на самом деле испытывает его; все с одной целью – убедиться, что он идентифицировал «корневую» постановку проблемы. Если к этому этапу относиться легкомысленно или продакт-менеджер уделяет этому недостаточно времени, то рождающиеся фичи продукта становятся хрупкими, искажаются и довольно быстро заканчивают свое существование.
Как только менеджер по продукту определил основную формулировку проблемы, он решает, стоит ли ее решать. Дискомфорт действительно большой, или он несколько преувеличен или, что еще хуже, просто выдуман? Повысит ли ее решение ценность для клиента и/или компании? Не приведет ли ее решение к значительному штрафу для клиента и/или компании? Есть ли способ решить эту проблему с помощью незначительных изменений в процессах или каких-либо действий, не требующих изменений в продукте, например, смена поставщика, согласование более выгодной цены с существующим поставщиком, получение стороннего программного обеспечения для решения проблемы, найм дополнительный сотрудник, изменения в содержании, графике, кнопке призыва к действию и т. д.?

По сути, если есть способ получить аналогичную добавленную стоимость от метода, не включающего изменения продукта, то мы предпочли бы его изменению чего-либо в продукте — будь то добавление или удаление. Как только менеджер по продукту убедится, что решение проблемы принесет значительную пользу, а изменение уровня продукта принесет гораздо большую рентабельность инвестиций (учитывая время, деньги и усилия по сравнению с ценностью), чем изменение не на уровне продукта, семена нового особенность продукта посажены.

Т – 15 дней

Если у менеджера по продукту есть некоторый предыдущий опыт, он может предложить решение, основанное на этом опыте. Однако это не может быть лучшим решением во всех случаях.
Если постановка проблемы требует высокотехнологичного решения, менеджер по продукту обсуждает то же самое с разработчиками и инженерами-менеджерами и прислушивается к их советам, как лучше всего это сделать. Если решение требует изменений на уровне дизайна, можно проконсультироваться с руководителем UX. Возможно, менеджер по продукту и специалист по UX организуют дизайн-спринт и выбирают решение, которое хорошо воспринимается реальными пользователями этой функции. Иногда проблема полностью связана с бизнесом и, следовательно, требует участия высшего руководства.
Таким образом, может быть несколько способов окончательного решения. Но как только это происходит, менеджер по продукту отвечает за преобразование этого теоретического решения в активную функцию продукта.

T = 0 (он же рождение функции продукта)

Когда определено конкретное решение, менеджер по продукту в сотрудничестве с соответствующей командой составляет базовую схему решения. Он может включать или не включать прототип решения. Иногда это просто простой лист Excel с условиями «если-то», написанными для того, когда показывать конкретный CTA пользователю и т. д.
Менеджер по продукту формулирует решение в соответствующем PRD (Документ с требованиями к продукту). Если функция небольшая, это может быть просто абзац в существующем PRD для более крупной функции. Иногда функция настолько велика, что требуется полный PRD только для того, чтобы правильно детализировать ее. PRD управляется соответствующими командами, и менеджер по продукту следит за тем, чтобы в отношении этой функции существовал широкий консенсус.

Т + 15 дней

Небольшие функции могут быть заморожены менее чем за день. Большие функции иногда требуют более 30 дней, чтобы получить всеобщее одобрение.
Возьмем в среднем 15 дней, чтобы сказать, что это время, когда разработчикам представляют новую функцию. Надлежащий дизайн и передача PRD происходят, когда разработчики, работающие над проектом, информируются о 5W (что, почему, когда, где, кто) и тестовых примерах (как функция должна вести себя или не вести себя после ее выпуска) .
Совместно с техническим менеджером для функции определяется надлежащий график выпуска с указанием сроков окончания разработки, начала тестирования, исправления обнаруженных ошибок и окончательной даты выпуска. Затем вся временная шкала делится на измеримые спринты (обычно по 15 дней). Как только разработчики удовлетворены, начинается разработка.

Т + 30 дней

Спринт 1 заканчивается. Выкатывается одна часть функции продукта. Возможно, это еще не клиентоориентированность, но сегодня большинство команд следуют методологиям Agile для разработки программного обеспечения , что означает, что мы строим постепенно и итеративно. Таким образом, вместо того, чтобы создавать большую функцию за 6 месяцев и выпускать все сразу, мы разбиваем все это на независимые части, которые могут функционировать сами по себе (куча пользовательских историй) и быстро готовы к просмотру и повторению.
Менеджер по продукту следит за соблюдением сроков выпуска посредством ежедневных схваток и обсуждений с соответствующим техническим менеджером, работающим над проектом. В случае задержки сроки корректируются соответствующим образом или небольшие части функций удаляются, чтобы обеспечить своевременный выпуск. После каждого спринта достигнутый прогресс представляется менеджеру по продукту и соответствующим заинтересованным сторонам на встрече, а после утверждения он публикуется.
Один год программы управления продуктами UpGrad

Т + х дней

После «n» спринтов разработка завершена, и вся функция отсутствует. Не обязательно, чтобы клиенты могли использовать эту функцию только после ее полного выпуска. Они могли использовать его с момента выпуска в конце самого спринта 1. Каждый последующий выпуск цикла спринта только делает функцию более надежной и приближает ее к тому, чем она должна быть.
Запуск функции сам по себе является искусством и включает в себя множество шагов, которые мы пропустим и просто предположим, что после большого барабанного боя и ударов в грудь миру было объявлено, что функция была выпущена. Это может быть полномасштабный пресс-релиз, в котором сам генеральный директор рассказывает о новом запуске, или это может быть просто письмо, отправленное в определенный отдел, который собирается использовать эту функцию и, вероятно, запросил ее в первое место. Итак, теперь, когда функция доступна, давайте дадим ей имя — Mr. Feature.

Т+г дней

Даже после финального релиза иногда что-то идет не так. Мистер Фича, который когда-то был блестящим и ценным, может уже не быть прежним, и на это может быть множество причин. Эта фаза в цикле продукта связана с поддержкой продукта. В один прекрасный день был выпущен еще один релиз, из-за которого Mr. Feature работал непреднамеренно (он же стал глючным), или, возможно, была удалена другая функция, которая имела некоторые зависимости от Mr. Feature, и это вызвало ошибочное поведение. Также может случиться так, что когда функция была создана, мы недооценили количество пользователей, которые будут ее использовать, или не спланировали все варианты использования, и теперь функция не может масштабироваться до такого количества пользователей или вариантов использования.

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

Менеджер по продукту пытается понять основную причину ошибки и, в соответствии с приоритетом, планирует исправление для следующего цикла выпуска — оно может быть добавлено в текущем спринте, если оно имеет высокий приоритет, или даже в последующих спринтах. После того, как ошибка будет исправлена ​​и выпущена, Mr. Feature доживет до следующего дня, хотя и в измененной форме — Mr. Feature 2.0 — благодаря менеджеру по продукту и команде инженеров. Слава!

Т + z дней

Говорят, что все хорошее когда-нибудь заканчивается. К сожалению, это относится и к Mr. Feature, независимо от его версии — может быть, Mr. Feature 9.263.75! Это означает, что мистер Фичер прожил долгую и счастливую жизнь, но теперь конец пути уже здесь.
Это может быть связано с разными причинами. Появилась новая функция, которая сделала потребность в мистере Фиче совершенно ненужной. Это также может быть что-то экстремальное — например, компания решила, что, хотя эта функция добавляет ценность ее пользователям, она больше не имеет для них экономического смысла.

Независимо от причины, менеджеру по продукту сообщается (или он начинает обсуждение), что услуги Mr. Feature больше не понадобятся. Теперь, как бы это ни было душераздирающе, у менеджера по продукту есть обязанность похоронить г-на Фичу. Хотя до этого ему нужно удостовериться в нескольких вещах, таких как информирование пользователей, которые использовали Mr. Feature, о том, что она будет недоступна с определенной даты, новая функция работает хорошо, прежде чем удалять Mr. Feature, ничего другого на поток влияет уход Mr. Feature и т. д.

Итак, пришло время попрощаться с мистером Фичей. В вашей карьере менеджера по продукту вам придется делать это несколько раз. Но помните, конец одной функции — это начало другой, и цикл продолжается. Такова жизнь управления продуктом!

Изучайте онлайн- курсы по управлению продуктами в лучших университетах мира. Заработайте программы Masters, Executive PGP или Advanced Certificate Programs, чтобы ускорить свою карьеру.

Избранная программа для вас: программа сертификации дизайнерского мышления от Duke CE