Не все продакты одинаково полезны

Как не впасть в карго-культ и создавать успешные тиражируемые продукты.

Я руковожу продуктовой разработкой и веду блог. Хочу поделиться осмыслением роли продакта сквозь призму опыта продуктовой разработки и общения на недавнем Product Sense’19.

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

Сразу оговорюсь, речь в статье идёт про реальный бизнес – коммерческие компании на самоокупаемости, которые мотивированы на зарабатывание денег и постоянно работают над повышением EBITDA. Я намеренно опускаю компании с гос. участием или особыми преференциями.

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

Тогда у меня возникло огромное желание перейти в сегмент здоровых коммерческих компаний, а в нём развивать тиражируемые аналитические продукты. Такой подход позволяет охватить весь сегмент SMB и принести пользу наибольшему количеству клиентов, одновременно повысив маржинальность. В Лаборатории Касперского, в направлении международного развития бизнеса портфеля B2B продуктов, я хорошо изучил и определил для себя дальнейшее стратегическое направление деятельности – облачные сервисы SaaS и PaaS. Из четырёх различных типов продуктов лучше всего масштабировался именно SaaS, все остальные требовали поддержки нескольких веток разработки и затратного обновления версий у каждого клиента.

Мне посчастливилось поработать с директором портфеля продуктов со стороны R&D и директором по развитию международного бизнеса в Бостоне. Поэтому я одинаково хорошо понимаю вызовы бизнеса и разработки, а также ограничения и мотивацию бэкофиса, несовершенство процессов пресейла и продаж при создании и выводе на международный рынок новых B2B продуктов.

После Лаборатории, вместе с командой единомышленников, в конце 2017 года я начал развивать продуктовое направление в крупном системном интеграторе. Мы до сих пор тратим немало сил, чтобы преодолевать неэффективность и медлительность крупной компании, привыкшей работать на гос. заказах с низкой операционной эффективностью. Частично помогают подходы быстрого прототипирования, Lean, CustDev, а также понимание процессов бэкофиса (например, с подрядчиком мы сразу подписываем рамочный договор, чтобы быстрее продлять работы). В истории, когда крупные компании создают внутри себя продуктовый акселератор, полностью преодолеть сдерживающие факторы развития можно только одним способом – выделив успешно прошедшую отбор команду с продуктом в отдельную компанию.

Порою, даже невозможно привить новую культуру работы в компании, потому что она конфликтует с ценностями директоров. А меняя директоров, нужно также менять весь административный аппарат, всю ту номенклатуру, которая невидимо поддерживает устоявшуюся неэффективность. Ещё есть хороший опыт с SLA между внутренними подразделениями в Сбербанке, если будет много запросов, напишу об этом отдельно. Как резюме – развивать инновационные ИТ продукты в крупной компании можно только при высокой автономности и поддержки руководства (право на ошибку в гипотезах, венчурный подход), с последующим выводом в новую компанию.

В стратегию развития продуктового направления, я заложил SaaS с минимальным циклом продаж и внедрения (до 1 месяца). Потому что именно длинные продажи и затратная интеграция съедают маржу и понижают тиражируемость.

С точки зрения технологий, мы сфокусировались на том, что хорошо знаем: бизнес-аналитика с применением технологий Big Data и Machine Learning (куда входят Deep Learning и остальные прикладные направления).

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

Я также думаю в сторону продуктов B2C, но там своя специфика – маркетинг вместо продаж, аналитика и A/B тесты вместо пресейлов и общения с клиентами. Мне лично нравится интервью и переговоры с клиентами и партнёрами, и я хочу сохранить это в работе. В одном аналитическом издании считают, что успешность B2B продуктов выше чем B2C. Возможно потому, что компании привыкли платить.

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

Именно на пересечении технологической и бизнес экспертизы, а также горящих глазах продакта, верящего в свою идею, мы создаём свои продукты. Если есть просадка в технологиях или непонимание бизнеса индустрии – может не получиться. Если продакт сам не верит в идею – он просто сдуется на сложном этапе и не сможет вдохновить команду. С одной из таких проблем мы столкнулись, разрабатывая MVP для студий разработки мобильных игр. Хорошего продуктового игрового аналитика оказалось очень сложно найти. А чтобы ещё умел писать модели машинного обучения или хотя бы знал основы для постановки задачи нашему Data Scientist – ещё сложнее.

