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

Я работаю менеджером по продукту в ИТ, и в прошлом году перешел из компании поменьше в DataLine, где как раз начались интенсивные изменения в управлении продуктами.

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

Как выглядела работа продакта в небольшой компании

Для начала напомню, чем занимается сферический продуктовый менеджер в вакууме.

Цели и задачи. Основная задача продакта ― взять технический бэкграунд компании и развить на его базе продукты, которые интересны клиентам и рентабельны для бизнеса. С одной стороны, нужно понимать целевой рынок, с другой ― приземлить потребности рынка на ресурсы и ограничения компании.

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

Этапы вывода на рынок. Обобщенно стадии работы с продуктом выглядят так:

1. Исследования и поиск идей. Здесь появляются модные слова: custdev, CJM и другие. Почерпнуть идеи для продуктов можно извне, под влиянием рынка, или внутри компании. Например, идея реализована в компании, но мы находим важные для клиента фичи.

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

   Есть ограничение: MVP не должен дорого обходиться бизнесу. Мы не можем на несколько месяцев отвлечь инженеров от деятельности, которая приносит деньги. По моим наблюдениям, 90% работы на этапе MVP все равно делает продакт.

3. «Продажа» идеи внутренним инвесторам. Если MVP успешен, продакт-менеджер готовит технико-экономическое обоснование для владельцев бизнеса: калькуляцию, итоги сравнения с конкурирующими продуктами. Появляется финансовая документация, примерные цифры, по которым мы решаем, пойдет ли идея в реализацию.
4. Вывод на рынок. Если с цифрами все хорошо, подключаем людей из разных отделов: не только технических специалистов, но и маркетологов, потому что реализованную идею нужно презентовать рынку.
5. Доработка, учет обратной связи. Любой продукт развивается, улучшается, модернизируется. Взяв что-то за основу, мы продолжаем пилить его до условного совершенства.

Это очень общее описание схемы работы продакта, выглядит просто и понятно. Схему легко адаптировать под себя.

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

Какие трудности есть при развитии зрелых облачных продуктов

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

Продакт-менеджер придумывает идеи без погружения в предметку

Чтобы этого не произошло, нужен минимум один из факторов:

1. Налажен поиск гипотез среди сотрудников-непродактов. Большинство идей в нашей сфере ― предложения от опытных коллег.
2. Уже есть опыт работы с аналогичными сервисами. Если специалист работал с облаками, некоторые идеи он может принести с прошлого места работы. Но не каждая такая идея приживется. Со стороны услуги разных сервис-провайдеров кажутся идентичными, но по факту каждый облачный провайдер эксплуатирует ресурсы и налаживает бизнес-процессы по-разному. Поэтому см. пункт 3.
3. Продакт прошел полный цикл адаптации в компании, изучил бэкграунд бизнеса и процессы производства. Ассимиляция продакт-менеджера в нашей сфере продолжается не меньше года.

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

Тестирование гипотез. В небольшой компании большинство MVP мне удавалось реализовать самостоятельно или с привлечением технических специалистов на условные 10%. Для самостоятельного создания прототипа хватало таких навыков:

• развернуть виртуалку;
• настроить Linux или Windows;
• развернуть какую-то софтинку, например, что-то с GitLab, GitHub, с Docker;
• возможно, написать пару скриптов.

Если под рукой техническая документация с хорошей навигацией, проблем нет.

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

1. В маленьком провайдере менее разветвленная структура, больше специалистов, которые совмещают несколько функций. Глубоко разбираться в какой-то области может только один человек, часто сильно загруженный. Быстро привлечь таких технических специалистов к MVP не получится, нужно вставать в очередь. Продакту волей-неволей приходится осваивать технические знания самостоятельно, чтобы «бутылочных горлышек» в процессе становилось меньше.
2. В крупной компании в производство вовлечено много отделов со своей специализацией. На нашем примере: есть отдельные группы специалистов по Linux, Windows, Kubernetes, резервному копированию, базам данных и так далее. Чаще всего для зрелых сервисов работа распределяется по нескольким специалистам, и каждый делает свой кусок задачи, где он разбирается лучше всего.

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

«Продажа» идеи внутренним инвесторам. На этом этапе тоже многое зависит от размера компании:

