Продуктовый подход — это методология, согласно которой мы строим бизнес вокруг продукта и его пользы для людей. А понимание того, нравится ли продукт целевой аудитории, приходит из объективных данных, а не из субъективных ощущений. В продуктовой компании критически важно, чтобы:
- Вся команда понимала, ради чего мы работаем, что мы несем в мир;
- В работу брали только то, что хорошо просчитано и проверено на основе данных;
- У команды было достаточно свободы и скорости, чтобы доставлять пользу вовремя;
- Мы всегда максимизировали прибыль, минимизируя издержки.
Внедрением продуктового подхода и его евангелистами в компании и за ее пределами всегда были product-менеджеры (aka product-оунеры, трайб-лидеры, head of product’ы). Это востребованные и редкие специалисты, которых пока не учат в казахстанских университетах. Зато иногда учат в продуктовых компаниях. Об одном из таких курсов можно узнать здесь.
А теперь давайте поговорим о том, как внедрить продуктовый подход эффективнее, если вы тоже в него поверили.
1. Управленческий паралич
Когда начинается работа с данными, люди часто собирают бесконечное количество данных в бесконечные дашборды, но выводы по этим данным сделать не могут. Для этого даже придумали название управленческий паралич, когда цифр перед глазами много, а принять какие-то реальные решения на их основе не получается.
Ожидание: наймем аналитика, и он сможет найти ответ на любой вопрос, подскажет, куда надо двигать весь бизнес.
Реальность: аналитик напилил миллион дашбордов, в которых легче потеряться самому, чем найти какие-то ответы. Зачастую в ответ на какой-то вопрос получаешь от него многомегабайтные excel-таблицы, от которых виснут компьютеры и мозги управленцев. На важные вопросы аналитик отвечает месяцами, поэтому менеджер продолжает принимать решения по наитию и опыту. Данные есть, а пользы от них нет.
Как надо: дашборды нужно составлять по мере появления четких вопросов, например: на каком шаге воронки мы теряем людей? Чтобы разобраться, аналитикам нужно будет покрыть каждый шаг метриками, а потом уже сделать дашборд для менеджера. Иногда дашборд и вовсе не нужен, а нужен ответ на конкретный вопрос: сколько у нас чего-то? Менеджер должен хорошо понимать и четко объяснять аналитикам, в каком виде он хочет получить ответ, и как он поможет ему действовать дальше, а не ждать чуда.
2. Продакт-предприниматель vs продакт-исполнитель
Ожидание: наймем product-менеджера. Он будет развивать бизнес как свой собственный сразу и наведет порядок абсолютно во всех процессах.
Реальность: product-менеджер приходит из другой сферы или компании. От него ждут всего и сразу. К тому же часто он предлагает решения, которые уже приходили в голову первому руководителю. Директор решает, что продакт недостаточно хорош, поэтому превращает его в исполнителя своей воли.
Все заканчивается тем, что продакт становится переводчиком с бизнесменского языка на разработческий. Он слушает, что говорит руководитель и ставит задачи разработчикам, дизайнерам и аналитикам.
Как надо: не требовать от product-менеджера растить весь бизнес сразу, потому что он будет заниматься всем и ничем. Если он должен одновременно наращивать объемы продукции и сокращать время доставки, скорее всего, не удастся достичь хороших результатов ни там, ни там.
Продакту полезно, например, работать на общую выручку, либо сконцентрироваться только на производстве – увеличить количество продукции за единицу времени. Тогда product-менеджер видит весь процесс, разбивает его на шаги, анализирует и улучшает каждый этап, изучает клиентский опыт. В какой-то момент он будет знать рынок и продукт куда лучше, чем CEO или владелец бизнеса.
3. Тупиковые коммуникации
Ожидание: продуктовая команда из аналитиков, дизайнеров и программистов будет понимать product-менеджера с полуслова и болеть за продукт не меньше, а то и больше, чем сам продакт. Все мысли продакта будут автоматически конвертироваться в правильный программный код, интерфейсы и пользовательский опыт.
Реальность: аналитик думает не так, как дизайнер, дизайнер – не так, как программист, программист – не так, как менеджер. А еще они могут быть интровертами. Если они будут пытаться коммуницировать напрямую, то релизы новых фич (функционала) не будут решать проблемы, которые должны были.
Как надо: невозможно однажды наладить коммуникации. Это нужно делать постоянно. Ставить задачи на разных «языках», быть фасилитатором, измерять температуру, проверять лично каждый этап разработки. Поставить задачу не равно решить проблему или достигнуть цели.
4. Фреймворки ради фреймворков
Ожидание: мы сейчас наймем SCRUM-коучей, введем SCRUM за несколько месяцев и начнем работать по Agile, поэтому все сразу захотят присоединиться к нашей компании, и мы, конечно же, добьемся сверхрезультатов.
Реальность: приезжают SCRUM-коучи, абсолютно немотивированные сотрудники ходят из-под палки на курсы по SCRUM, а на ежедневных стендапах говорят что-то в стиле «я вчера работал, а сегодня тоже буду работать». В результате ничего не меняется.
Как надо: нужно отталкиваться от проблемы и работать только с высокомотивированными командами. Внедрять гибкие методологии в командах, где один или несколько человек хотят меняться и менять мир вокруг. На основе их успехов постараться масштабировать практики на другие команды. Главное, чтобы ритуалы не превалировали над тем, для чего они затевались — над результатами. Работающий продукт важнее документации, а коммуникации между людьми важнее, чем протоколы и инструкции.
Если хотите узнать еще больше инсайтов о профессии product-менеджера в Казахстане, то почитайте исследование от Kolesa Group. Мы опросили 320 практикующих специалистов и привлекли экспертов из лидирующих IT-компаний.
