Представим, что вы как менеджер продукта делаете идеальное приложение. Оно продумано, ориентировано на определенный сегмент рынка. Инновации, 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. И дату в проекте, когда вы выходите на финишную прямую.

Комментарии (5)


  1. slaFFik
    14.02.2019 13:53

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


    1. MikhailZakharov Автор
      14.02.2019 14:04

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


      1. helg1978
        15.02.2019 19:38

        логика в абзаце инвертируется по отношению к заголовку:

        Не делайте план запуска (launch plan)

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

        путает при чтении


        1. MikhailZakharov Автор
          15.02.2019 20:08

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


          1. helg1978
            15.02.2019 20:42

            не могу с вами не согласиться ;)