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