Claude
В первых двух частях мы разобрались, как найти проблему, которую стоит решать, как измерить, решаем ли мы её, и как выбирать между идеями. Осталась, пожалуй, самая практическая часть профессии: превратить всё это в план, договориться о нём с людьми и довести дело до запуска, не потеряв по дороге связь с реальностью.
Минимально жизнеспособный продукт
Термин «минимально жизнеспособный продукт», или MVP, стал настолько популярным, что почти потерял смысл. Им называют и сырую первую версию, и демо для инвесторов, и просто всё, что сделано наспех. Стоит вернуть ему исходное значение.
MVP — это самый дешёвый способ проверить самое рискованное допущение о продукте. Не первая версия, не урезанный продукт, а именно эксперимент. Ключевое слово здесь — «самое рискованное». Если вы уверены, что люди хотят учить алфавиты через чтение, но сомневаетесь, что они будут возвращаться, ваш MVP должен проверять возвращаемость, а не то, как красиво выглядит страница.
Есть известная иллюстрация. Если вы строите автомобиль, неправильный путь — сначала колесо, потом шасси, потом кузов, и только в конце машина, на которой можно ехать. Пока не готово всё, пользователь не получает ничего. Правильный путь — сначала самокат, потом велосипед, потом мотоцикл и только потом машина. На каждом шаге у пользователя есть что-то, что решает его задачу — переместиться из точки А в точку Б, — хотя и всё лучше и лучше. И на каждом шаге вы узнаёте, действительно ли ему нужно перемещаться, или он предпочёл бы остаться дома.
Langu в своей нынешней форме — классический самокат. Одна страница со списком историй, одна страница чтения, выбор алфавита. Ни аккаунтов, ни прогресса, ни уведомлений. Но базовая работа — «выучить алфавит, не умирая от скуки» — уже выполняется. Если окажется, что выполняется хорошо, можно строить велосипед.
Дискавери и деливери
В зрелых продуктовых командах работу условно делят на два потока. Дискавери — поиск того, что стоит делать: интервью, прототипы, эксперименты, анализ данных. Деливери — надёжная реализация того, что уже признано стоящим: разработка, тестирование, запуск.
Частая ошибка — думать, что эти потоки идут последовательно: сначала всё исследуем, потом всё строим. На практике они идут параллельно и постоянно. Пока инженеры доделывают текущую функцию, продакт и дизайнер уже проверяют гипотезы для следующей. Тогда к моменту, когда команда освобождается, у неё есть не просто идея, а идея с хотя бы минимальным подтверждением.
Другая ошибка — отдать дискавери целиком продакту, а деливери целиком инженерам. Инженеры, которые слышат пользователей напрямую, принимают тысячи мелких решений лучше, потому что понимают контекст. А продакт, который понимает техническую сложность, не будет обещать невозможного. Лучшие команды вовлекают ведущего инженера в дискавери с самого начала: он часто видит решения, которые продакту и дизайнеру просто не приходят в голову, потому что они не знают, что технически возможно.
Роадмап, который не врёт
Роадмап — пожалуй, самый неправильно понимаемый артефакт продуктовой работы. В большинстве компаний это таблица с функциями и датами: в марте делаем это, в апреле то, к лету запускаем вот это. Проблема в том, что такой план почти всегда врёт, и все об этом знают.
Он врёт, потому что предполагает, что мы заранее знаем, какие функции решат проблему. А мы, как обсуждали во второй части, не знаем: большинство идей не работают так, как ожидалось. Он врёт, потому что даты для работы, которую никто ещё не начинал, — это догадки. И он вредит, потому что превращает команду в фабрику фич: успех измеряется тем, запустили ли вовремя, а не тем, помогло ли.
Альтернатива — роадмап, построенный на проблемах и результатах. Вместо «март: прогресс-бар» пишется «сейчас: увеличить долю людей, дочитавших первую историю». Вместо «апрель: озвучка букв» — «следом: помочь тем, кто учит японский, не путать похожие знаки». Вместо конкретных месяцев — три горизонта: сейчас, следом, потом. Чем дальше горизонт, тем меньше в нём деталей и тем больше он похож на направление, а не на обещание.
Такой роадмап сначала раздражает руководство: хочется конкретики и дат. Но он честнее и в итоге полезнее. Он отвечает на вопрос, который на самом деле важен для бизнеса, — какие проблемы мы решаем и почему именно эти, — и оставляет команде свободу искать лучшее решение. Если дата действительно важна — например, есть внешний дедлайн вроде выставки или регуляторного требования, — её, конечно, нужно указать. Но жёсткие даты должны быть исключением, а не правилом.
Одностраничник вместо техзадания
Перед тем как команда начнёт работу над чем-то существенным, полезно написать короткий документ. Не огромное техническое задание на сорок страниц, которое никто не дочитает, а одну страницу, которая отвечает на несколько вопросов.
Какую проблему мы решаем и для кого? Как мы узнали, что она существует? Как поймём, что решили её, — какая метрика и какое целевое значение? Что мы сознательно не делаем в этот раз? Какие у нас главные риски и как мы их проверим?
Пункт «что мы не делаем» стоит выделить особо. Он кажется лишним, но на практике именно он экономит больше всего времени. Каждая функция обрастает желаниями: а давайте ещё вот это, раз уж мы всё равно там. Явный список исключений позволяет вежливо отвечать «да, отличная идея, но не в этот раз — смотри пункт пять».
Хороший одностраничник пишется до начала работы и обсуждается с командой. Самые ценные комментарии к нему обычно звучат как вопросы: «а почему мы уверены, что...» Каждый такой вопрос — сэкономленная неделя, которую иначе потратили бы на реализацию ошибочной идеи.
Люди, которые не подчиняются продакту
Особенность профессии, к которой многие оказываются не готовы: у продакта почти никогда нет формальной власти. Инженеры подчиняются своему руководителю, дизайнеры — своему, продажи — своему. Продакт должен добиться, чтобы все они работали над общей целью, не имея возможности никому ничего приказать.
Единственный рабочий инструмент в такой ситуации — доверие, а доверие строится из нескольких простых вещей. Во-первых, ясность: люди охотнее идут за тем, кто понятно объясняет, зачем мы делаем то, что делаем. Во-вторых, предсказуемость: если вы говорите, что решение будет в пятницу, оно должно быть в пятницу. В-третьих, честность в плохих новостях: продакт, который скрывает проблемы до последнего, теряет доверие быстрее, чем продакт, который сразу говорит «мы ошиблись, вот что мы делаем дальше».
Отдельный навык — говорить «нет». Каждый день к продакту приходят с запросами: от руководства, от продаж, от поддержки, от самих пользователей. Большинство из них разумны, и почти все придётся отклонить или отложить, потому что ресурсы ограничены. Хорошее «нет» звучит не как отказ, а как объяснение приоритетов: «Это важная проблема. Сейчас мы занимаемся вот этим, потому что оно затрагивает в пять раз больше людей. Давай вернёмся к твоему вопросу в следующем квартале, и вот что поможет его поднять выше — данные о том, сколько клиентов с этим сталкиваются».
Запуск — это не финал
В фабрике фич запуск — кульминация: релиз, поздравления, все идут отдыхать. В продуктовом подходе запуск — это середина работы, а иногда и самое её начало. Именно после запуска появляются настоящие данные о том, как люди пользуются функцией.
Несколько практик, которые делают запуски безопаснее и полезнее. Постепенная раскатка: новую функцию сначала видят пять процентов пользователей, потом двадцать, потом все. Если что-то пошло не так, пострадала небольшая часть, и откатиться легко. Переключатели функций: возможность включить или выключить функцию без нового релиза. Мониторинг с первой минуты: метрики успеха и метрики проблем — ошибки, жалобы, падение конверсии — должны быть видны сразу, а не через неделю, когда кто-то соберёт отчёт.
И обязательное возвращение. Через две-четыре недели после запуска стоит собраться и честно посмотреть: подтвердилась ли гипотеза из одностраничника? Если да — что дальше? Если нет — что мы узнали и что попробуем вместо этого? Без этой встречи команда никогда не учится, и каждая следующая ошибка повторяет предыдущую.
Разбор ошибок без поиска виноватых
Когда что-то идёт не так — функция провалилась, запуск сломал оплату, метрика обвалилась, — у организации есть два пути. Можно найти виноватого, наказать и двигаться дальше. Можно разобраться, какие условия сделали ошибку возможной, и изменить эти условия.
Первый путь эмоционально приятнее, но вредит. Люди начинают скрывать проблемы, бояться экспериментов и перестраховываться. Второй путь медленнее, но со временем делает систему надёжнее. Хороший разбор отвечает на вопросы: что произошло, в какой последовательности, почему это показалось разумным людям в тот момент и что мы изменим, чтобы это не повторилось. Обратите внимание на третий вопрос: почти никто не принимает решений, которые в момент принятия кажутся ему глупыми. Понять, почему решение казалось разумным, — значит найти настоящую причину.
Вместо заключения
Если собрать все три части в одну мысль, она будет примерно такой: продакт-менеджмент — это дисциплина честности с самим собой. Честно признать, что мы не знаем, нужна ли людям наша идея. Честно выбрать метрику, которая может показать, что мы неправы. Честно расставить приоритеты, даже если это значит отказать начальству. Честно посмотреть на результат запуска, даже если он разочаровал.
Всё остальное — модели, фреймворки, аббревиатуры — лишь инструменты, которые помогают сохранять эту честность под давлением сроков, амбиций и собственной влюблённости в решения.
А если вы дочитали эту серию до конца в режиме нового алфавита, у вас есть маленькое доказательство одной из гипотез нашего сервиса: учиться можно незаметно, если есть что читать. Подумайте, какую метрику вы бы выбрали, чтобы проверить эту гипотезу на тысяче других людей, — и вы уже думаете как продакт.