Всем привет! Меня зовут Сергей Сжёнов. Более 15 лет я работаю в ИТ-индустрии, а сейчас отвечаю за развитие облачных продуктов в beeline cloud.

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

Запускаем новый продукт — что нужно знать на старте? 

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

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

 Что самое важное при создании продукта?

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

Нам кажется, что мы знаем, что нужно покупателю, но чаще всего ошибаемся. И пусть мы знаем свое дело — мы все равно ошибаемся © Адам Писони, директор по продажам Yammer

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

Вот какие артефакты необходимо подготовить:

  • Видение продукта

    • Определите вашу ЦА

    • Опишите ее потребности

    • Опишите идею и ключевые возможности вашего продукта. Какие проблемы решает продукт? Это будет что-то новое для рынка или же продукт аналогичен уже существующим? В чем тогда отличие и ценность для клиента?

    • Определите, какая ваша цель и как вы планируете ее достигнуть?

  • Исследование рынка

    • определите сегмент и рынок (отечественный или зарубежный)

    • определите уровень проникновения конкурентных решений на рынок

    • выполните оценку объема рынка: TAM-SAM-SOM

  • Unit-экономика и бизнес-кейс

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

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

Waterfall vs Agile

А теперь немного поговорим о методологии. Уверен, вы не раз слышали про Waterfall и Agile (Scrum или Kanban). Каждый из подходов имеет свои плюсы и минусы. Какой вариант выбрать, зависит от многих факторов и культуры внутри компании. Но не стоит строго следовать какому-то одному варианту. Вполне возможно, что у вас будет иной подход. Главное, чтобы он приводил к результатам, которые устраивают все заинтересованные стороны.

На практике я пробовал все нижеуказанные варианты. Когда речь идет про реализацию проектов (тут важно понимать разницу между проектом и продуктом), я бы рекомендовал Waterfall с четким графиком, взаимосвязями и пошаговым процессом. 

В продуктовом подходе, когда требовалось оперативно вносить изменения, я использовал Agile. Причем одна моя команда работала по Scrum, другая — по Kanban. С разными командами мы запускали несколько различных продуктов.

Когда подходит Waterfall

Когда подходит Agile

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

Вам необходимо вносить изменения на каждом этапе реализации.

Вы реализуете проект, а не продукт. Продукт может быть результатом проекта, но не наоборот.

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

Вы сформировали ТЗ для выполнения задачи. Предполагается, что в ходе реализации проекта не будут вноситься изменения.

Вы будете участвовать в реализации проекта на всех этапах: от идеи до выхода на рынок и последующего развития.

У команды есть опыт реализации проектов и работы по этой методологии.

У команды уже есть опыт реализации продуктов и работы по методологии Scrum или Kanban.

Разработка продукта

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

Например, процесс разработки продуктов может включать следующие варианты (или другие):

Как видите, принцип у всех один и можно выделить несколько основных этапов:

  • Формирование идеи.

  • Анализ и исследования.

  • Разработка (прототип, MPV, продукт).

  • Запуск в коммерцию с последующим развитием.

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

Сценарии ошибок

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

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

  • Определите свое отношение к MVP (Minimum Viable Product), у многих оно двоякое. На какой стороне вы? 

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

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

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

Компетенции

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

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

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

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

В управлении у senior может находиться до пяти продуктов (большим количеством становится сложно управлять), компетенции должны включать в себя опыт управления как менеджерами, так и продуктами (в общей сложности от шести лет).

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

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

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

А если вы тоже запускали продукт — поделитесь в комментариях, с какими трудностями сталкивались? 


Что еще почитать про запуск и разработку продуктов

beeline cloud — secure cloud provider. Разрабатываем облачные решения, чтобы вы предоставляли клиентам лучшие сервисы.

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