Развивая продуктовое направление, я взял на себя роль драйвера, сея в сознание команды стратегию, ценности тиражируемого SaaS, преимущества работы на международном рынке. Далее, мы отрабатывали фазу Product Discovery для наших идей. В первом прототипе я выступил в ролях Product Manager и Product Owner (по scrum). Здесь сразу отмечу, чем эти роли отличаются. Не во всех компаниях известна и используется методология scrum в той мере, в которой ей учат в scrumalliance.org. Итак, начнём.

Во-первых, Product Manager - это роль в команде, создающей или развивающей продукты. Создание продукта проходит через определённые фазы, которые продакт должен знать и уметь, по мере возможностей и роста команды. Некоторые из фаз хорошо проиллюстрировал Сергей Тихомиров в своём проекте PAF. Я как практик уверен, что в фазе Discovery обязательно нужна проверка MVP хотя бы одним тестовым клиентом – чтобы понять, что задумка технически реализуема и частично решает боли клиента. Мы это обсудили с Сергеем в переписке и при личной встрече, но он пока занят наполнением проекта.

Роль Product Owner изначально более операционная, ранее она обеспечивала направление работ и перечень задач scrum-команде. И не важно, что команда делала – продукт, проект или заказную разработку. Важно, что с помощью scrum можно было быстрее увидеть первые результаты и, при необходимости, быстро перестроиться под изменившиеся требования. К быстрой, гибкой и итерационной работе призывает и Эрик Рис в своём Lean Startup. Я двумя руками за! Поэтому scrum используем, по мере возможностей и зрелости команды.

Во-вторых, можно выделить акценты в работе PM и PO. Рекомендую статью Евгения Зубака «Почему Product Manager и Product Owner — это не один человек». Позволю себе привести иллюстрацию из статьи:

Из иллюстрации можно увидеть, что Product Manager больше времени и внимания тратит на общение с внешним миром, анализ рынка и конкурентов, на изучение чаяний и нужд клиентов, придумывание и проверку продуктовых гипотез, финансовые расчёты. Для этого PM нужно уметь хорошо общаться и иметь структурное мышление для интерпретации интервью, анализа и расчётов. Мы к этому ещё вернёмся.

Иллюстрируемая схема решает большую головную боль бизнеса – как можно одновременно формировать стратегию, придумывать продуктовые идеи, анализировать рынок и конкурентов, проводить интервью и при этом детализировать задачи в бэклоге, их приоритезировать, думать над архитектурой и управлять командой? Ответ – разделив роли PM и PO. Особенно, если в команде больше 5 человек и слабая культура scrum.

Конечно, когда команда опытная и организованная, то участники сами чередуют роль Scrum Master, сами разбирают задачи на спринт, сами отслеживают результаты спринта и разбирают итоги (ретроспективу). В этом случае у Product Owner есть время на стратегию, исследования, анализ. Но даже в Каспере я такой зрелости не видел. Пока такие возможности остаются в теории или в США, где методология используется повсеместно много лет. Если кто знает продуктовые команды в РФ, научившиеся так работать по scrum – напишите в комментариях, буду рад познакомиться.

В реальности роль Scrum Master приходилось совмещать с Product Owner и регулярно планировать спринты, раздавать задачи контролировать их исполнение ежедневно. Поэтому PO был занят продуктом, как Project Manager проектом. Ещё раз – методологи scrum так не задумывали, просто требуется очень хорошо изучить методологию с командой и наработать практику. А мне, как практику, важно делать продукты как можно быстрее и эффективнее в текущих реалиях.

Кстати, похоже, методологи scrum пробуют объединить Product Manager с ролью Product Owner. Это можно увидеть, если пробежаться по статье Мелиссы Перри – Product Manager vs Product Owner от 2017 года и заглянуть в ней по ссылке на 2017 learning objectives for their Certified Scrum Product Owner Certification. А потом сравнить эти обязанности с текущим актуальным описанием Learning Objectives CERTIFIED SCRUM PRODUCT OWNER (CSPO). Например, можно увидеть, как в свежем CSPO отдельно выделены Advanced Customer Research and Product Discovery и Complex Product Assumption Validation. По-простому это CustDev, анализ рынка и конкурентов, генерирование и проверка гипотез. Знакомые задачи, не правда ли? Посмотрим, к чему это приведёт в США – может и удастся подружить эти роли. Но покуда у нас scrum в командах не привит на уровне привычек, придётся в больших командах разделять роли Product Manager и Product Owner.

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