1. В небольшой компании цепочка согласования меньше. Можно быстрее о чем-то договориться, согласовать условия и вывести MVP на следующий этап. Компании это тоже выгодно, так как быстрые решения ускоряют получение первых результатов, «оборачиваемость» идеи становится выше.
2. В крупном бизнесе процесс согласования устроен чуть сложнее. Изменение большого сервиса затрагивает много заинтересованных групп, нужно получить одобрение не одного человека, а, допустим, трех-четырех. Для каждого из них нужны свои аргументы. Например, на этом этапе продакт не только находит общий язык с производственным департаментом, но и договаривается с коммерческим блоком по поводу продвижения. Здесь возникает больше нюансов по работе с брендом: у позиционирования большого бизнеса свои особенности, цена ошибки часто выше.

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

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

Когда мы устанавливаем обновление на уже доработанный софт, не все может пойти гладко «из коробки». Чтобы обновление не сломало полезную функциональность, нужны технические специалисты со знанием всех деталей доработанного софта. Точно так же MVP из «песочницы» продакта может вступить в конфликт с промышленной облачной платформой.

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

Как видим, с ростом компании возникает сразу несколько особенностей, которые требуют другого продуктового подхода. Поэтому передаю слово Алексею ― он расскажет, как в DataLine был устроен переход к продуктовому подходу с внутренними стартапами.

Как мы управляем развитием сложных продуктов сейчас

Цели изменений. Пока DataLine была небольшой, простое разделение команд по функциональному принципу работало хорошо. Затем для сложных клиентских проектов потребовался новый подход, и появились ТАМы (о чем мы уже рассказывали).

Со временем продуктовое направление тоже усложнилось:

• комплексными и многосоставными стали не только проекты, но и продукты;
• продуктовая линейка расширилась, стало физически невозможно уделять всем одинаковый объем внимания и ресурсов;
• под влиянием пандемии некоторые сервисы требовали особенно быстрого развития, например, VDI. Для их доработки не подходила схема, когда продакт ищет временную команду в функциональных группах инженеров. Возникали ситуации: продакт прибежал в производственный отдел и срочно просит подключиться;
• сложнее становились процессы продвижения: появлялось больше разных каналов общения с клиентами, усложнялся пресейл.

В этой ситуации мы поняли, что нам необходимо фокусироваться на приоритетных сервисах и при этом не терять гибкость. Для изменений мы выбрали 4 комплексных продукта, которым не хватало более пристального внимания: VDI, DBaaS, WAF, NGFW. В этих направлениях было важно отвечать на клиентские потребности быстрее, и мы решили развивать их как внутренние мини-стартапы. Вот какие задачи поставили:

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

Команда. Вокруг этих сервисов сформировали постоянные команды, где каждый знает продукт вдоль и поперек в рамках своей специализации и вовлечен в него полностью. Сейчас там такие роли:

1. product owner (РО), или владелец продукта;
2. продуктовый маркетолог (PMM);
3. менеджер по продажам;
4. выделенные инженеры функциональных групп.

Самым главным нововведением стало то, что в роли владельцев продукта выступили инженеры профильных групп:

• для VDI ― инженер группы Microsoft;
• для DBaaS ― архитектор баз данных;
• для WAF и NGFW ― специалисты центра киберзащиты.

Это позволило сосредоточиться на развитии и улучшении продуктов с точки зрения технической экспертизы. Заодно стало проще организовать работу инженеров функциональных групп с учетом используемых технологических фреймворков.

Каждой команде выделили минимум 2-3 инженеров. Сейчас эти специалисты занимаются только одним продуктом и постоянно ротируются между задачами развития и поддержки:

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

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

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

Процессы и подходы. Раньше в функциональных группах была относительная свобода в использовании управленческих методов: где-то могли ориентироваться на Kanban, где-то на старый добрый waterfall. Но сформированные продуктовые команды мы решили объединить общим подходом и остановились на scrum.

По каждому продукту мы движемся двухнедельными спринтами. Скрам-мастер у нас пока один на все команды: он помогает не съехать с этого пути и поддерживает единый порядок по всем продуктам.

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

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

1. Исследование и поиск идей: бэклог стал более насыщенным. Он пополняется с трех сторон: из продуктового анализа рынка, из обращений и анкет клиентов, из общения продакт-сейлов с потенциальными клиентами.
2. MVP: ускорился цикл тестирования идеи. В числе прочего мы стали быстрее закупать оборудование для тестов. У продуктовых команд повысился статус, и, следовательно, для таких закупок повысили приоритет. Тесты гипотез теперь делает вся команда и смотрит на MVP c совершенно разных сторон.
3. «Продавать» идею внутренним инвесторам стало проще благодаря регулярным продуктовым комитетам — не нужно ни за кем бегать.
4. Для вывода на рынок тоже есть больше выделенных ресурсов в маркетинге и продажах.

Но, конечно, нам еще есть над чем работать в этом направлении.

Трудности внедрения. С чем мы столкнулись при переходе на внутренние стартапы:

• Инженерам нужно было время, чтобы перестроиться и примерить на себя роль PO-внутреннего предпринимателя. В их деятельности появились новые бизнесовые метрики, с которыми они не привыкли работать. Мы постарались смягчить этот процесс за счет дополнительного обучения по управлению продуктами. Делимся знаниями и рекомендуем друг другу полезные ресурсы.
• Взаимодействие со смежными отделами тоже наладилось не сразу. Коллегам нужно было привыкнуть к новым ролям: теперь инженеры приходят к маркетологам, аналитикам и сервис-менеджерам с бизнесовыми вопросами.
• Стали появляться новые задачи для нашей системы аналитики. Продуктовые команды захотели получать больше информации, потребовались новые отчеты.

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

Бонус: что почитать для развития внутреннего предпринимательства

Общие продуктовые знания

1. Создавая инновации. Клейтон Кристенсен.

   Книга рассказывает, как шло развитие таких компаний как Netflix, Amazon, Google.

   Описываются первые шаги, которые привели к хорошим показателям и провалам. Очень интересно, если уже быть в курсе, что это за компании и как они работают.

   Рекомендую после нее перейти к «На крючке» (Inspired) Марти Кеган.

2. На крючке. Нира Эяль.

   О том, как формировать и создавать продукты, которые будут незаменимы или войдут в привычку.

   Концепция книги так и сформулирована: «эффект крючка» позволит создать продукт, который зацепит пользователя и не отпустит его.

   Рекомендации: чисто продуктовая книга, но для общего развития можно и ребятам из проектных команд.

Проектное управление

3. Intercom on Product Management.

   Сборник рассказов о проектах от ПМ в крупных компаниях: Basecamp, Homebrew, HubSpot.

   Основной смысл: как составить roadmap проекта и какие задачи в него включить. Как говорить «нет» проекту и уметь это «нет» обосновать.

4. Lean Analytics. Alistair Croll and Benjamin Yoskovitz.

   Книга помогает правильно выстраивать аналитику для ведения проектов. Авторы сделали свой фреймворк для развития стартапа и поделили его на области, основываясь на разных фреймворках. Рассказывают, как применять аналитику для каждой области развития.

   Лучше всего ее читать после «Бизнес с нуля. Метод Lean Startup».

5. На крючке (в оригинале ― «Inspired»). Как создавать продукты-хиты. Марти Кеган.

   Основная мысль книги в том, что есть большая разница в создании продуктов: как это делают большие компании и как это делают стартапы и маленькие компании. Автор книги рассказывает и делится опытом, как он работал и создавал продукты в Netflix, Amazon, Google.

   Еще одна книга для чисто проджектов, но читается легко и интересно.

6. Путь камикадзе. Эдвард Йордон.

   Книга для более опытных коллег, рассказывает о проблемах в сложных проектах. Рассматриваются безнадежные случаи и даются советы по их ведению. Если кажется, что проект обречен, автор предлагает сконцентрироваться на других аспектах. Например, как правильно вести переговоры, как расставлять приоритеты или как максимально использовать доступные вам ресурсы. Он объясняет, когда следует быть гибким, а когда, наоборот, лучше проявить настойчивость. И самое главное — как самому понять, что пора выйти из проекта.

Управление людьми и собой

7. Deadline. Том ДеМарко.

   Книга помогает формировать команду для работы над проектами, дает практические советы по подбору людей, на что обращать внимание, как выявлять сильные и слабые стороны людей и как делать команду, соблюдающую баланс.

   Рекомендация к прочтению ― для руководителей и HR.

8. Легкий способ перестать откладывать дела на потом. Нейл Фьоре.

   В целом все сказано в названии книги. Основная мысль: как бороться с прокрастинацией при решении любой задачи. Очень интересно описаны варианты, как ее победить.

   Полезно будет всем.

9. Начни с почему. Саймон Синек.

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

Продвижение в ИТ

10. Преодоление пропасти. Джеффри Мур.

    Издание 2006 года, на данный момент уже немного устаревшее. Книгу по-прежнему называют основной для маркетинга в хайтек-компаниях. Есть переиздание 2013 года.

    Основной упор автор сделал на позиционирование продаж для массового рынка.

11. От нуля к единице. Питер Тиль.

    Книгу написал сооснователь PayPal и инвестор Linkedin, Yelp.

    Автор конфронтирует со всеми стандартными форматами развития стартапов. Основной посыл: нужно искать ценное в неожиданных местах.

    Рекомендация к прочтению ― тем, кто занимается развитием и продвижением.

12. Метод StoryBrand. Дональд Миллер.

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