Claude
Продакт-менеджмент, часть 1. Сначала проблема, потом решение
Есть старая шутка: инженер, которого попросили сделать лестницу на второй этаж, через месяц приносит лифт. Лифт прекрасный, с подсветкой и голосовым управлением. Только заказчику нужно было один раз в год поднять на второй этаж ёлку, и вполне хватило бы стремянки. Продакт-менеджмент в значительной степени существует для того, чтобы таких лифтов становилось меньше.
Эта серия текстов — короткое введение в профессию для человека, который умеет строить продукты руками, но хочет научиться понимать, какие продукты стоит строить. Попутно вы выучите новый алфавит: сервис, на котором вы это читаете, постепенно подменяет русские буквы чужими. Давайте сразу договоримся использовать его как учебный пример. Он маленький, понятный и вполне настоящий.
Кто такой продакт-менеджер
Продакт-менеджер отвечает за то, чтобы продукт решал реальную проблему реальных людей так, чтобы это было выгодно компании. В этом определении три части, и каждая важна. Реальная проблема — значит, не выдуманная нами за обедом. Реальные люди — значит, мы можем назвать, кто они, и поговорить хотя бы с несколькими. Выгодно компании — значит, решение должно окупаться деньгами, вниманием, удержанием или стратегическим преимуществом.
Обратите внимание, чего в определении нет. Там нет слов «пишет задачи в трекер», «проводит планирование» и «рисует макеты». Всё это продакт иногда делает, но это инструменты, а не суть. Хороший продакт может не открывать трекер неделями и при этом приносить команде огромную пользу. Плохой может идеально вести бэклог и годами двигать продукт в никуда.
Полезно представлять продакта как человека на пересечении трёх кругов: пользователь, бизнес и технологии. Дизайнер глубже понимает пользователя, инженер — технологии, финансист — бизнес. Продакт обычно не лучший ни в одном из трёх, зато он единственный, кто обязан держать в голове все три одновременно и принимать решения, когда интересы расходятся.
Проблема и решение — разные вещи
Самая частая ошибка начинающего продакта и почти любого инженера — влюбиться в решение. Мы видим технологию, придумываем фичу, и нам уже не терпится её построить. Проблема, которую фича якобы решает, подбирается задним числом, как оправдание.
Проверить себя просто. Попробуйте описать проблему, не упоминая своё решение. Если получается только «пользователям не хватает кнопки экспорта в PDF», вы описали решение, переодетое в проблему. Настоящая формулировка звучит иначе: «бухгалтеру раз в месяц нужно отправить отчёт директору, который не пользуется нашей системой, и сейчас он делает скриншоты и вставляет их в письмо». Из такой формулировки вырастает несколько решений: экспорт в PDF, ссылка на отчёт без авторизации, автоматическая рассылка по расписанию. Возможно, лучшее из них вовсе не то, с которого мы начали.
Вернёмся к нашему сервису. Решение — «текст, в котором буквы постепенно заменяются на буквы другого алфавита». А какая проблема? Попробуем сформулировать: «человек хочет научиться читать на новом алфавите, но зубрить таблицу букв скучно, и через пару дней он бросает». Уже лучше. Из этой формулировки видно, что конкурент сервиса — не другой сервис, а скука и потеря мотивации. Видно и то, что важная метрика — дочитал ли человек текст до конца, а не сколько раз он открыл главную страницу.
Работа, которую нанимают сделать
Одна из самых полезных моделей в арсенале продакта называется Jobs To Be Done, или «работа, которую нужно выполнить». Идея простая: люди не покупают продукты, они «нанимают» их, чтобы продвинуться в какой-то ситуации. Знаменитый пример — дрель. Человеку нужна не дрель, а дырка в стене. А если копнуть глубже, то и не дырка, а полка, на которой будут стоять книги, чтобы в комнате было уютно.
Каждый уровень этой цепочки открывает новых конкурентов. На уровне «дрель» вы соревнуетесь с другими дрелями. На уровне «дырка» — с мастером на час. На уровне «полка» — с клейкими крючками, которым дырка не нужна вовсе. На уровне «уют» — с напольным стеллажом из ближайшего мебельного. Продакт, который мыслит только на уровне дрели, однажды обнаружит, что рынок съели крючки, и даже не поймёт почему.
Работу удобно формулировать по шаблону: «Когда я [ситуация], я хочу [мотивация], чтобы [ожидаемый результат]». Например: «Когда я лечу в Тбилиси через месяц, я хочу хотя бы читать вывески и меню, чтобы чувствовать себя в городе не совсем беспомощным». Заметьте, насколько эта формулировка богаче, чем «пользователь хочет выучить грузинский алфавит». Из неё следует срок — месяц. Следует уровень амбиций — читать вывески, а не Руставели в оригинале. Следует эмоциональная составляющая — не чувствовать себя беспомощным. И сразу появляются идеи: тексты про еду и город, режим «за пять минут в день», короткие истории вместо «Вия» на семьдесят тысяч знаков.
Разговоры с пользователями
Как узнать, какую работу на самом деле нанимают делать ваш продукт? Ответ разочаровывающе банален: поговорить с людьми. Разочаровывающе — потому что почти все продакты знают об этом и почти все этого не делают, либо делают так, что разговоры бесполезны.
Главная проблема пользовательских интервью в том, что люди очень вежливы и очень плохо предсказывают собственное поведение. Если вы спросите «вам бы понравилось приложение, которое учит алфавиту через чтение историй?», вы почти наверняка услышите «да, классная идея!». Это ничего не стоит. Человек не хочет вас обидеть, а гипотетическое будущее ему ничем не грозит. Роб Фицпатрик описал это в небольшой книге с выразительным названием: правильные вопросы такие, что на них не сможет соврать даже ваша мама.
Несколько правил, которые делают интервью полезными.
Спрашивайте о прошлом, а не о будущем. Не «стали бы вы», а «когда вы в последний раз пытались выучить новый алфавит? Как это было? Что вы делали?» Прошлое конкретно и не зависит от вежливости.
Говорите о жизни собеседника, а не о своей идее. Пока вы рассказываете про свой продукт, вы ничего не узнаёте. Идеальное интервью — то, в котором вы ни разу не упомянули, что делаете.
Ищите следы усилий. Если человек говорит, что проблема для него важна, спросите, что он уже предпринимал, чтобы её решить. Скачивал приложения? Покупал курс? Вешал на холодильник таблицу с буквами? Если не делал ничего, проблема, скорее всего, не так уж болит, сколько бы он ни уверял в обратном.
Обращайте внимание на деньги и время. Комплименты бесплатны, обязательства — нет. Сильный сигнал — когда человек готов что-то отдать: заплатить, потратить час на тестирование, познакомить вас с коллегой, оставить почту для раннего доступа.
Пять–семь хороших интервью обычно дают больше, чем опрос на тысячу человек. Опросы полезны, когда вы уже знаете, что спрашивать, и хотите измерить масштаб. Интервью нужны, чтобы понять, что вообще стоит измерять.
Гипотезы вместо требований
Классическая разработка начинается с требований: «система должна позволять пользователю делать то-то». Продуктовый подход начинается с гипотез: «мы верим, что если сделаем то-то, то такие-то люди начнут делать вот это, и мы узнаем об этом по таким-то признакам».
Разница кажется формальной, но она меняет всё. Требование нельзя опровергнуть: его можно только выполнить или не выполнить. Гипотезу можно проверить и обнаружить, что она неверна. Так команда получает право ошибаться и, что важнее, обязанность замечать свои ошибки.
Хорошая гипотеза состоит из четырёх частей: изменение, аудитория, ожидаемое поведение и критерий успеха. Например: «Если на странице истории показывать прогресс — сколько букв уже выучено и сколько осталось, — то читатели, открывшие историю с выбранным алфавитом, будут чаще дочитывать её до конца. Мы считаем гипотезу подтверждённой, если доля дочитавших вырастет с тридцати до сорока процентов за две недели».
Обратите внимание: критерий успеха записан до эксперимента. Это важно. Если не договориться заранее, то после запуска любая цифра покажется подтверждением. Выросло на два процента — «тренд положительный». Не выросло — «зато пользователи стали дольше задерживаться на странице». Упало — «это сезонность». Человеческий мозг — непревзойдённая машина по подгонке объяснений под желаемый результат, и единственная защита от неё — записать ожидания до того, как появились данные.
Самая дешёвая проверка
Когда гипотеза сформулирована, возникает соблазн сразу её построить. Но построение — самый дорогой способ проверки. Прежде чем писать код, стоит спросить себя: как узнать ответ в десять раз дешевле?
Существует целая лестница способов проверки, от дешёвых к дорогим. На нижней ступени — разговоры и наблюдение: можно просто посмотреть, как пять человек пользуются продуктом, и половина вопросов отпадёт сама. Чуть выше — «фальшивая дверь»: вы добавляете кнопку новой функции, но за ней ничего нет, только сообщение «скоро будет, оставьте почту». Если на кнопку никто не нажимает, функцию можно не строить. Ещё выше — «волшебник страны Оз»: снаружи продукт выглядит автоматическим, а внутри всё делает человек вручную. Так проверяют спрос на сложные функции, не тратя месяцы на автоматизацию. И только на верхних ступенях — прототип и полноценная реализация.
Наш сервис сам по себе — неплохой пример «волшебника». Вся библиотека историй загружается вручную, никакой автоматической генерации контента, никаких рекомендаций. И это правильно: пока неизвестно, будет ли кто-то регулярно читать, строить сложную систему контента — значит строить лифт ради ёлки.
Почему это сложно
Если всё описанное кажется очевидным, это хороший знак: идеи продакт-менеджмента действительно простые. Сложность в другом — их очень трудно соблюдать под давлением.
Давление приходит отовсюду. Руководитель хочет фичу, которую видел у конкурента. Крупный клиент обещает контракт, если вы сделаете интеграцию лично для него. Команда скучает и хочет переписать всё на новом фреймворке. Вы сами придумали гениальную идею в душе и не можете дождаться, чтобы её реализовать. В каждом из этих случаев правильный первый вопрос один и тот же: какую проблему мы решаем, для кого, и откуда мы знаем, что она существует?
Задавать этот вопрос неприятно. Он замедляет. Он раздражает людей, которые уже всё решили. Иногда ответ на него — «мы не знаем, но всё равно сделаем, потому что так решил директор», и это тоже нормальный ответ, если он честный. Плохо не то, что решения иногда принимаются без данных. Плохо, когда команда не замечает, что принимает их без данных, и потом удивляется результату.
Что попробовать прямо сейчас
Возьмите продукт, над которым вы работаете, или любую функцию, которую делали в последний месяц. Попробуйте ответить на три вопроса. Какую работу нанимает делать эту функцию пользователь? Назовите конкретного человека, который с этой проблемой сталкивался. Как вы узнаете через месяц после запуска, что функция работает?
Если на все три есть уверенные ответы — поздравляю, вы уже мыслите как продакт. Если нет — не страшно, большинство функций в большинстве продуктов не проходят этот тест. Во второй части мы поговорим о том, как измерять, работает ли продукт, и как выбирать, что делать дальше, когда идей много, а людей мало.
Продакт-менеджмент, часть 2. Метрики и приоритеты
В первой части мы договорились, что продукт начинается с проблемы, а не с решения, и что любую идею стоит воспринимать как гипотезу. Теперь два следующих вопроса, с которыми продакт сталкивается каждый день. Как понять, что продукт работает? И как выбрать, что делать дальше, если идей в десять раз больше, чем времени?
Зачем вообще нужны метрики
Метрика — это число, которое помогает принять решение. Если число нельзя использовать для решения, это не метрика, а украшение дашборда. Хороший тест: спросите себя, что вы сделаете иначе, если цифра вырастет вдвое или упадёт вдвое. Если ответ «ничего», можно перестать на неё смотреть.
Самая распространённая ловушка — метрики тщеславия. Это числа, которые всегда растут и приятно выглядят на слайдах: общее количество регистраций за всё время, суммарные просмотры, число скачиваний. Они растут даже у умирающего продукта, потому что накопленная сумма не может уменьшиться. Если у нашего сервиса за год набралось десять тысяч посетителей, это звучит гордо. Но если девять тысяч девятьсот из них открыли одну страницу и ушли навсегда, продукта на самом деле нет.
Противоположность метрикам тщеславия — метрики, которые отражают реальную ценность и могут ухудшиться. Сколько людей вернулось на этой неделе? Какая доля начавших историю дочитала её до конца? Сколько человек прошли весь алфавит хотя бы один раз? Эти цифры неприятно показывать, когда они плохие, и именно поэтому за ними стоит следить.
Путь пользователя: модель пиратских метрик
Удобная рамка для размышлений о метриках — модель AARRR, которую за звучание прозвали пиратской. Она описывает путь пользователя через пять этапов.
Привлечение. Откуда люди узнают о продукте и сколько их приходит. Для нашего сервиса — переходы из поиска, из ссылок в чатах, от друзей.
Активация. Испытал ли человек ценность продукта при первом знакомстве. Здесь важно честно определить, что значит «испытал ценность». Открыть главную страницу — не активация. Выбрать алфавит и прочитать хотя бы один раздел с новыми буквами — пожалуй, да. Этот момент иногда называют «ага-моментом»: человек вдруг понимает, зачем ему продукт.
Удержание. Возвращаются ли люди. Для большинства продуктов это главный этап, потому что без удержания всё остальное бессмысленно. Можно лить сколько угодно трафика в дырявое ведро, и оно всё равно будет пустым.
Доход. Платят ли люди и сколько. Для некоммерческого проекта сюда можно подставить любую форму отдачи — например, присылают ли пользователи свои тексты.
Рекомендации. Приводят ли пользователи других пользователей. Это самый дешёвый и самый честный канал привлечения: люди рекомендуют только то, за что им не стыдно.
Ценность модели не в аббревиатуре, а в том, что она заставляет искать узкое место. Если на каком-то этапе теряется девяносто процентов людей, улучшать соседние этапы почти бесполезно. Нет смысла вкладываться в привлечение, если активация нулевая: вы просто быстрее сожжёте аудиторию.
Удержание и когорты
Об удержании стоит поговорить отдельно, потому что его очень легко посчитать неправильно.
Наивный способ — смотреть на общее количество активных пользователей за неделю. Проблема в том, что эта цифра смешивает старых и новых. Если вы активно привлекаете трафик, число активных может расти, даже когда каждый отдельный пользователь уходит через два дня. Вы видите рост и радуетесь, а на самом деле ведро всё так же протекает, просто вы наливаете быстрее.
Правильный способ — когортный анализ. Пользователей группируют по неделе первого визита и смотрят, какая доля каждой группы возвращается через неделю, две, месяц. Получается таблица, в которой каждая строка — когорта, а каждый столбец — время с момента прихода. Если кривые удержания со временем выходят на плато — например, через месяц стабильно возвращается пятнадцать процентов, — у продукта есть ядро людей, для которых он ценен. Если кривые неуклонно стремятся к нулю, продукт пока никому по-настоящему не нужен, и маркетинг этого не исправит.
Сравнение когорт между собой показывает, становится ли продукт лучше. Если когорта, пришедшая после запуска новой функции, удерживается заметно лучше предыдущих, функция, скорее всего, сработала. Это гораздо надёжнее, чем смотреть на общие цифры до и после.
Северная звезда
Когда метрик становится много, команда начинает тянуть в разные стороны. Маркетинг гонит трафик, дизайнеры улучшают конверсию на одном экране, разработчики ускоряют загрузку. Всё это полезно, но неясно, складывается ли в общий результат.
Для этого придумали метрику Северной звезды — одно число, которое лучше всего отражает ценность, получаемую пользователями, и при этом связано с долгосрочным успехом бизнеса. У сервиса бронирования жилья это может быть количество забронированных ночей. У мессенджера — количество отправленных сообщений. Хорошая Северная звезда растёт, только когда пользователи действительно получают пользу, и её трудно накрутить.
Какой она могла бы быть для нашего сервиса? Количество посетителей не подходит: это привлечение, а не ценность. Время на сайте — спорно: человек может открыть вкладку и уйти пить чай. Кажется, неплохой вариант — количество разделов с новыми буквами, прочитанных за неделю. Каждый такой раздел — это реальный шаг в изучении алфавита. Но и у этой метрики есть недостаток: она не различает, запомнил ли человек буквы или просто пролистал. Идеальных метрик не бывает, бывают достаточно хорошие и честно описанные ограничения.
Как не обмануть себя экспериментом
Самый надёжный способ узнать, работает ли изменение, — эксперимент, или A/B-тест. Пользователей случайно делят на две группы: одна видит старую версию, другая новую. Если между группами возникает разница, её можно приписать изменению, потому что всё остальное в среднем одинаково.
У экспериментов есть подвохи, о которых стоит знать даже без глубокой статистики.
Первый подвох — маленькие выборки. Если в каждой группе по двадцать человек, разница в десять процентов может оказаться чистой случайностью. Как подбрасывание монеты: десять бросков вполне могут дать семь орлов, но это не значит, что монета кривая. Чем меньше ожидаемый эффект, тем больше людей нужно для уверенного вывода.
Второй подвох — подглядывание. Если смотреть на результаты каждый день и остановить тест в момент, когда разница выглядит значимой, вы почти гарантированно найдёте эффект, которого нет. Случайные колебания рано или поздно пересекут любую черту. Срок и размер теста нужно определять заранее и не останавливать его досрочно из-за красивой цифры.
Третий подвох — слишком много метрик. Если сравнить группы по двадцати показателям, один из них почти наверняка покажет «значимую» разницу по чистой случайности. Поэтому главная метрика эксперимента выбирается одна и заранее, а остальные считаются вспомогательными.
Для маленьких продуктов вроде нашего A/B-тесты часто вообще не работают: просто не хватает людей. Это нормально. Тогда опираются на качественные методы — интервью, наблюдение за пользователями, анализ отдельных сессий — и на здравый смысл. Плохой эксперимент хуже, чем его отсутствие, потому что создаёт иллюзию уверенности.
Приоритизация: идей всегда слишком много
Теперь о второй большой задаче. У любого живого продукта список идей растёт быстрее, чем команда успевает их реализовывать. Бэклог в сотни задач — нормальное состояние. Вопрос в том, как выбрать несколько, которые стоит делать сейчас.
Самый популярный инструмент — оценочные модели. Модель RICE предлагает оценить каждую идею по четырём параметрам. Охват: сколько людей затронет изменение за определённый период. Влияние: насколько сильно оно изменит поведение каждого из них, по условной шкале. Уверенность: насколько мы уверены в первых двух оценках, в процентах. Усилия: сколько человеко-недель уйдёт на реализацию. Итоговая оценка — произведение охвата, влияния и уверенности, делённое на усилия.
Например, для нашего сервиса есть три идеи. Первая — показывать прогресс изучения алфавита. Её увидят все читатели, влияние среднее, уверенность умеренная, сделать можно за пару дней. Вторая — мобильное приложение. Охват потенциально больше, влияние неясное, уверенность низкая, а усилия огромные. Третья — озвучка новых букв при наведении. Охват средний, влияние, возможно, высокое для тех, кто учит японский, усилия умеренные. Даже грубый подсчёт сразу показывает, что приложение проигрывает: огромные усилия в знаменателе при низкой уверенности в числителе.
Важно понимать, чем на самом деле полезны такие модели. Они не выдают истину. Цифры в них почти всегда взяты с потолка, и подогнать их под желаемый ответ ничего не стоит. Их ценность в другом: они заставляют проговорить допущения вслух. Когда кто-то ставит влияние «три» новой функции, а коллега ставит «единицу», возникает разговор о том, почему вы по-разному видите пользователя. Этот разговор и есть настоящий результат приоритизации.
Ещё одна полезная модель — модель Кано. Она делит функции на три типа. Базовые — те, отсутствие которых раздражает, а наличие не радует: никто не хвалит сайт за то, что он открывается, но все ругают, если нет. Линейные — чем больше, тем лучше: скорость, количество историй в библиотеке. Восхищающие — те, которых никто не ждёт, но они вызывают восторг: например, если бы сервис вдруг показал, что вы уже можете прочитать настоящую вывеску на грузинском. Хорошая стратегия сначала закрывает базовые потребности, затем держит конкурентный уровень по линейным и добавляет немного восхищения, чтобы о продукте хотелось рассказать.
Фабрика фич
Напоследок — о самом распространённом анти-паттерне в продуктовых командах. Он называется фабрикой фич. Команда измеряет свою работу количеством выпущенных функций. Квартальные цели звучат как «запустить пять новых возможностей». После запуска никто не проверяет, изменилось ли что-нибудь для пользователей: на это нет времени, впереди следующие пять.
Снаружи фабрика фич выглядит продуктивной. Изнутри она выматывает: люди много работают, а продукт почему-то не становится лучше. Признаки легко узнать. Никто не может сказать, какие из прошлогодних функций реально используются. Роадмап — это список фич с датами, а не список проблем, которые нужно решить. Успех празднуют в день релиза, а не в день, когда метрика выросла.
Лекарство — переключиться с результатов работы на последствия работы. Не «запустить прогресс-бар», а «увеличить долю дочитавших историю с тридцати до сорока процентов». Прогресс-бар — одна из гипотез, как этого достичь. Если она не сработает, команда попробует другую, и это будет не провал, а нормальный ход работы.
Что попробовать прямо сейчас
Выберите одну метрику своего продукта, на которую вы регулярно смотрите. Задайте себе вопрос из начала этого текста: что я сделаю иначе, если она вырастет вдвое? А если упадёт вдвое? Если ответа нет — возможно, это метрика тщеславия.
Затем возьмите три верхние задачи из своего бэклога и попробуйте грубо оценить их по RICE. Не ради точных цифр, а чтобы заметить, где ваша уверенность на самом деле ниже, чем казалось. В третьей части мы поговорим о том, как превратить всё это в план, который понимают и команда, и руководство, и как запускать продукты, не теряя связь с реальностью.
Продакт-менеджмент, часть 3. Планы, запуски и люди
В первых двух частях мы разобрались, как найти проблему, которую стоит решать, как измерить, решаем ли мы её, и как выбирать между идеями. Осталась, пожалуй, самая практическая часть профессии: превратить всё это в план, договориться о нём с людьми и довести дело до запуска, не потеряв по дороге связь с реальностью.
Минимально жизнеспособный продукт
Термин «минимально жизнеспособный продукт», или MVP, стал настолько популярным, что почти потерял смысл. Им называют и сырую первую версию, и демо для инвесторов, и просто всё, что сделано наспех. Стоит вернуть ему исходное значение.
MVP — это самый дешёвый способ проверить самое рискованное допущение о продукте. Не первая версия, не урезанный продукт, а именно эксперимент. Ключевое слово здесь — «самое рискованное». Если вы уверены, что люди хотят учить алфавиты через чтение, но сомневаетесь, что они будут возвращаться, ваш MVP должен проверять возвращаемость, а не то, как красиво выглядит страница.
Есть известная иллюстрация. Если вы строите автомобиль, неправильный путь — сначала колесо, потом шасси, потом кузов, и только в конце машина, на которой можно ехать. Пока не готово всё, пользователь не получает ничего. Правильный путь — сначала самокат, потом велосипед, потом мотоцикл и только потом машина. На каждом шаге у пользователя есть что-то, что решает его задачу — переместиться из точки А в точку Б, — хотя и всё лучше и лучше. И на каждом шаге вы узнаёте, действительно ли ему нужно перемещаться, или он предпочёл бы остаться дома.
Langu в своей нынешней форме — классический самокат. Одна страница со списком историй, одна страница чтения, выбор алфавита. Ни аккаунтов, ни прогресса, ни уведомлений. Но базовая работа — «выучить алфавит, не умирая от скуки» — уже выполняется. Если окажется, что выполняется хорошо, можно строить велосипед.
Дискавери и деливери
В зрелых продуктовых командах работу условно делят на два потока. Дискавери — поиск того, что стоит делать: интервью, прототипы, эксперименты, анализ данных. Деливери — надёжная реализация того, что уже признано стоящим: разработка, тестирование, запуск.
Частая ошибка — думать, что эти потоки идут последовательно: сначала всё исследуем, потом всё строим. На практике они идут параллельно и постоянно. Пока инженеры доделывают текущую функцию, продакт и дизайнер уже проверяют гипотезы для следующей. Тогда к моменту, когда команда освобождается, у неё есть не просто идея, а идея с хотя бы минимальным подтверждением.
Другая ошибка — отдать дискавери целиком продакту, а деливери целиком инженерам. Инженеры, которые слышат пользователей напрямую, принимают тысячи мелких решений лучше, потому что понимают контекст. А продакт, который понимает техническую сложность, не будет обещать невозможного. Лучшие команды вовлекают ведущего инженера в дискавери с самого начала: он часто видит решения, которые продакту и дизайнеру просто не приходят в голову, потому что они не знают, что технически возможно.
Роадмап, который не врёт
Роадмап — пожалуй, самый неправильно понимаемый артефакт продуктовой работы. В большинстве компаний это таблица с функциями и датами: в марте делаем это, в апреле то, к лету запускаем вот это. Проблема в том, что такой план почти всегда врёт, и все об этом знают.
Он врёт, потому что предполагает, что мы заранее знаем, какие функции решат проблему. А мы, как обсуждали во второй части, не знаем: большинство идей не работают так, как ожидалось. Он врёт, потому что даты для работы, которую никто ещё не начинал, — это догадки. И он вредит, потому что превращает команду в фабрику фич: успех измеряется тем, запустили ли вовремя, а не тем, помогло ли.
Альтернатива — роадмап, построенный на проблемах и результатах. Вместо «март: прогресс-бар» пишется «сейчас: увеличить долю людей, дочитавших первую историю». Вместо «апрель: озвучка букв» — «следом: помочь тем, кто учит японский, не путать похожие знаки». Вместо конкретных месяцев — три горизонта: сейчас, следом, потом. Чем дальше горизонт, тем меньше в нём деталей и тем больше он похож на направление, а не на обещание.
Такой роадмап сначала раздражает руководство: хочется конкретики и дат. Но он честнее и в итоге полезнее. Он отвечает на вопрос, который на самом деле важен для бизнеса, — какие проблемы мы решаем и почему именно эти, — и оставляет команде свободу искать лучшее решение. Если дата действительно важна — например, есть внешний дедлайн вроде выставки или регуляторного требования, — её, конечно, нужно указать. Но жёсткие даты должны быть исключением, а не правилом.
Одностраничник вместо техзадания
Перед тем как команда начнёт работу над чем-то существенным, полезно написать короткий документ. Не огромное техническое задание на сорок страниц, которое никто не дочитает, а одну страницу, которая отвечает на несколько вопросов.
Какую проблему мы решаем и для кого? Как мы узнали, что она существует? Как поймём, что решили её, — какая метрика и какое целевое значение? Что мы сознательно не делаем в этот раз? Какие у нас главные риски и как мы их проверим?
Пункт «что мы не делаем» стоит выделить особо. Он кажется лишним, но на практике именно он экономит больше всего времени. Каждая функция обрастает желаниями: а давайте ещё вот это, раз уж мы всё равно там. Явный список исключений позволяет вежливо отвечать «да, отличная идея, но не в этот раз — смотри пункт пять».
Хороший одностраничник пишется до начала работы и обсуждается с командой. Самые ценные комментарии к нему обычно звучат как вопросы: «а почему мы уверены, что...» Каждый такой вопрос — сэкономленная неделя, которую иначе потратили бы на реализацию ошибочной идеи.
Люди, которые не подчиняются продакту
Особенность профессии, к которой многие оказываются не готовы: у продакта почти никогда нет формальной власти. Инженеры подчиняются своему руководителю, дизайнеры — своему, продажи — своему. Продакт должен добиться, чтобы все они работали над общей целью, не имея возможности никому ничего приказать.
Единственный рабочий инструмент в такой ситуации — доверие, а доверие строится из нескольких простых вещей. Во-первых, ясность: люди охотнее идут за тем, кто понятно объясняет, зачем мы делаем то, что делаем. Во-вторых, предсказуемость: если вы говорите, что решение будет в пятницу, оно должно быть в пятницу. В-третьих, честность в плохих новостях: продакт, который скрывает проблемы до последнего, теряет доверие быстрее, чем продакт, который сразу говорит «мы ошиблись, вот что мы делаем дальше».
Отдельный навык — говорить «нет». Каждый день к продакту приходят с запросами: от руководства, от продаж, от поддержки, от самих пользователей. Большинство из них разумны, и почти все придётся отклонить или отложить, потому что ресурсы ограничены. Хорошее «нет» звучит не как отказ, а как объяснение приоритетов: «Это важная проблема. Сейчас мы занимаемся вот этим, потому что оно затрагивает в пять раз больше людей. Давай вернёмся к твоему вопросу в следующем квартале, и вот что поможет его поднять выше — данные о том, сколько клиентов с этим сталкиваются».
Запуск — это не финал
В фабрике фич запуск — кульминация: релиз, поздравления, все идут отдыхать. В продуктовом подходе запуск — это середина работы, а иногда и самое её начало. Именно после запуска появляются настоящие данные о том, как люди пользуются функцией.
Несколько практик, которые делают запуски безопаснее и полезнее. Постепенная раскатка: новую функцию сначала видят пять процентов пользователей, потом двадцать, потом все. Если что-то пошло не так, пострадала небольшая часть, и откатиться легко. Переключатели функций: возможность включить или выключить функцию без нового релиза. Мониторинг с первой минуты: метрики успеха и метрики проблем — ошибки, жалобы, падение конверсии — должны быть видны сразу, а не через неделю, когда кто-то соберёт отчёт.
И обязательное возвращение. Через две-четыре недели после запуска стоит собраться и честно посмотреть: подтвердилась ли гипотеза из одностраничника? Если да — что дальше? Если нет — что мы узнали и что попробуем вместо этого? Без этой встречи команда никогда не учится, и каждая следующая ошибка повторяет предыдущую.
Разбор ошибок без поиска виноватых
Когда что-то идёт не так — функция провалилась, запуск сломал оплату, метрика обвалилась, — у организации есть два пути. Можно найти виноватого, наказать и двигаться дальше. Можно разобраться, какие условия сделали ошибку возможной, и изменить эти условия.
Первый путь эмоционально приятнее, но вредит. Люди начинают скрывать проблемы, бояться экспериментов и перестраховываться. Второй путь медленнее, но со временем делает систему надёжнее. Хороший разбор отвечает на вопросы: что произошло, в какой последовательности, почему это показалось разумным людям в тот момент и что мы изменим, чтобы это не повторилось. Обратите внимание на третий вопрос: почти никто не принимает решений, которые в момент принятия кажутся ему глупыми. Понять, почему решение казалось разумным, — значит найти настоящую причину.
Вместо заключения
Если собрать все три части в одну мысль, она будет примерно такой: продакт-менеджмент — это дисциплина честности с самим собой. Честно признать, что мы не знаем, нужна ли людям наша идея. Честно выбрать метрику, которая может показать, что мы неправы. Честно расставить приоритеты, даже если это значит отказать начальству. Честно посмотреть на результат запуска, даже если он разочаровал.
Всё остальное — модели, фреймворки, аббревиатуры — лишь инструменты, которые помогают сохранять эту честность под давлением сроков, амбиций и собственной влюблённости в решения.
А если вы дочитали эту серию до конца в режиме нового алфавита, у вас есть маленькое доказательство одной из гипотез нашего сервиса: учиться можно незаметно, если есть что читать. Подумайте, какую метрику вы бы выбрали, чтобы проверить эту гипотезу на тысяче других людей, — и вы уже думаете как продакт.
Продакт-менеджмент, часть 4. Ценность, деньги и стратегия
Три предыдущие части были о том, как сделать продукт, который нужен людям. Эта — о том, как сделать так, чтобы он мог существовать дальше. Самый полезный продукт в мире закроется, если на нём нельзя заработать или если его за полгода скопирует компания с бюджетом в сто раз больше. Поэтому продакт, даже очень далёкий от финансов, должен понимать базовые вещи о ценности, деньгах и стратегии.
Ценность и цена — не одно и то же
Начнём с различия, которое кажется очевидным, но постоянно теряется на практике. Ценность — это то, что получает пользователь. Цена — это то, что он за это отдаёт. Себестоимость — то, во что продукт обходится компании. Бизнес возможен только тогда, когда ценность для пользователя выше цены, а цена выше себестоимости. Если первое условие нарушено, никто не купит. Если второе — каждая продажа приближает компанию к банкротству.
Самая частая ошибка — назначать цену от себестоимости: посчитали, сколько стоит сервер и зарплаты, добавили наценку, готово. Пользователю совершенно безразлично, во что вам обходится продукт. Он сравнивает цену с ценностью для себя и с альтернативами. Если сервис экономит бухгалтеру десять часов в месяц, его ценность — десять часов бухгалтера, и брать за него стоимость одного часа — значит оставлять на столе огромные деньги. И наоборот: если ваша себестоимость высока, а ценность для пользователя скромная, никакая наценка не поможет — нужно менять либо продукт, либо аудиторию.
Попробуем применить это к нашему сервису. Какую ценность он создаёт? Человек, который через месяц летит в Тбилиси, получает возможность читать вывески и меню. Альтернативы — бесплатные таблицы алфавита, приложения с карточками, частный преподаватель. Таблица бесплатна, но скучна. Преподаватель эффективен, но стоит дорого и требует расписания. Наш сервис где-то посередине: эффективнее таблицы, дешевле и гибче преподавателя. Значит, цена может быть ниже стоимости одного урока, а аргумент для покупки — «выучишь за пару недель, просто читая интересное».
Модели монетизации
Способов брать деньги не так много, и у каждого свои последствия для продукта.
Разовая покупка проста и понятна пользователю, но компании приходится постоянно искать новых покупателей: старые больше не платят. Подписка даёт предсказуемый доход и мотивирует компанию постоянно улучшать продукт — иначе люди отпишутся. Но подписка подходит только для продуктов, которыми пользуются регулярно. Платить ежемесячно за то, что нужно раз в год, никто не захочет, и правильно сделает.
Модель «бесплатно с платными возможностями», которую часто называют фримиумом, позволяет людям попробовать продукт без риска. Главный вопрос в ней — где провести границу. Если бесплатная версия слишком хороша, никто не платит. Если слишком плоха, никто не доходит до момента, когда захочется заплатить. Хорошая граница обычно проходит там, где пользователь уже получил ценность и хочет больше: для нашего сервиса это мог бы быть один алфавит бесплатно, а остальные — по подписке, или бесплатная библиотека и платная загрузка собственных текстов.
Реклама кажется бесплатной для пользователя, но на самом деле меняет продукт глубже всего. Когда доход зависит от рекламы, настоящим клиентом становится рекламодатель, а пользователь превращается в товар. Метрики незаметно смещаются от «помогли ли мы человеку» к «сколько времени он провёл на сайте», и продукт начинает удерживать людей любой ценой, даже если им это вредит. Это не значит, что реклама — зло, но это значит, что выбор модели монетизации — продуктовое решение, а не только финансовое.
Юнит-экономика
Чтобы понять, может ли продукт зарабатывать, полезно посчитать экономику одного пользователя. Две главные величины — стоимость привлечения клиента и пожизненная ценность клиента.
Стоимость привлечения — сколько денег уходит на то, чтобы получить одного платящего пользователя: реклама, маркетинг, работа продаж, бесплатные пробные периоды. Пожизненная ценность — сколько денег клиент принесёт за всё время, пока пользуется продуктом. Если человек платит триста рублей в месяц и в среднем остаётся на десять месяцев, его пожизненная ценность — три тысячи, за вычетом себестоимости обслуживания.
Правило простое: пожизненная ценность должна быть заметно больше стоимости привлечения. Часто называют соотношение три к одному как ориентир здорового бизнеса. Если привлечение стоит дороже, чем клиент приносит, рост только ускоряет убытки: чем больше клиентов, тем больше потерь.
Обратите внимание, как эта формула связывает финансы с тем, о чём мы говорили раньше. Пожизненная ценность напрямую зависит от удержания: если люди уходят через месяц вместо десяти, ценность падает в десять раз. А стоимость привлечения сильно зависит от рекомендаций: клиент, пришедший по совету друга, почти ничего не стоит. Поэтому продуктовая работа над удержанием и рекомендациями — это не что-то отдельное от бизнеса, а самый прямой рычаг его экономики.
Позиционирование
Позиционирование отвечает на вопрос: почему именно этот продукт, а не альтернатива? Это не слоган и не реклама, а осознанный выбор того, для кого продукт, с чем его сравнивают и чем он лучше.
Удобный шаблон звучит так: «Для [кого], которые [имеют проблему], наш продукт — это [категория], который [ключевая польза]. В отличие от [альтернативы], мы [главное отличие]». Например: «Для людей, которые скоро поедут в страну с незнакомым алфавитом, Langu — это читалка, которая учит буквам незаметно, пока вы читаете интересную историю. В отличие от карточек и таблиц, здесь не нужно ничего зубрить».
Хорошее позиционирование всегда что-то отсекает. Оно говорит не только «для кого мы», но и «для кого мы не». Наш сервис явно не для тех, кто хочет выучить язык целиком: он учит только алфавиту, и честно об этом говорить — значит не разочаровывать людей с неправильными ожиданиями. Страх сузить аудиторию — одна из главных причин размытого позиционирования. Но продукт, который «для всех», на практике не нужен никому конкретно.
Защита от копирования
Последний вопрос стратегии: что помешает другим сделать то же самое? В мире софта скопировать функциональность почти всегда легко. Наш сервис хороший программист повторит за выходные. Поэтому устойчивое преимущество редко держится на функциях. Его называют рвом вокруг замка, и рвы бывают нескольких типов.
Сетевой эффект: продукт становится ценнее с каждым новым пользователем. Мессенджер, в котором нет ваших друзей, бесполезен, сколько бы функций в нём ни было. Данные: продукт, который учится на поведении пользователей, со временем становится лучше копий, у которых этих данных нет. Стоимость переключения: если человек годами хранит в продукте свои материалы, уйти к конкуренту дорого и неудобно. Бренд и доверие: люди выбирают знакомое, даже если альтернатива чуть лучше. Масштаб: большая компания может предлагать цену, на которой маленькая разорится.
У маленького продукта на старте рва обычно нет, и это нормально. Важно понимать, какой ров вы собираетесь копать. Для нашего сервиса можно представить несколько вариантов. Библиотека хороших текстов, подобранных под изучение алфавитов, — это и контент, и бренд. Данные о том, в каком порядке лучше вводить буквы, чтобы люди запоминали быстрее, — это знание, которого нет у копий. Сообщество людей, которые делятся своими текстами, — это сетевой эффект в миниатюре.
Стратегия как набор отказов
Слово «стратегия» часто используют для красивых документов с размытыми целями: «стать лидером рынка», «обеспечить лучший пользовательский опыт». Это не стратегия, а пожелания. Настоящая стратегия — это набор согласованных решений о том, что мы делаем и, главное, чего не делаем, чтобы добиться конкретного преимущества.
Хороший тест стратегии — может ли разумный конкурент выбрать противоположное. «Мы делаем качественный продукт» — противоположность абсурдна, никто не стремится к некачественному. А «мы учим только алфавиту, не грамматике и не словам, и делаем это через чтение длинных историй, а не через короткие упражнения» — это стратегия: можно представить успешный продукт, который выбрал прямо противоположное, и это сразу показывает, от чего мы отказались.
Каждое такое решение отсекает возможности. Мы не будем делать геймификацию с очками и рейтингами, потому что наша ставка — на интерес к самой истории. Мы не будем делать короткие упражнения на пять минут, потому что наш механизм работает только на длинном тексте. Эти отказы болезненны, но именно они делают продукт цельным. Продукт, который пытается быть всем, становится набором случайных функций, не связанных общей идеей.
Итоги всей серии
За четыре части мы прошли путь от проблемы до стратегии. Сначала понять, какую работу люди нанимают выполнить, и не влюбляться в своё решение. Затем выбрать честные метрики, которые могут показать, что мы неправы, и расставлять приоритеты, проговаривая допущения вслух. Потом строить маленькими шагами, планировать от проблем, а не от функций, и учиться на каждом запуске. И наконец, убедиться, что созданная ценность превращается в устойчивый бизнес, а продукт защищён чем-то большим, чем набор функций.
Ни один из этих шагов не требует особого таланта. Все они требуют дисциплины: задавать неудобные вопросы, особенно самому себе, и не прекращать их задавать, когда продукт начинает расти. Удачи — и с продуктами, и с новыми алфавитами.