Из недостатков повышенная загрузка при увеличении команды и развитии продукта, которая привела бы к низкой результативности всей команды. Во втором продукте я перешёл на уровень Head of Product, сохранив роль Product Manager, а Product Owner передал нашему техническому менеджеру и архитектору. В третьем продукте я частично делегировал роль Product Manager молодому специалисту, чтобы параллельно продолжать заниматься вторым продуктом.

Из преимуществ разделения ролей Product Manager и Product Owner отмечу больше возможностей заниматься изучением рынка и клиентов. При этом команда регулярно уплывала в не ту степь, потому что Product Owner переписывал сценарии использования в более технический вид, теряя связь с исходными пользовательскими запросами.

Несколько лет назад, когда я впервые прочитал про роль Product Manager, его сравнивали с мини CEO. Тогда я был очарован и верил этому. Потом понял, что это не так. Конечно, когда у меня продуктовый стартап из 2 человек, то я как CEO буду Product Manager и Product Owner, в то время как CTO будет писать код. Но потом, с развитием, у меня появится директор по продукту или CPO. А у того, в свою очередь Product Owner, а потом и Product Manager.

В компании от 100 человек, с уже существующим продуктом, Product Manager чаще выполняет функции Product Analyst. Ну честно, какие у него возможности? Нанимать людей не может, бюджетом напрямую не распоряжается, поддержки в команде мало, по сравнению с Product Owner или ресурсными руководителями. Бывают исключения, например в S7. Там продакт владел бюджетом и наймом. Зато там был другие перекосы, продактами называли проектных менеджеров, ибо заказное решение для одной компании является проектом. Пусть даже проектом по scrum, его не продашь другим компаниям.

В Лаборатории ролью, распоряжавшуюся бюджетом и наймом, отвечавшего за финансовые результаты называли Head of Product. У него в подчинении был Product Manager, а сам глава выполнял роль Product Owner но для руководителей команд анализа, разработки, тестирования и DevOps. Те, в свою очередь, проводили свои стендапы и планирования уже привычными методами. Мне эта структура понятна - хэд участвовал в политике, головой и репутацией отвечал перед топами, по сути вёл бизнес конкретного продукта или продуктового направления. В небольших продуктовых компаниях Head of Product может называться CPO.

С одной стороны, директор по развитию бизнеса головой отвечает за краткосрочные и долгосрочные финансовые результаты продукта. С другой стороны, CPO полностью отвечает за успешность продукта, которая тоже измеряется деньгами. Поэтому CPO часто курирует ключевые сделки в B2B. Поделитесь своим опытом и пониманием в комментариях, для меня это очень интересная тема.

Я знаю много продактов, которые выросли из бизнес-аналитиков. Некоторые ребята на недавно прошедшей в Москве конференции Product Sense’19 это подтвердили. Некоторые «выросли» до CPO, хотя по факту остались продактами или продуктовыми аналитиками. Часть должность красиво называется, а зона ответственности не определена, либо она совсем другая.

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

Если аналитик не может структурно мыслить, он не сможет пропустить через себя изучение рынка, структурировать его результаты в виде объёмов, конкурентов, сегментов. Также он не сможет структурировать результаты интервью или Customer Development. Нечего и говорить и прикидках срока ROI для фичей и общего, MRR и прочих оценок при защите продукта. Наоборот, хороший продуктовый аналитик сможет провести анализ рынка, конкурентов, провести серию интервью, сформулировать продуктовые гипотезы и определить их частотность в запросах пользователей, а потом прикинуть возможный экономический эффект и сложность реализации (с руководителем разработки, конечно). Далее Product Owner возьмёт результаты анализа, напишет сам или попросит аналитика расписать сценарии использования и запланирует работы.

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

