Авторы английской версии: Дес Трейнор (Des Traynor), co-founder and the Chief Strategy Officer of Intercom; Пол Адамс (Paul Adams), Chief Product Officer at Intercom; Алисса Смрекар (Alyssa Smrekar), VP of Corporate Marketing, Intercom; Эоган МакКейб (Eoghan McCabe), co-founder Intercom. Cреди клиентов Intercom: Notion, Amplitude, Microsoft, Unity, Amazon, Atlassian;
Перед вами перевод бесплатного курса «Product Management» от компании Intercom. Над переводом работали Ринат Шайхутдинов, Ольга Жолудова и Анастасия Свеженцева.
Итак, поехали. Вы продакт менеджер? Основатель стартапа? Генеральный директор (CEO)? Технический директор (CTO)? Руководитель отдела дизайна? Какой бы ни была ваша должность, предположим, что вы принимаете решения в продукте. Какую функциональность (фичи) разрабатывать, когда лучше это делать, как помочь пользователям начать пользоваться новинками, и так далее.
Содержание:
- Фреймворк продакт-менеджера и рекомендации по анализу текущей ситуации в продукте | Глава 1
- Стратегия развития продукта: с чего начать, как найти слабые места, точки роста в продукте и что включить в родмап? | Глава 2
- Какие фичи и функции включить в план следующими | Глава 3 (в процессе)
- Как анонсировать новые функции и выводить их в рынок | Глава 4 (в процессе)
У всех, кто совершенствует продукт, есть большие надежды и мечты о том, как продукт будет развиваться в реальном мире. У вас наверняка есть блокнот, полный идей, из которых наверняка появится что-то вроде Uber, Slack или Fb. Но прежде чем вы начнете делать роадмап (product roadmap), который приведет ваш продукт к такой высоте, проанализируйте и внимательно изучите, что же сейчас происходит в вашем продукте.
Что на самом деле пользователи делают с вашим продуктом? Как именно они им пользуются?
Все ли функции (features) они используют? Конечно, нет. Давайте начнем разговор с этого.
При планировании новой функциональности (roadmap) и распределении ресурсов команды, полезным бывает спросить: «Сколько клиентов на самом деле использует каждую из фичей в продукте?». Это одна из ключевых техник (101) в продуктовом менеджменте, которая потребует от вас несколько минут на SQL-запрос или несколько секунд в продуктах Intercom, чтобы это узнать. Затем примените простой способ визуализации использования функциональности в продукте — расположите его на двух осях: как много людей пользуется и как часто.
В результате получится что-то похожее на такую таблицу:
Основная функциональность (и ключевая ценность) будет находиться в правом верхнем углу — это то, чем люди действительно пользуются.
Заметка: исключите функции «администрирования» вроде регистрации, восстановления пароля и тд. Здесь они не важны. Также исключите функциональность, доступную только определенным пользователям (например из enterprise-сегмента). Ее стоит оценить отдельно.
Функциональность в левом верхнем углу — это те функции, которые используется не в полной мере и их требуется доработать; они нужны небольшому количеству пользователей, но они ими почти не пользуются.
Еще один вариант анализа через визуализацию ответа на вопрос: «Какой процент ваших пользователей научились пользоваться функцией и извлекают ценность (product adoption)?». Для этого можно сделать график. Предположим как этот, что похож на продукт мечты. Тот, который мы все думаем, что создаем, когда у нас открыты редакторы (например Figma, InVision Studio или Photoshop). Все же пользователи будут использовать и любить все эти функции, верно? Иначе зачем мы их делаем?
Пожалуй, каждый продакт-менеджер знает, что суровая реальность выглядит как-то так:
Как же так вышло? Вы создали продукт, в котором есть отличный мессенджер, а также функции редактирования файлов и документов. Об этих функциях вы рассказываете на лендинге, они описаны в документации со вкусными скриншотами, также про них рассказывается в туре по продукту, и каждый новый пользователь влюбляется в них.
Но успех — плохой учитель. В таком потоке легко подумать, что вы больше не будете ошибаться и каждая новая функция станет успешной.
Затем вы добавляете чат, но он не заходит пользователям. Затем календарь, и снова показатели ниже ожидаемых. Никто не создал больше одной записи, а вы сами даже не упомянули о нем на сайте. А недавно вы добавили функцию учета времени, которая зашла только некоторым пользователям.
В общем, это ваш продукт, и вы можете это исправить.
Заметка о подрывных инновациях, распылении и фокусировке
Если вы наблюдаете такое распределение использования функций в продукте, то у вас отличный продукт для одного конкретного сценария и куча других частей, которыми никто не пользуется. Представьте Hangouts внутри Google+, в качестве примера, или дополнительный примитивный редактор документов (типа BUI) внутри Microsoft Word.
Если вы смотрите на такой график, то вы уязвимы для ребят с подрывной инновацией (disruption). Кто-то может создать простой продукт, сфокусированный на одной функции (key feature), и сделать её лучше (дешевле, быстрее, проще и т.д.). А вам будет сложно с ними конкурировать из-за множества других дополнительных функций, которые усложняют продукт и тянут как груз.
Что делать дальше с результатами аудита продукта?
Для любой функциональности с небольшим количеством пользователей, которые применяют ее и успешно извлекают ценность (product adoption) у вас четыре варианта:
- Удалить: признать поражение и убрать ее из продукта
- Увеличить число пользователей
- Увеличить частоту использования
- Целенаправленно улучшать для тех пользователей, которые ей пользуются
Можно визуализировать ситуацию следующим образом:
Как улучшать фичи
Кайдзен — философия непрерывного совершенствования. Все digital-компании в поисках рынков для своих продуктов так или иначе действуют в рамках Кайдзену, даже если они не осознают это.
Релиз нового кода не означает, что вы что-то улучшили. Вы можете сделать клевое улучшение в продукте и не получить никакого эффекта. Всё сводится к тому, какие именно улучшения вы делаете.
Два самых популярных способа улучшить продукты — это добавление новой функциональности или улучшение существующей. Для начала мы посмотрим на способы улучшения существующей функциональности, а к новой перейдем в следующей главе.
Улучшение существующей функциональности
Существующую функциональность можно улучшить тремя разными способами:
- улучшить (преднамеренное улучшение / deliberate improvement)
- доработать так, чтобы чаще пользовались (повысить частоту / frequency)
- сделать так, чтобы пользовалось больше людей (увеличить долю пользователей, которые освоились с функцией и начали достигать значимых целей / product adoption)
1. Преднамеренное улучшение (deliberate improvement)
Это когда вы точно знаете, зачем клиентам существующая функциональность (existing feature), и почему они ее предпочитают. При намеренном улучшении вы делаете функциональность лучше для существующих пользователей. Например, повышаете быстродействие, делаете функциональность удобнее или улучшаете эстетику.
Используйте преднамеренные улучшения, когда: есть функциональность, которую любят и используют все ваши клиенты, и у вы понимаете как значительно поднять ее ценность.
Стоит отметить, что преднамеренное улучшение (deliberately improving) самых популярных и освоенных в полной мере функций (well-adopted frequently used features) сопряжено с большим риском. Например, представьте себе улучшении текстового редактора платформы для блогов. Сделаете всё правильно, и каждый пользователь оценит улучшение. Но если допустить ошибку, сломаете процессы для всех ваших пользователей. Рискованно, но стоит того.
2. Улучшение частоты использования (frequency improvement)
Делаем так, чтобы функциональность использовали чаще. Например, добавьте новые уведомления в ленту активностей, и её начнут чаще просматривать. Новые опции для поиска — и люди начнуть чаще читать и использовать его для различных задач. Такие улучшения помогают превратить функциональность, которую клиенты используют раз в неделю, в фичу полезную каждый день (every day feature).
Возьмем в качестве примера функцию подтверждения навыков (endorsements) в LinkedIn. Они добавили возможность сделать все в один клик сразу для нескольких навыков. Теперь можно легко (или даже случайно) подтвердить навыки у четырех своих друзей (даже тех навыков, которых у них даже нет). В результате, это создает больше подтверждений, больше заходов в приложение и еще больше действий в один клик. Замкнутый круг.
О принципе, который использовали в LinkedIn писал еще Нир Эяль, автор книги На крючке. Он говорит о том, что привычки формируются в результате повторяющегося цикла, состоящего из четырех ключевых элементов.
Триггер: причина, по которой пользователь заходит в приложение (например, вам пришло письмо о том, что ваш контакт подтвердил ваш навык)
Действие: которое пользователь совершает, чтобы получить награду (скролл, поиск и т.д.)
Награда: которую пользователь получает за своё действие (видит красивую доску в Pinterest)
Инвестиция: действие, которое приведет к большему количеству триггеров (подписка, лайк, установка связи с пользователями и т.д.).
Вот как это выглядит на примере Pinterest:
Увеличивайте частоту использования, когда есть функциональность, которую большинство пользователей применяет редко, но вы верите, что более частое использование им поможет. Также важно оценить пользу для вашего бизнеса от увеличения частоты использования этой функции. Например, если Basecamp увеличит частоту, с которой пользователи создают проекты, они будут в плюсе, потому что на этом построена их бизнес модель. Но есть множество путей увеличить использование функциональности, которое не принесёт никакой выгоды или даже навредит продукту. Например, метрики LinkedIn могли стать лучше, но не стала ли система слишком назойливой?
3. Увеличение доли пользователей, которые освоились с функциональностью и извлекают ценность (product adoption)
Это улучшение нацелено на тех, кто не использует функциональность. Чтобы больше пользователей начали ее использовать, устраните самые важные проблемы, которые им мешают. Здесь особенно помогает техника «Пяти почему». Например ваши пользователи могут не использоваь функциональность отчетов:
- Почему? Они не видят ценности.
- Почему? Они не могут показать их своему начальству.
- Почему? Потому что они не могут получить их в удобном формате.
- Почему? Потому что наше API не дает подходящих данных.
Если раскопать ответы на вопрос «Почему?» несколько раз, то в конечном итоге вы докопаетесь до корня проблемы.
Для исследования вам нужен больше чем один пользователь, в каждом случае причины могут быть разными. Вы будете находить блокирующие паттерны снова и снова. В результате вы сможете добраться и решить ключевые проблемы, которые на самом деле мешают пользоваться функционалом.
Используйте увеличение доли пользователей, которые освоились с функциональностью и извлекают ценность (adoption), когда есть важная функциональность, которую большая часть ваших пользователей не использует, и вы видите очевидные пути, которые помогут им начать это делать.
Когда вы планируете такие улучшения, всегда учитывайте факторы и за пределами программного обеспечения. Иногда дело не в дизайне или функциональности, а в том, как ее преподносят. Часто пользователям нужно понять, зачем вообще использовать отчеты. Лучшее решение в этом случае – улучшение маркетинговых коммуникаций и коммуникаций с клиентами, а не изменение функциональности.
Непрерывные улучшения
На ранних стадиях у стартапов есть огромное преимущество перед существующими компаниями. Они движутся и адаптируются быстрее, у них нет большого технического долга, старой (legacy) функциональности или очень ценных клиентов клиентов, тормозящих движение. Иногда такая скорость и гибкость сносит крышу и приводит к тому, что стартапы бегут во все стороны вместо того, чтобы сосредоточится на улучшении продукта. У продукт менеджера в таком случае две цели:
- найти улучшения, которые помогут бизнесу и пользователям
- убедиться, что эти улучшения увидят свет.
Главное, о чем должны помнить digital-стартапы: «Если не становишься лучше, угасаешь».
Это первая глава | Продолжение (Глава 2) →