Pre-mortem: как найти причины провала фичи и не допустить того, чтобы она провалилась После неудачного запуска фичи причины часто кажутся очевидными: пользователям неудобно, сценарий не продумали, поддержка не выдержала потока обращений. На ретро обязательно кто-нибудь скажет: «Я еще в начале об этом думал». Полезно дать этим мыслям место, пока в фиче или продукте можно что-то изменить. Для этого есть pre-mortem — инструмент Гэри Кляйна. Команда представляет, что проект уже провалился, и объясняет, почему это произошло. Допустим, сервис доставки продуктов готовит новую фичу: автоматический заказ привычной корзины каждую неделю. Рассчитываем, что покупателям станет удобнее не совершать одни и те же действия регулярно, а мы увидим рост повторных заказов. До релиза собираем команду и предлагаем представить: «Прошло полгода. Фичу почти никто не использует, поддержка получает жалобы, мы готовимся ее закрыть. Почему так вышло?» Сначала каждый самостоятельно записывает причины у себя в заметках. Затем участники по очереди делятся ими, и команда выбирает самые существенные риски. В нашем воображаемом запуске список мог бы получиться таким: — Люди не успевали съедать имеющиеся продукты, а следующая корзина уже приезжала. — Цена корзины менялась от недели к неделе, и сумма списания становилась сюрпризом. — Любимых товаров не было в наличии, а замены не подходили. — Пропустить доставку на одну неделю было сложно, поэтому пользователи отключали функцию целиком. Теперь с этим можно работать: добавить напоминание, согласование суммы и замен, сделать простой пропуск недели по запросу. Для каждого риска — определить действие и ответственного. Но даже если мы закроем все эти риски, это еще не докажет, что фичу стоит запускать. Pre-mortem помогает ответить на вопрос «почему мы можем провалиться?». А нам нужен еще один ответ: «на чем основана уверенность, что это решение принесет пользу?» Возможно, человеку нужна помощь с регулярной закупкой, но состав корзины он хочет каждый раз выбирать сам. Тогда удобный автозаказ с прозрачной ценой все равно не решит его задачу. Поэтому к списку рисков стоит добавить проверки: как люди сейчас повторяют покупки, что меняют в корзине, готовы ли доверить сервису следующий заказ. А затем — небольшой пилот с заранее выбранными критериями успеха. Разобрать возможный провал до релиза полезно. Ещё полезнее заранее договориться, какие факты дадут нам основания продолжать. 🤩О том, как проверять решения заранее, поговорим 2 ноября на нашем вебинаре. Подробнее о вебинаре — тут. Шаблон pre-mortem (на английском) можно найти по ссылке. @productmindset

Вебинар: Вы приняли продуктовое решение. Как понять, что оно — правильное? Для начинающих менеджеров продуктов и тех, кто уже запускает фичи, но хочет быть уверенным в том, как он подходит к их проработке. Вы приняли продуктовое решение и запустили его. Казалось бы, дальше остается ждать роста метрик. Но если заранее не определить все критерии принятия решения и того, что считать успехом, любой исход можно интерпретировать постфактум как захочется, а не отталкиваясь от реальной ситуации. На вебинаре пройдем путь решения по шагам: от цели до выбора метрик, а также рассмотрим реальный продуктовый кейс. 🗓 Дата и время: 2 ноября (пн) в 19:00 МСК ⏰ Длительность: 1 час Что будет на вебинаре 1️⃣Теория: — Поговорим, зачем нужно продуктовое мышление. — Рассмотрим пять шагов проверки решения (от целей к способам проверки и метрикам результата). — Соберем шаги в удобный инструмент для принятия решений. 2️⃣Практика: — Разберем реальный кейс в прямом эфире. — Покажем, как опытные менеджеры продуктов применяют решения на практике. — Ответим на вопросы. Спикеры — Иван Меркурьев, Senior Product Manager, Яндекс. Автор телеграм-канала Ordinary PM — Анастасия Бабинцева, Product Manager, LifetimeHealth. Редактор канала Product Mindset Почему стоит прийти ✅ Узнаете понятный порядок действий подготовки любой фичи к реализации. ✅ Поймете подход, который можно применить к своему продукту уже сейчас. ✅ Зададите вопросы спикерам в прямом эфире 🎁 Бонус: табличка принятия решений и карта навыков менеджера продукта для оценки ваших навыков. Формат: онлайн в Академии ProductSense Участие: бесплатно 👉 Зарегистрироваться