2. Если продакт умеет структурно мыслить, но не может сформулировать стратегию развития и ключевые сценарии использования или не может договориться с Product Owner, чтобы на равных развивать продукт, то ему лучше побыть продуктовым аналитиком у PO и набраться опыта.

3. Если продакт может договориться с Product Owner, имеет стратегию, регулярно проводит интервью и исследования с последующей корректировкой позиционирования и фин. расчётов, то он на своём месте.

4. Если продакт хочет быть CPO или Head of Product, претендует на управление бюджетом, наймом и стратегией развития, он должен напрямую общаться с директорами, уметь отстаивать и обосновывать бюджет внутреннему или внешнему инвестору, а, главное, получать заданные показатели успешности. В этом случае продакт сможет развернуться как в своём бизнесе, так и в уже существующем.

Очень много ребят, желающих стать или уже объявивших себя продактами не умеют структурно мыслить. Многие из них ошибочно воспринимают роль продакта как что-то творческое, порхающее над непонятными занудами из ИТ и придумывающее гениальные гипотезы. Некоторые даже радуются, что гуманитарии. На практике очень быстро сдуваются и либо начинают учиться, либо начинают имитировать продакта, создавая культ карго. Для имитации можно жонглировать различными методологиями выявления и приоритезации гипотез, методиками оценки рынка, способами представления информации, а на практике не владеть в достаточной мере ни одной и уж тем более не понимать, как эту представленную информацию использовать.

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

До сих пор в описании вакансий встречается дичь, сплошь и рядом путают PM и PO, а ещё кого-только из продакта не пытаются сделать – и технического писателя и руководителя проектов, в общем каша. В продуктовых компаниях лучше, но всё ещё объединяют PM и PO. Зарплаты выросли, но ещё не дотягивают до уровня настоящего продакта.

Недавно общался с крупной продуктовой компанией, у которой около 15 продактов. Обсуждали возможности применения машинного обучения в различном функционале продукта. У них продакты похожи на продуктовых аналитиков. В Booking.com тоже, очень узкий фронт работ. Хотя, кому-то нравится полировать одну функцию продукта целый год. У меня аналогичных разговор был с разработчиками видеоигр – одни делали казуальные простые игры, но почти полностью, а другие какого-нибудь Ведьмака, но маленькую часть. В итоге, и те и другие довольны.

Иван Шмелёв aka Ivano Digital в середине 2018 написал нашумевшую статью «Приключения Продакта в России». В ней Иван в ярких красках описывает дикость и неверное понимание ролей и обязанностей компаниями, а также скудные зарплаты. Я списался с Иваном, а потом мы встретились и плотно переговорили по проблемам и зрелости рынка в целом.

По результатам общения у меня сложилось мнение, что не всё так плохо у компаний. Где-то Иван чрезмерно сгустил краски, а где-то уже продвигал себя как эксперта. Для меня, например, слова цифровая трансформация - как красная тряпка у быка. А ему наоборот, это направление интересно. В одном мы едины – рынку продуктовой разработки в РФ предстоит ещё развиваться и многому учиться. И делать это нужно быстрее, чтобы быть конкурентными на международном рынке.

1. Если продакт создаёт новый продукт или развивает стратегическое направление, то оплата и система мотивации должны быть соответствующе высокими. Опцион для продакта и PO увеличивает долгосрочную мотивацию и вероятность достижения бизнес-результатов. Если мне кто-то скажет, что понятие опциона отсутствует в РФ, я предложу его денежный эквивалент в % от стоимости компании на момент прохождения КТ по заранее согласованному способу оценки. Новые продукты создавать это вам не семечками на базаре торговать.

2. Также хорошо показала себя денежная премия ключевым создателям продукта за успешно завершённые этапы, длительностью 1-2 месяца (максимум 3). Самая большая премия на этапе Discovery должна быть за успешно созданный MVP с одновременным завершением пилота у первого тестового клиента. При таком стечении обстоятельств, это сразу и первая продажа и пресс-релиз в рынок о новом продукте. Дальше начнётся разработка основного продукта и наращиванием продаж. KPI соответственно на релиз продукта и на объём продаж.

