Портал №1 по управлению цифровыми
и информационными технологиями

Почему запуск продукта проваливается (и как этого избежать)

Сколько запусков новых продуктов происходит каждый год? По данным Nielsen около 30 000 среди товаров повседневного спроса. Для программного обеспечения гораздо труднее найти конкретные данные. Но могу вас заверить, что статистика того, как проходит большинство этих запусков, довольно мрачная. Разные источники приводят показатели от 40 до 80 процентов в качестве частоты провалов. Я предполагаю, что на самом деле может быть и чаще. Ой!

Но что мы имеем в виду, когда говорим, что запуск продукта «провалился»? И почему так много провалов?

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

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

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

Это огромная работа. Я лично могу сказать, что большинство достижений в моей карьере являются результатом сплочённой командной работы, сотрудничества при осмыслении и решении проблем. Создавать нечто от идеи до полностью сформированного решения, которое нравится клиентам очень захватывающе. Вот почему я предан своей команде разработчиков Aha! Вместе с которыми создаю новые предложения.

Наша команда в Aha! имеет большой опыт разработки продуктов, и у нас есть возможность поддерживать тысячи команд, которые используют наше программное обеспечение каждый день. Исходя из этого мы собрали коллективные знания о частых причинах неудач при запуске продукта.

Движение без внятных целей

Разработка энергозатратна. Можно гнаться за большим количеством идей, но знаете ли вы, почему прямо сейчас вы занимаетесь именно этим? Я не имею в виду над чем вы работаете, а говор о том, чего вы хотите достичь в данный момент. То, что мы получаем на выходе (функциональность), зависит от результата (ценности для клиента и бизнеса), который будет реализован.

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

Решение проблемы, которой не существует

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

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

Фокусировка исключительно на возможностях

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

Как избежать провала: уделите приоритетное внимание чёткому определению проблем, которые должны разрешить разработчики, а не созданию отдельных функций.

Отсутсвие организации специально выделенной продуктовой команды

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

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

Отсутствие позиционирования и послания для клиентов

Какую ценность вы доставляете? Как это лечит болевые точки? Почему вы выводите продукт на рынок именно сейчас? Люди, которые продают, продвигают, сопровождают и (да) покупают ваш продукт, должны знать эти ответы. Их деятельность является локомотивом, двигающим успешный и долговечный продукт. Чёткое позиционирование и послание прокладывают ему путь.

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

Уверенность в том, что план всем известен

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

Как избежать провала: Создайте практику обзора дорожных карт для определённой аудитории и заинтересованных сторон с обсуждением ответственности за сроки и прогресс.

Ожидание, пока «всё закончим»

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

Как избежать провала: установите два горизонта – краткосрочные возможности для достижения долгосрочной цели.

Отсутствие пострелизной деятельности

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

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

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

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

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

А как вы думаете, что является осью запуска продукта?

by Brian de Haaff
оригинал статьи 

«Трансформация ИТ в традиционных компаниях»
Учебный курс о кратном ускорении за счёт новой организации работы

Добавить комментарий

Ваш адрес email не будет опубликован.

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM