Михаил Покидько: «Нельзя просто въехать на хайпе продуктового подхода»

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

Там обычно не принципиально, как выстроена работа, если она даёт результат. Например, я раньше занимался приложением для платных парковок. Наши разработчики были в Эстонии, а мы — в России. Было непонятно, как, когда, что мы делаем. Внедрили гибкую систему управления — SCRUM, и стало понятнее, появилась предсказуемость.

В любой большой компании продакт-менеджер — это всегда история про разделение труда. У него жёсткая специализация: в какие-то области его принципиально не пускают, где-то он просто не нужен. Ну и за счёт размера команды многое делегируется другим.

А вот сам по себе продуктовый подход одинаковый и в больших компаниях, и в маленьких. Может только восприятие отличаться.

В случае с обычными продуктами — это история «на сколько больше мы станем зарабатывать живых денег?», а в случае с внутрикорпоративными продуктами — «на сколько больше мы станем зарабатывать опосредованно?» Просто экономический эффект выделяешь и измеряешь, это не зависит от продукта.

Во всех компаниях по-разному понимают, чем продуктовый подход отличается от проектного. Я на примере X5 объясню. У нас большие данные, Big Data, образовались полностью с нуля в конце 2017 года. Я пришёл в мае 2018-го, когда в целом компания толком не знала ни о больших данных, ни о том, кто такие продакт-менеджеры и что они делают.

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

Зачем чинить то, что и так работает? Конечно, все слышали какие-то модные хайповые слова, спрашивали: «Что вы нам будете делать? CustDev?» Я отвечал: «Да». Но они не знали, что такое CustDev и для чего он нужен. Все говорят, что хотят проверять бизнес-гипотезы, но как это работает и зачем, до сих пор многие не понимают.

На самом деле это только для продуктовой тусовки звучит ужасно и крамольно. На «той стороне» люди приводят очень даже здравые аргументы: «Ок, продуктовый подход, хорошо. А чем нам это поможет? Мы же не айтишная компания, как «Яндекс», мы торгуем помидорами и зарабатываем нормальные деньги. Зачем нам всё это?». Это традиционный подход к организации процессов, но он работает.

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

Мы рассказываем азы: что делает продакт-менеджер, специфику работы, про общение с потребителями, с пользователями. Объясняем, что CustDev, делание, развитие через MVP — не какие-то хипстерские штуки, про которые пишут в статьях на медиуме и хабре. Это инструменты, приёмы и подходы для решения конкретных прикладных задач.

Людям сложно принять изменения, пока они не видят в них практическую ценность лично для себя.

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

Однажды выяснилось, что один аналитик начал делать что-то, что другой уже делал месяц назад. Это помогло избежать лишней работы и хорошо зашло ребятам. Я просто не стал эти встречи называть «дейликами».

Иногда кажется, что бесконечно работаешь над одними и теми же задачами, а большая колонка с выполненными стикерами и карточками мотивирует двигаться дальше. Стена со стикерами — это на самом деле такая канбан-доска.

С ретроспективой точно так же зашло. Мы работали, у нас периодически какие-то вопросы возникали. Потом стали собираться на час командой и разговаривать. Обсуждали, что сделано круто, что и как можно улучшить, на какие грабли наступили и как их избежать в дальнейшем.

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

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

По большому счёту, с ними похожая история. Обычно для директора Agile — это когда сроков назвать не могут, документация не ведётся, и когда задача будет сделана — вопрос. С его стороны ситуация выглядит так: приходят какие-то продакт-менеджеры, непонятно, что у них просить.

Реакция обычно такая: «Ок, у меня всё равно нет времени контролировать выполнение ваших задач. То, что вы присылаете, мне понятно. Прохождение крупных вех я вижу. Если мне зачем-то хочется посмотреть на выполнение маленьких задач, я их тоже увижу. Ну здорово, теперь понятно, почему мы внедряем продуктовый подход».

Тут главное не махать флагом с криком: «Мы продакт-менеджеры, у нас гипотезы». Не надо говорить непонятные слова, которые люди в лучшем случае слышали где-то или читали. Лучше наглядно показать, что всё неплохо работает.

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

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

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

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

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

В самом начале, когда мы начинали строить команду, мы все вместе ходили в магазины. Разработчики и Data scientist видели живых людей, с которыми можно просто поговорить. Когда человек пришёл за покупками, понятно, что он не хочет разговаривать с сумками в руках. Но, по крайней мере, наши ребята увидели, что с кулаками никто не бросается. Люди готовы беседовать, просто им неудобно: покупки, вечер, совершенно другое на уме.

Ребята увидели, что с пользователями можно разговаривать. Проверять некоторые предположения и гипотезы только на данных — долго. Можно взять и попросить живого человека ответить на вопросы. Например, это помогает проверять гипотезы по поводу механик вознаграждений или причин низкого чистого отклика. Теперь ребята не хотят сидеть и фантазировать, предлагают просто пойти и спросить. И я понимаю, что это здорово, всё сработало как надо.

В итоге выяснили, что количество баллов, которое мы даём, не стимулирует человека идти за покупкой. Вывод: можно и дальше закапывать время Data scientist в повышение точности, а можно — на самом деле нужно — поэкспериментировать с новыми механиками вознаграждений.

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

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

Сейчас мы стараемся не брать тех, кто говорит, что гибкий подход — плохо, а надо всё делать исключительно по вотерфоллу. Я бы не сказал, что есть какие-то чёткие критерии, по которым мы точно возьмём человека. Это зависит от потребности команды. Например, у нас есть команды, где за продакт-менеджера всю исследовательскую часть делает бизнес-аналитик. Так сложилось исторически, ну и почему бы и нет? Ценность создаётся и поставляется самым эффективным способом.

У нас гораздо меньше этапов, чем в «Яндексе», например. Мы не устраиваем полноценные технические секции. Продакт-менеджер должен понимать про функциональные и нефункциональные требования, про какую-нибудь диаграмму Ганта. В каких случаях её можно менять, а в каких — если переставить один квадратик, всё разъедется.

А вот в каком виде хранятся данные на кластерах, продакт-менеджеру при собеседовании знать не обязательно. За месяц погружения в предметную область всё равно разберётся.

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

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

Поэтому очень подробных собеседований мы не устраиваем. Проходимся по вопросам вроде: как работаешь, как принимаешь решения, как общаешься с командой, какие у тебя были проблемы, как у вас были выстроены процессы в предыдущей команде, как решал конфликты, как всё было выстроено в технологическом плане.

Ну, во-первых, тогда я не назвал бы себя мегаопытным продакт-менеджером. Я хотел систематизировать знания. Если просто смотреть темы по содержанию курса, то я это всё и так знал. Это нормально, потому что материалы про продакт-менеджменту в интернете уже годами выложены. С другой стороны, нужно это всё уложить в какую-то систему. Для этого я и пошёл.

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

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

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

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

Я дам два совета:

Первый — держите всегда в фокусе то, что вы хотите сделать. Цель постоянно должна быть в голове. Нужно спрашивать себя: «А укладывается ли то, что мы конкретно сейчас делаем, в нашу цель?» Может быть, этой активностью вы достигаете чего-то другого.

Второй — поменьше заморачиваться на инструментах. Инструмент результат не заменяет. То есть, нельзя сказать: «Ок, я не очень понимаю, что мы делаем и куда двигаемся, в чём проблема пользователя. Поэтому я буду полагаться на инструмент, а он всё сделает за меня».

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

#продактменеджмент #карьера