3. Условия для работы продакта должны быть максимально гибкими. Потому что ни одна продуктовая идея не приходит при сидении в офисе молча за компом. Это всегда общение, обсуждение, встреча, прогулка – какое-то движение. Полезно, когда продакт регулярно встречается с другими продактами на митапах, конфах, вебинарах. Если компании большие – удачным решением будет устраивать у себя продуктовые встречи, открытые обсуждения проблем с поиском решения, но не замыкаться на них. Несмотря на гибкий график, продакт должен каждый день плотно общаться с PO, обмениваться с ним мыслями, наработками. А ещё вместе с PO общаться с командой на регулярной основе, напитывать их видением пользы и сценариями использования, которые даже у разработчика формируют понимание что, зачем и почему пользователю нужно.

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

Активно развивается работа в распределённых командах. Наши ребята тоже такой опыт получили, работая с подрядчиком, люди которого работают в разных городах России. При этом все постоянно на связи в скайпе, стоит только микрофон включить и задать вопрос. По признанию нашего Data Scientist такое чувство, что в соседних комнатах сидим. А у меня подобный опыт с международной командой, работающей на нескольких материках. Создание у себя распределённых команд позволяет работать с лучшими экспертами в разных городах и странах, это мощное конкурентное преимущество.

С точки зрения обучения продактов, большую работу делают Миша Карпов, Рома Абрамов, Юра Агеев проводя обучение Product Star и конференции Product Sense. Мне понравился формат обучения Product Star (проходил весной 2018-го). Большое спасибо ребятам из Яндекса и Mail.ru за запуск своих продуктовых академий. Понятно, для себя учат, но всё равно рынку это пойдёт на пользу.

Автор любимой книги, Роб оказался очень общительным. Мы проговорили минут 30 за жизнь и я посоветовал ему с женой сходить вечером в ресторан Sixty, насладиться видами вечерней Москвы с 60-го этажа Москва-Сити. Удивительно, как его книга так хорошо зашла нашим читателям, столько лет уже прошло, а Роба помнят и зовут. На этой конференции Роб провёл своё обучение. Кто из вас был, напишите что было интересного в комментариях.

В связи с тем, что сообщество продактов у нас молодое, среди докладчиков и слушателей было очень мало хэдов и CPO. Доклады больше общеобразовательные, чем про бизнес. Общаясь с коллегами на перерывах, сошлись во мнении что уже в следующем году сообщество можно сегментировать по зрелости и выделять группу продуктовых аналитиков и группу, близкую к CEO (CPO, Head of Product). Мне конечно очень не хватает последней, чтобы обсуждать бизнес, делиться тем что получается и перенимать опыт. Возможно это клуб продуктовых предпринимателей. Если такой уже где-то создан – пожалуйста, поделитесь.

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

Недавно, Mail.ru провёл конференцию по развитию облачного рынка РФ и собрал за круглым столом представителей некоторых крупных облачных провайдеров. Все вместе искали драйверы роста рынков IaaS PaaS и SaaS.

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

Кстати, у Лаборатории уже несколько лет действует свой продуктовый акселератор, направленный на международный рынок. Сейчас, насколько мне известно, ЛК сняла строгое ограничение на cyber security. Но ИМХО, если стартап станет портфельной компанией, ему будет полезно быть близким к бизнесу компании, чтобы использовать все наработки.

Я сам продолжаю работу над новыми аналитическими сервисами SaaS с планами вывода на международный рынок. Работая с данными, продолжаю прорабатывать применение машинного обучения в прикладных сервисах – в предсказаниях по поведенческим паттернам, в распознавании объектов и голоса. С ML-моделями поверх данных получаются удобные и функциональные сервисы, облегчающие жизнь людям. Есть у меня желание делиться знаниями и наработками с коллегами по цеху SaaS/PaaS, поэтому думаю в сторону менторства и обучения.

А напоследок анекдот. Сохраняйте здравый смысл в своей работе, несмотря на новые роли и методологии.

Напоминаю об интересных вопросах:

1. Пример эффективной, самоорганизованной, продуктовой scrum команды в РФ?

2. Про взаимодействие CBDO и CPO при выводе новых продуктов, кто весомее?

Буду рад вашим комментариям. Для личной переписки доступен в фейсбуке - www.facebook.com/tmishin