Вы единственный продакт в стартапе. К вам приходят с вопросами — а к кому идти с вопросами вам? «Я пришла в стартап менеджером продукта и сначала обрадовалась: мои задачи будут глобальными и будут влиять на весь продукт, я смогу сделать очень многое. Скорее всего, я не буду перекрашивать кнопку или отвечать за рост метрики на десятые доли процента, это будет что-то более сложное и ответственное. А потом вместе с ответственностью приходит вот что: разбираться нужно сразу во всем, а посоветоваться не с кем. Ты и есть тот человек, к которому приходят с вопросами. А куда с вопросами идти тебе?» — Настя, менеджер продукта в стартапе Кажется, что главная трудность роли единственного менеджера продуктов в компании — не у кого учиться. На самом деле с источниками знаний проблем нет: профессиональные сообщества, конференции, менторские программы и просто общение с друзьями — все это помогает находить информацию. Не хватает другого — обратной связи конкретно на вашу работу. Статья объяснит, как устроена приоритизация, но никто не скажет, что ваш бэклог на квартал собран вокруг одного клиента, который громче всех доказывает важность фичи именно для него. В большой команде это заметит лид на ревью. В стартапе — только вы сами и возможно остальные недовольные клиенты, но это уже совсем другая история. Ментор может помочь, но и у него есть пределы. А часть особенностей этой роли вообще не про обучение — их полезно знать заранее. Ментор не заменит CTO По техническим вопросам никто не поможет вам так, как собственный технический директор: он знает архитектуру продукта и ограничения команды. Чем лучше вы понимаете друг друга, тем быстрее растете вы оба и ваш продукт. Свой рынок вы будете знать лучше ментора Ментор поможет проверить логику решения, но не скажет, чего хотят ваши клиенты. Здесь главный учитель — пользователи. В стартапе вы к ним ближе всего, и этим стоит пользоваться. Систему придется строить самим На ранних стадиях процессы в стартапах часто еще не выстроены или выстроены на скорую руку, «чтобы просто работало». Выстраивать их будете вы, и ошибок будет много. Где-то рост пойдет медленнее, чем в большой компании, зато опыт в этом деле вы получите колоссальный. Начните с одного процесса — как вы приоритизируете задачи, — и формализуйте его. Дальше действуйте в рамках правил, которые вы согласовали. Договориться о границах с основателем стоит на берегу В стартапе продуктовые решения часто принимает основатель. Обсудите на старте, какие решения приносите вы, а какие готовы брать с его стороны. Иначе вы будете отвечать за результат, которым не управляете. Как создать себе обратную связь: — Найдите одного-двух менеджеров продуктов из других компаний и раз в месяц разбирайте решения друг друга. — Записывайте ключевые решения и ожидаемый результат, чтобы потом было с чем сверяться (о таком журнале принятия решений мы уже рассказывали ранее). — Если оценить ваш уровень пока некому, сверяйтесь с картой компетенций. ИИ тоже может помочь, если просить его найти слабые места и аргументы за/против решения, а не оценить, хорошее ли оно. Так к кому идти с вопросами? Не к одному человеку, а к нескольким: с техническими — к CTO, с вопросами о рынке — к пользователям, с решениями — к коллегам-продактам, а с границами и системой — накапливать опыт, который будете получать на реальных задачах. Лида, который видит все и сразу, в стартапе часто нет. Поэтому такой круг обратной связи вам придется собрать самостоятельно. Но это точно окупится и даст кратный рост в профессии. @productmindset