Пре-мортем фичи
Приём Lenny Rachitsky
Это адаптация чужой практики: разбираем методологию автора, переписываем под наш формат и показываем, как применить, на примере ниже. Первоисточник →
В бенчмарке моделей зону «Команда» сейчас лучше всех решают: 1. GPT 5.6 Sol — 9,6 · 2. Claude Fable 5 — 9,4 · 3. GPT 5.6 Luna — 9,4
Ты — продуктовый менеджер, который проверяет идеи на прочность до того, как команда потратит на них квартал. Проведи пре-мортем фичи.
Входные данные: — продукт: [вставьте описание продукта, пользователей и бизнес-модели]; — фича: [вставьте описание фичи: что делает, для кого, какую проблему решает, какие ожидания от эффекта]; — ограничения: [вставьте сроки, ресурсы и то, что уже решено и не обсуждается].
Задача:
- Пре-мортем: представь, что прошёл год после запуска и фича признана провалом. Назови топ-5 причин провала и распредели их по категориям: продукт (не решает проблему), техника (не работает как надо), поведение пользователей (люди используют не так, как планировалось), бизнес (вред деньгам или стратегии). Несколько причин могут быть в одной категории, категория может остаться пустой.
- Для каждой причины укажи: ранний сигнал — что и где команда увидит в первые недели, если причина сбывается; профилактическое действие — что сделать до или сразу после запуска.
- Непредвиденные последствия: ровно 5 эффектов второго порядка — что изменится вокруг фичи для пользователей, поддержки, команды и бизнеса, хотя в планах этого нет.
- Аргумент против: сформулируй самое сильное обоснование, почему нам НЕ стоит делать эту фичу, — так, как сформулировал бы грамотный несогласный. Заверши одним абзацем: что должно оказаться правдой, чтобы этот аргумент не сработал.
Ограничения: — каждую причину строй из описанных фичи и продукта, а не из общего списка рисков; причина без привязки к контексту не засчитывается; — не смягчай: если фича может навредить метрикам, деньгам или доверию пользователей, напиши об этом прямо; — не делай вывод об отмене фичи: твоя работа — показать риски, решение остаётся за командой; — если данных не хватает (нет метрик успеха, непонятна техническая база), отметь это и укажи, какой риск из-за этого не оценён.
Пример данных
Данные вымышлены. Замени их информацией о своей задаче.
Продукт: «ОтзывПро» — b2b-сервис обратной связи для отелей: QR-коды в номерах и ссылки после выезда ведут на короткую форму оценки пребывания, ответы стекаются в дашборд, при низкой оценке менеджер отеля получает алерт. Клиенты — отели 3–5 звёзд, подключено 180 отелей. Фича: черновики ответов на публичные отзывы с помощью ИИ. Сервис подтягивает отзывы гостя с площадок и генерирует черновик ответа от лица отеля; менеджер отеля правит и публикует через API партнёра. Ожидание: среднее время ответа на публичный отзыв сократится с 26 часов до 8, менеджер будет экономить до 5 часов в неделю. Ограничения: релиз через 6 недель; команда 5 человек; лимиты и стабильность API партнёра для публикации не выяснены.
Пример ответа
Один из возможных результатов. Проверь факты и адаптируй текст перед использованием.
Пре-мортем: год спустя фича провалилась
| № | Причина провала | Категория | Ранний сигнал в первые недели | Профилактика |
|---|---|---|---|---|
| 1 | Черновики однотипные: «Благодарим за отзыв!», — менеджеру быстрее написать с нуля, чем править | Продукт | Медианное число правок менеджера на черновик не падает; доля черновиков, удалённых без публикации, растёт | До релиза прогнать генерацию на 200 исторических отзывов из сервиса и проверить, насколько черновики различаются между собой |
| 2 | Публикация через API партнёра падает на пиковых объёмах: черновики копятся, время ответа не сокращается | Техника | Доля черновиков, не опубликованных из-за ошибок API, заметна уже в первую неделю | Выяснить лимиты и статус API партнёра до релиза; заложить очередь публикаций и повторные попытки |
| 3 | Менеджеры публикуют черновики без правок, гости узнают шаблонные ответы, отелям прилетают упрёки | Поведение пользователей | Доля опубликованных без единой правки черновиков растёт от недели к неделе | Подсказывать менеджеру, что дописать лично: имя гостя и конкретная деталь из его отзыва |
| 4 | Площадки отзывов распознают массовые однотипные ответы и понижают отели в выдаче или блокируют аккаунты — отели винят «ОтзывПро» | Бизнес | Первые жалобы отелей на предупреждения от площадок | Правило уникализации: ограничить повторяющиеся формулировки в черновиках одного отеля |
| 5 | Ожидаемой экономии нет: менеджеры пробуют фичу и отключают, до продления подписки дело не доходит | Бизнес | Через 4 недели после релиза фичей регулярно пользуется меньше половины менеджеров подключённых отелей | Считать удержание фичи отдельной метрикой и опрашивать отключившихся, что не сработало |
Пять непредвиденных последствий
- Менеджеры перестают дочитывать отзывы до конца: содержание проблем гостя перестаёт попадать в дашборд и алерты — проседает основная ценность сервиса.
- На негатив генерируются вежливые извинения вместо разбора: алерты по низкой оценке теряют смысл, потому что причина недовольства так и не вскрывается.
- Черновик от лица отеля обещает то, чего отель не предлагал: скидку или компенсацию, — фактическая ошибка публикуется от имени клиента.
- Поддержка «ОтзывПро» получает волну вопросов «почему ответ написан не тем тоном»: нагрузка смещается в поддержку.
- Команда откладывает доработки дашборда и алертов ради доводки генерации: базовая ценность для остальных отелей замирает на время фичи.
Почему нам НЕ стоит это делать
Самый сильный аргумент против: отели покупают «ОтзывПро» ради раннего сигнала о недовольном госте, а фича смещает фокус на публичную витрину. Если черновики ускорят публикацию ответа, но гость с проблемой не получит разбора, ни повторных броней, ни удержания подписки это не даст: 26 часов превратятся в 8, а причина недовольства останется. Сюда же репутационный риск шаблонности: сервис, обещающий качество работы с гостями, не должен учить отели отвечать штампами.
Аргумент не сработает, если окажется правдой: менеджеры и так пишут содержательные ответы, а узкое место — именно набор текста, а не понимание проблемы гостя; и гости реально читают ответы перед выбором отеля. Тогда скорость напрямую конвертируется в ценность. Оба условия из входных данных не следуют — их стоит проверить до релиза.
Проверьте факты
- Ожидания из брифа (26 часов до 8, экономия 5 часов в неделю) отражены дословно; сами цифры не проверялись.
- Пороги ранних сигналов (первая неделя, 4 недели, «меньше половины») — предлагаемые настройки мониторинга, во входных данных их нет.
- Категория «бизнес» получила две причины, «продукт» и «техника» — по одной, «поведение пользователей» — одну: промпт это допускает.
- Лимиты API партнёра во входных данных не выяснены — поэтому техническая причина 2 помечена как самая проверяемая до релиза.
Из главы: Работа с командой и стейкхолдерами