Как менеджеру продукта испортить релиз на финальном отрезке
Представим, что вы как менеджер продукта делаете идеальное приложение. Оно продумано, ориентировано на определенный сегмент рынка. Инновации, big data, machine learning. И это действительно так. Как же можно запороть релиз на финишной прямой. Инструкция по неприменению.
Не делайте план запуска (launch plan)
Ваша аудитория должна ждать продукт. Если он новый, то это потенциальная аудитория — инноваторы. Если это следующая версия, то текущие заказчики. Без запуска его на рынок о нем никто не узнает. Этот этап включает такие проверенные инструменты как статьи в блоги и профильные журналы, вебинары и рассылки. Составьте его с маркетингом заранее, и лучше начинайте выполнять загодя. Это кажется очевидным при выпуске совершенно нового продукта, но легко забывается при релизе очередной версии.
Забудьте про передачу знаний
Ваша техническая поддержка и консалтинг (если есть) должны знать новые функции. Как они работают, что нового несут. А также как решать проблемы и сбои.
Очень важно подготовить материалы для продавцов и партнеров, если они у вас есть. Те самые слайды и whitepapers, которые будут помогать им продвигать и продавать.
К новым продуктам забудьте придумать цену в прайслисте
Бухгалтерия процесса такова, что нельзя просто так взять и отгружать «Чудо софт 2.0». У вас должен быть присвоен каталожный номер (термин существует под разными названиями: SKU, Part Number, Model ID, Material Number). Он должен быть, с соответствующей ценой. Если у вас небольшая компания, то обновление каталога можно провернуть быстро. Если компания крупная, то это может занять до нескольких месяцев.
Это касается не только продукта целиком, но и комбинаций — бандлов. Например, вы придумали новую подписку — обновите номер и прайслист.
Также я бы отнес сюда все аспекты связанные с постановкой на баланс. Это больше по бухгалтерской части, но продукт менеджер или директор продукта часто задействованы на разных этапах.
Далее идут нюансы.
Например, не сделать вовремя ECCN или специфичную сертификацию для специализированного софта.
Не уведомить собственную IT команду, что предстоит установить новую версию, в случае облачных решений.
Все это может показаться тривиальным и не достойным отдельной статьи. Однажды я не вовремя вспомнил о том, что номер Model ID новой версии должен измениться. Мне это стоило два месяца ожидания обновления всех каталогов.
Для подстраховки достаточно иметь чеклист (рекомендую The Checklist Manifesto: How to Get Things Right by Atul Gawande. И дату в проекте, когда вы выходите на финишную прямую.
