Обзор книги Intercom on Product Management. Ч. 1.

Недавно компания «Интерком» (о которой я ничего не знаю) опубликовала электронную книгу про управление продуктами. Как пишут авторы в предисловии, это сборник топовых статей из их блога. Книжка небольшая, на час-два, поэтому в подробном обзоре мало смысла — проще прочитать:

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

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

Расскажу о том, что запомнилось и показалось интересным лично мне.

Продуктовое решение ≠ родмапное решение

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

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

Make product usage growth, not product growth

Оставил английскую формулировку, потому что по-русски звучит коряво. Изящно сформулированная идея о том, что заниматься надо не ростом продукта в смысле постоянного наращивания функционала, а улучшать его использование (видите, как коряво).

Когда вы выкатили новую функцию и увидели, что люди используют ее лишь частично (относительно замысла), у вас есть 4 варианта действий:

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

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

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

Сначала скажите «нет»: продуктовый подход

Не один старик Кэмп учит любить это заветное слово. Авторы книжки считают, что «нет» должно стать любимым словом и у продакта. Вот почему.

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

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

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

Бесплатных решений не бывает

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

Простое правило, которое следует запомнить: бесплатных решений не бывает. «Ну это же совсем мелкое изменение, оно нам ничего не стоит». Это вранье. Даже если кажется, что технически добавить функцию ничего не стоит, всегда нужно задать себе ряд вопросов, чтобы понять ее настоящую ценность. Авторы приводят в пример предложение «давайте уменьшим количество символов в отзыве до 140, потому что на следующих этапах мы планируем отправлять их как СМС». Вопросы:

  • Что произойдет, когда символов станет больше 140? Мы не даем печатать дальше или выводим ошибку? Если выводим ошибку, то в каком виде и где? Что там будет написано? Как мы объясним старым пользователям, почему ограничили ввод? Есть ли у нас стили для окна ошибки? Если нет, кто их нарисует? Обрабатывать ошибки на сервере глупо, значит надо делать это на клиенте. Кто напишет джава-скрипт? Клиент выводит тот же тип ошибки, что сервер или нет? Если нет, что мы будем делать? И так далее.

About: neadmin


Leave a Reply

Your email address will not be published. Required fields are marked *

Skip to toolbar