Рус
Eng
Привет, меня зовут Миролюбов Владимир
Моя специальность — продакт-менеджмент и онлайн-бизнес. Изучаю психологию и философию. Делюсь разными идеями и мыслями на все эти темы. Больше обо мне тут.
17 April, 2017 in Книга

Рост продукта

grow-mj

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

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

Несмотря на это, я бы предложил делить дорожные карты на два направления:

  • Функциональная дорожная карта
  • Маркетинговая дорожная карта

На самом деле, эти две вещи взаимосвязаны, поэтому давайте рассмотрим и разложим на столе каждую из этих колод по порядку.

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

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

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

Какими бывают дорожные карты по продолжительности? Обычно они делятся в зависимости от текущего этапа проекта. Я делю дорожные карты на несколько типов, главное различие в которых — в их количествах и сроках их реализации. Всего их три:

  • краткосрочные (от 1 недели до 1 месяца);
  • среднесрочные (от 1 месяца до 6 месяцев);
  • долгосрочные (от 6 месяцев до 1+ года).

Логика с ними простая простая. Если ваш проект еще не окупается, то строить планы более чем на 1 месяц  бессмысленно. Живите “текущим днем”, держите руку на пульсе продукта, получайте и изучайте обратную связь, оперативно закрывайте дыры/баги, фиксите и совершенствуйте свой продукт. Всё что вам нужно на текущем этапе — искать, находить и удовлетворять потребности ваших пользователей, которые должны платить за ваш продукт. Родмап забивается фичами, приоритет реализации которых постоянно перемешивается и меняется.

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

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

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

Когда продукт успешно работает, пользователи рады, а деньги у продукта уже есть, то необходимо их 1) сохранить 2) увеличить, поэтому долгосрочные родмапы сроком от 6 месяцев и свыше года могут позволить себе продукты, которые уже вышли на окупаемость и уже приносят прибыль. На этом этапе настало время стратегического планирования, более бизнесовых решений в виде выхода на новые рынки/страны, поглощений конкурентов или продуктов с целевой аудиторий, в общем, решений, которые требуют максимально взвешенной, детальной подготовки и планирования.

Внимание от самого продукта и его функционала больше смещается в сторону его эффективного управления (именно поэтому большие продукты медленнее растут) и масштабирования прибыли. Планирование на год(а) вперед — лучшее для этого решение.

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

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

  1. лояльность и(или) активность пользователей;
  2. деньги пользователей.

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

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

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

  • Новая фича принесет новых пользователей?
  • Новая фича увеличит лояльность/активность текущих пользователей?
  • Новая фича увеличит средний чек от текущих пользователей?

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

Откуда брать идеи для фич? Вопрос простой и сложный одновременно. Есть два основных источника идей для расширения функционала продукта:

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

Все, нет, АБСОЛЮТНО ВСЕ идеи в обязательном порядке должны записываться вами либо в таск-менеджере, либо в каком-то еще документе, разделяя их на идеи, которые идут от вас или команды и на идеи, которые идут от пользователей. И умение продукт-менеджера в том, чтобы балансировать между этими двумя целями и находить между ними золотую середину. И если с первым источником идей понятно, то со вторым есть несколько вариантов откуда их брать.

Ниже в тексте вы найдете упоминание такой онлайн-метрики как NPS, обозначающую уровень удовлетворенности пользователями вашим продуктом. Одновременно с ее замером вы также можете использовать простейшую форму-запрос “Что бы вы хотели, чтобы мы улучшили?”, позволяющую пользователям рассказать вам о том, что им кажется недоработанным в функционале вашего продукта.

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

Поделюсь еще одной мыслью, которую можно использовать при определении необходимости разработки той или иной функции, кажущейся вам крайне полезной и необходимой, а именно:

по-настоящему  хорошая идея должна отстояться

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

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

Идем далее. Поделюсь с вами еще одной практической фишкой, которая выручала меня много раз и которую я называю “Разработать с учётом…”  —  фразой, которую, на мой взгляд, должен использовать каждый продукт-менеджер в постановке задач для тимлида или команды разработки на новые фичи в продукте.

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

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

Вы, как “добренький PM”, решили пойти им навстречу и дать ограниченный доступ к первым 10 объектам из этой базы данных, чтобы пользователи могли посмотреть её примеры. Само собой, это надо пилить, а значит, надо формулировать стори и ставить задачи команде разработки.

Но вы знаете, что через пару недель в разработку уйдет уже другой спринт с платной подпиской на доступ к этой самой базе данных без обязательного заполнения пользователями брифа. Именно поэтому при постановке задачи на ограниченный доступ к первым 10 объектам было бы не лишним написать и обозначить разработчикам, что эту фичу нужно “Разработать с учетом” того, что через НН недель будет еще одна фича, связанная с платным доступом и которая по механике и коду будет затрагивать эту же область.

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

Вернуться назад Читать далее

23 April in Книга
0

Переходим к дальнейшей стадии. Как расти и развивать свой продукт? Ответ на этот вопрос мы будем искать в разрезе процесса эффективного и правильного развития функциональности, а не в росте бюджетов на маркетинг и пользовательской базе. Наверное, вы не раз слышали о таком термине как дорожная карта или roadmap. Эта штука позволяет продукт-менеджерам систематизировать всю поступающую […]

22 April in Книга
0

Переходим к дальнейшей стадии. Как расти и развивать свой продукт? Ответ на этот вопрос мы будем искать в разрезе процесса эффективного и правильного развития функциональности, а не в росте бюджетов на маркетинг и пользовательской базе. Наверное, вы не раз слышали о таком термине как дорожная карта или roadmap. Эта штука позволяет продукт-менеджерам систематизировать всю поступающую […]