Анализ конкурирующих гипотез (ACH): как найти причину падения метрики
Анализ конкурирующих гипотез (ACH) Хойера для продукта: матрица гипотез и фактов, диагностичность, 8 шагов и что спросить у команды, когда упала метрика.
Исследования
Как проверять гипотезы и принимать решения при неопределённости: интервью, эксперименты, методы анализа.
Карта допущений (assumption mapping): что проверять до разработки
Карта допущений по Дэвиду Бланду: как за час найти убеждения, от которых зависит продукт, и оплатить их проверку раньше, чем разработку фичи.
Атомарные исследования: как перестать платить за ресёрч дважды
Атомарные исследования (atomic research) — база фактов вместо отчётов: шаблоны факта, инсайта и решения, уровни доказательности, трассируемость и формат для RAG.
Mom Test: интервью с клиентами, которым можно верить
Mom Test для руководителя: как отличить обязательство клиента от комплимента, какие custdev-вопросы задавать и как проверить отчёт команды об интервью.
Opportunity Solution Tree (дерево возможностей): от фич к результату
Opportunity Solution Tree, или дерево возможностей Терезы Торрес: как задать команде продуктовый результат, сравнить решения и за 10 минут найти красные флаги в дереве.
Премортем: как найти причины провала проекта до его запуска
Премортем (pre-mortem) — анализ рисков проекта до запуска: сценарий на 45 минут, роль руководителя, шаблон «причина → сигнал → страховка → владелец».
STORM от Стэнфорда: ИИ-исследование, которое сначала ищет точки зрения
STORM от Stanford OVAL: как вести кабинетное исследование с помощью ИИ через роли, вопросы и источники, что доказала статья NAACL 2024 и где риски для компании.
Ценность информации по Хаббарду: сколько стоит знать до решения
Как посчитать в рублях, стоит ли заказывать исследование: ожидаемые потери, EVPI, инверсия измерений и разбор на числах по методу Дугласа Хаббарда.
Продуктовые решения при неопределённости: 8 методов для руководителя
Как CPO и основателю решать, что строить, не переплачивая за исследования: 8 методов от Mom Test и дерева возможностей до ACH и премортема в одном цикле.
Ошибки первого и второго рода в A/B тестировании
A/B тест - это инструмент принятия решений под неопределённостью. Вы никогда не знаете «правду» о вашем продукте со 100% уверенностью: у вас есть только выборка данных.
Плохие A/B тесты
Тест идёт третий день. PM открывает дашборд — версия B ведёт с конверсией 6.8% против 5.9% у контроля. P-value — 0.04. Коллеги в Slack пишут «запускаем?».
Как найти настоящую причину проблемы, а не её симптом
На еженедельном синке всплывает та же проблема: конверсия в активацию падает. Прошлый раз переписали онбординг — не помогло. До этого упростили регистрацию — тоже.
Боль vs просьба: как правильно отличать
Клиент на созвоне говорит: «Нам бы интеграцию с Salesforce». Продакт записывает. Дизайнер рисует. Разработчик пилит два спринта. Интеграция выходит. Клиент не пользуется.
Бесполезный JTBD - гипотезы которые не выходят в рынок
Квартал закончился. Спринты закрыты, задачи выполнены, дизайн отрисован. Только ни одна из пяти гипотез, которые обсуждали в январе, до рынка не дошла.
Дизайн A/B эксперимента: как спроектировать тест, который дает инсайды
Команда запускает A/B тест - две версии онбординга. Через две недели версия B побеждает: конверсия выше на 8%. Решение принято, версия B едет в прод.
Как перестать проектировать для «среднего пользователя» и начать для живого человека
Совещание по фиче. PM рассказывает, что «пользователь хочет простую автоматизацию отчётов». Дизайнер показывает интерфейс. Разработчик оценивает в спр... Совещание по фиче.
DIBB: как Spotify превратил «хотелки» в проверяемые ставки
У PM в руках — список из двадцати задач и ни одного внятного аргумента, почему одна важнее другой. В итоге побеждает тот, кто громче говорит или чьё кресло стоит дороже.
Данные говорят одно. CEO говорит другое
Команда делает то, что сказал CEO. Ошибки огребает продакт. Знакомо? У этого есть название — HIPPO. Highest Paid Person's Opinion. Проблема не в том, что CEO ошибается.
Боль клиента как источник гипотезы: как слышать проблему, а не просьбу
Клиент говорит: «Нам нужна интеграция с CRM». Команда строит интеграцию. Клиент не пользуется. Почему? Потому что решили просьбу, а не боль. Просьба — это «сделайте дашборд».
Double Diamond: не прыгай в решение — сначала найди правильную проблему
Double Diamond — фреймворк Design Council (2004). Первый ромб - про проблему, второй — про решение.
Minimum Lovable Product
Пролистывается по требованиям на продакта и увидел интересный пункт. И как же сильно он попадает в боль продактов Раньше все говорили про MVP.
RooCode - спасение для комплексных задач
В общем, поигрался с Cursor - видно, что заточены на режим сопровождения корпоративного разработчика. Выделить участок и сгенерировать отдельную коррекцию.