Когнитивные искажения в продуктовой работе: как не обмануть самого себя
Краткий обзор типичных искажения мышления и практические предохранители для продуктовых решений
Зачем разбираться в искажениях
В продукте мы принимаем решения в тумане: мало данных, много давления, ограниченное время. Мозг не создан для таких условий — он оптимизирует, упрощает, достраивает. На бытовом уровне это помогает. В продуктовой работе — дорого обходится.
Самые опасные искажения — тихие. Они маскируются под опыт, интуицию и «ну так же все делают». Эта статья помогает заметить такие ловушки раньше, чем команда уйдёт в неправильный квартал.
Базовые искажения, которые встречаются чаще всего
Confirmation bias — видеть только подтверждения
Предвзятость подтверждения - одна из самых распространённых ловушек мышления.
Мы выбираем те данные, которые совпадают с нашей идеей, и игнорируем противоречия.
Пример: пять положительных интервью → «пользователи явно хотят фичу». Хотя пятеро — это чаще всего сегмент «лояльные фанаты».
Почему опасно: команда перестаёт видеть реальность и подпирает гипотезу эмоциями.
Survivorship bias — равнение на выживших
Предвзятость выжившего заставляет нас смотреть только на успешные кейсы.
Сравниваем себя с Airbnb, Tesla, Notion — забывая про тысячи команд, которые делали то же самое и умерли.
Почему опасно: переоценка успехов других и недооценка базовых вероятностей.
Sunk cost fallacy — «мы уже вложили слишком много, чтобы остановиться»
Ошибка невозвратных затрат — когда мы продолжаем проект только потому, что уже вложили в него время и ресурсы.
Проект живёт не потому, что приносит ценность, а потому что жалко усилий.
Почему опасно: сжигает кварталы, ресурсы и внимание.
Availability bias — последняя яркая история кажется законом
Предвзятость доступности — когда мы судим о вероятности события по тому, насколько легко вспомнить примеры.
Один громкий клиент, один твит, один недавний кейс — и кажется, что «все так думают».
Почему опасно: субъективный шум превращается в стратегическое решение.
Самые незаметные искажения (тихие, но разрушительные)
1. Base rate neglect — игнорирование базовых вероятностей
Предвзятость базовой ставки — когда мы не учитываем общие статистические данные и сосредотачиваемся на уникальности нашего случая.
Мы считаем свой кейс уникальным. Хотя рынок — статистически жестокая штука.
Пример: «У нас другой сегмент → средний CR нам не подходит». На практике 9 из 10 стартапов сталкиваются с теми же законами рынка.
2. Planning fallacy — оптимисты внутри нас
Ошибка планирования — когда мы систематически недооцениваем время и ресурсы, необходимые для выполнения задачи.
Команда всегда думает, что сделает быстрее, чем в прошлый раз. Но прошлые цифры стабильно говорят обратное.
Пример: «Два спринта и готово» → шесть недель спустя: «ну ещё чуть-чуть».
3. Authority bias — влияние сильного голоса
Предвзятость авторитета — когда авторитет говорит уверенно, мозг перестаёт думать критически.
Мы склонны принимать решения на основе статуса говорящего. Не из страха — просто это «проще».
Пример: «CEO сказал, что надо» → проверка данных исчезает.
4. Ambiguity effect — избегание неопределённых вариантов
Эффект неопределённости — когда мы избегаем вариантов с неизвестными исходами.
Мы выбираем знакомое, даже если оно хуже.
Пример: «Лучше расширим текущую фичу, чем попробуем новый подход». И продукт застревает в локальном оптимуме.
5. Outcome bias — оценка решения по результату, а не по качеству процесса
Предвзятость результата — когда мы судим о качестве решения по его исходу, а не по тому, насколько оно было обоснованным.
Если фича выстрелила — кажется, что решение было правильным. Хотя могла сыграть скидка, сезонность или просто случайность.
Почему опасно: закрепляет плохие процессы.
Практические предохранители (что реально снижает риски)
1. Критерии успеха заранее
До эксперимента: — формулируем метрику; — задаём «границу успеха»; — фиксируем время проверки.
Это снижает искушение подтасовать вывод под ожидания.
2. Независимые ревью
Аналитик, PM из другой команды или дизайнер. Стратегия проста: «один человек без эмоциональной привязки смотрит на данные».
Это выбивает confirmation bias и authority bias.
3. Контрольные группы и blind-методики
A/B, где команда не знает, какая версия «нужная». Даже в юзабилити-тестах: скрываем цель, чтобы не подсказать респонденту.
4. Decision gates
До старта проекта определяем точки, в которых пересматриваем решение: 2 недели → данные, 4 недели → пересборка, 6 недель → stop/go.
Это лекарство от sunk cost fallacy.
5. Фильтры шума
— «Три независимых сигнала» перед принятием решения — Убираем крайние мнения — Проверяем каждую сильную эмоцию данными
Быстрый чеклист перед любым решением
- Есть ли заранее определённые метрики успеха?
- Проведены ли CustDev-интервью с ключевыми (платящими) пользователями?
- Что мы не хотим видеть в данных? (тест на confirmation bias)
- Какие сигналы мы игнорируем?
- Какое решение мы бы приняли, если бы начали с нуля? (проверка на sunk cost)
- Насколько наш план реалистичен по сравнению с прошлым опытом?
- Основано ли решение на данных или на статусе говорящего?
- Что дороже: делать или не делать? (антидот ambiguity effect)
Вывод
Искажения — не ошибка характера. Это особенности нашего мозга. Мы не выключим их, но можем встроить процессы, которые защищают нас от самих себя.
Задача продакта — смотреть на реальность, а не на желание, чтобы гипотеза была правдой.
Вопросы для CustDev, которые снижают confirmation bias
Важно: цель этих вопросов — не получить «да» на вашу гипотезу, а расширить реальность и увидеть поведение, а не мнения. Они построены так, чтобы пользователь не угадывал «правильный» ответ.
1. Снять розовые очки (уход от желаемого ответа)
- «Расскажите о последнем случае, когда вы решали эту задачу. Что именно вы сделали?»
- «Что вас больше всего раздражает в текущем способе решения?»
- «Какие альтернативы вы уже пробовали? Что в них не работало?»
Зачем: мы изучаем факты поведения, а не то, что человек думает «в идеале».
2. Проверить реальную частоту и важность проблемы
- «Как часто возникает эта ситуация? Когда был последний раз?»
- «Если бы эта проблема исчезла завтра — что бы изменилось в вашем дне?»
- «Что происходит, если вы её не решаете?»
Зачем: подтверждение гипотезы требует частоты, а не эмоции.
3. Найти реальные критерии выбора
- «Как вы обычно выбираете решение? Что важнее всего?»
- «Что заставило вас перейти на текущее решение?»
- «Когда вы в последний раз разочаровались в продукте/фиче — почему?»
Зачем: помогает увидеть логику пользователя, а не придуманную модель продукта.
4. Снять иллюзию будущего поведения
Пользователи любят обещать, что «будут пользоваться». Это ловушка.
Вопросы:
- «Вспомните последний раз, когда вы говорили себе: ‘буду делать по-другому’ — что получилось на деле?»
- «Что должно произойти, чтобы вы реально начали пользоваться новым инструментом?»
- «Какие барьеры мешают вам попробовать что-то новое?»
Зачем: мы проверяем реальность, а не фантазии.
5. Проверка платёжной готовности (анти-wishful thinking)
Не спрашиваем «вы бы заплатили?». Люди всегда говорят «да».
Вопросы:
- «Сколько вы сейчас тратите на решение этой проблемы?»
- «А какой максимум готовы потратить, чтобы она исчезла?»
- «Что было бы достаточно ценным, чтобы вы поменяли привычный инструмент?»
Зачем: деньги — антидот самообмана. Факты > намерения.
6. Тест на нашу гипотезу без наведения
Эти вопросы выдают правду, даже если гипотеза вам нравится.
- «Представьте магию: проблема решена одним нажатием. О чём речь?»
- «Если бы у вас был персональный ассистент, что бы вы делегировали ему в этой задаче?»
- «Что самое раздражающее в текущем процессе — топ-1?»
Зачем: проверяет, совпадает ли реальная боль с тем, что вы хотите строить.
7. Самый жёсткий вопрос (и самый честный)
- «Если бы этот продукт исчез завтра — что бы вы делали вместо него?»
Зачем: это тест на необходимость, а не на вежливость.