Периодически мы чувствуем, что предлагаем хорошее решение. Как в меме: «Эта фича будет прибыльной, но я пока не могу этого доказать». В этом случае оценка продукта не учитывает мнение целевой аудитории, как будто мы единственный пользователь нашего решения. 

Иногда при формировании новых гипотез мы можем столкнуться с подменой понятий идеи, ценности и спроса. В моменте идея может показаться нам настолько классной, что мы объясняем её ценность команде, но пропускаем этап её фактической проверки и сразу приступаем к разработке. 

Бывает, что интуитивное решение оказывается успешным. Но сейчас рынок растёт стремительнее, а поведение пользователей становится менее предсказуемым. Поэтому в текущих реалиях интуиция может сыграть с вами злую шутку.

Давайте разберёмся, как же всё‑таки принимать решения с опорой на реальность.

Модели принятия решений — главный фильтр идей

Давайте начнём с теории и вспомним, какие модели принятия решений бывают, какие плюсы и минусы можно выделить в каждой из них.

Рациональная модель 

Она позволяет найти лучшее решение среди альтернатив, сформировать картину расходов и потенциальных возможностей от принятого решения. Модель предполагает следующие этапы:

• Определение проблемы.

• Определение критериев успешного решения.

• Определение веса каждого критерия.

• Определение и оценка альтернатив для решения проблемы.

• Оценка результатов.

Минус модели: чаще всего она требует вложения ресурсов — финансовых и временных.

Модель ограниченной рациональности

Она предполагает поиск оптимального, а не лучшего, решения, которое позволит добиться результатов быстро. Как правило, в рамках этой модели выбирается несколько критериев и альтернатив, опираясь на которые принимается решение без анализа всех нюансов. Подойдёт, когда нет ресурсов на проведение глубокого исследования.

Интуитивная модель

Несмотря на название, интуитивная модель не формируется на какой‑то сверхспособности. Она складывается из наработанного нами опыта, который мозг использует, чтобы прогнозировать разные сценарии. Но наш опыт часто отличается от опыта других, поэтому мы не можем экстраполировать его на большую базу пользователей.

Модель Врума‑Йеттона, или модель совместного принятия решений

Эта управленческая концепция разработана в 1973 году психологами Виктором Врумом и Филиппом Йеттоном. Её суть модели заключается в том, что эффективность решения зависит не только от его качества, но и от готовности сотрудников его принять. 

Модель предполагает пять типов решений:

• A1 (Авторитарное 1): руководитель принимает решение самостоятельно, не консультируется с командой.

• A2 (Авторитарное 2): руководитель асинхронно запрашивает информацию у нескольких сотрудников, но принимает решение сам. 

• C1 (Консультативное 1): руководитель обсуждает проблему с отдельными сотрудниками, выслушивает их мнения, но принимает решение сам.

• C2 (Консультативное 2): руководитель собирает команду, обсуждает проблему совместно, но окончательное решение остаётся за ним.

• G2 (Групповое): решение принимается группой, роль руководителя сводится к модерации процесса.

Эта модель особенно полезна, когда нужно быстро определить баланс между скоростью принятия решения (A1, A2) и вовлечённостью сотрудников (C2, G2).

Модель принятий решений на основе распознаваний (RPD)

Основная идея этой модели заключается в сравнении вариантов и выборе лучших из них. Процесс состоит из нескольких действий:

1. Оценка ситуации
Менеджер анализирует входные данные и ищет сходства с ситуациями, которые он уже встречал. Если контекст знакомый, в голове включается алгоритм принятия решения.

Пример

Руководитель видит падение продаж в сезон отпусков. Вместо того чтобы строить сложные прогнозы, он сразу запускает план стимулирования.

2. Проверка приемлемости
Менеджер мысленно прогоняет один выбранный сценарий: «Если я сделаю X, что произойдёт?». Если в воображении всё складывается удачно, решение принимается. Если возникают проблемы, сценарий корректируется или отбрасывается.

3. Действие
На этом этапе происходит принятие решения и его реализация.

Модель RPD актуальна в следующих ситуациях:

• Когда нет времени на сбор и анализ данных. Менеджеры опираются на интуицию, которая на самом деле является накопленным опытом распознавания угроз.

• Когда с задачей работает опытный специалист. Новичкам лучше использовать аналитический метод и сравнивать возможные варианты, так как у них нет базы наработанных паттернов. 

• Когда задача уникальна, но с элементами знакомых подзадач.

Как в Точка Банке появляются фичи

Мы стараемся делать так, чтобы каждая фича была последствием решения проблемы или потребности клиентов. Поэтому, как правило, мы используем рациональную модель принятия решений, реже — модель ограниченной рациональности.

Вот алгоритм, по которому идём во время проработки новых идей.

Качественные интервью

Каждый продакт в Точка Банке может организовать качественные интервью, в рамках которых встречается с пользователем и общается о его работе. Как правило, на качественных интервью нам удаётся и нащупать проблему, и установить дружеский контакт. Так формируется лимит доверия, благодаря которому пользователю легче делиться проблемами или идеями для доработок.

На этапе качественного интервью важно ответить на вопросы о респонденте:

• какие он решает задачи;

• с какими сложностями при этом сталкивается;

• какие «костыли» использует в работе.

Наша цель — найти боли клиентов и оценить, насколько они критичны для них. Исходя из этих данных мы понимаем, какую проблему будем решать, и формируем гипотезу ценности.

Количественные исследования

Опыт каждого пользователя уникален, поэтому и проблемы, и решения, которые мы предлагаем, могут меняться. Нам важно понять массовость опыта, чтобы оценить потребность клиентов в фиче и грамотно приоритизировать реализацию фичи.

На этапе количественного исследования важно ответить на вопросы:

• сколько пользователей сталкиваются с проблемой;

• насколько она критична для них;

• насколько это массовая проблема.

В Точка Банке мы чаще всего используем следующие инструменты:

• Опросы. Задаём клиентам прямые вопросы о конкретных проблемах. Или на примере конкретной проблемы узнаём, какие варианты «обхода» клиент использует в работе и насколько это для него критично.

• Аналитика. Это может быть веб‑аналитика, аналитика поведения пользователя, аналитика обращений в поддержку.

Выбор инструмента должен исходить из проблемы пользователя и соотносить полученный результат и затраченные ресурсы на него.

Проверка спроса

На этом этапе нужно определить и оценить гипотезу ценности решения.

Пример 

Мы выходим к клиенту с вопросом: «Мы знаем, что вы заходите в онлайн‑банк ночью, и от яркого света экрана телефона у вас могут болеть глаза. Мы можем сделать тёмную тему, чтобы вы чувствовали себя комфортнее. Вы будете пользоваться этим?». Пользователи ответят: «Да», а после сложных доработок может оказаться, что большинство сидят в телефоне с включённым светом и не испытывают дискомфорта. Так мы столкнёмся с ситуацией, когда проблема есть, но спроса на её решение нет.

Чтобы избежать таких ситуаций и оценить фактический спрос, мы используем следующие инструменты:

• Fake door. Подробнее об инструменте рассказывали здесь.

• Ручные продажи.

• Консьерж‑тест.

Для проверки спроса можно запустить цикл продаж, посмотреть на готовность клиентов к покупке или подключению фичи и оценить возражения.

Запуск MVP

После того, как мы определили проблему, массовость и спрос, мы можем перейти к MVP — продукту с ограниченной функциональностью. 

С помощью него оцениваем:

• реальное использование продукта;

• найти барьеры при использовании;

• сформировать воронку активности и понять, на каком этапе пользователи могут отваливаться, каким функционалом не пользуются.

На этом этапе мы можем выявить сложность онбординга, непонятную ценность или организационные ограничения. 

Для меня идеальная формула запуска продукта выглядит так:

Качественное интервью → количественная проверка → проверка спроса → MVP → разработка

Исключение каждого из этапов может быть обосновано только жёсткими факторами.

Как ещё использовать полученные данные

В рамках цикла исследования мы получили следующую информацию:

• проблему какого сегмента мы решаем;

• насколько проблема массовая, какое влияние она оказывает на пользовательский опыт;

• насколько высок спрос и экономический потенциал решения;

• Сформировали понимание реального использования фичи.

Но продакты и их команды часто живут в реалиях, когда исследуемая фича — не единственная. А чаще бывает так, что помимо уже имеющегося бэклога в рамках качественных исследований могут появиться сразу несколько проблем пользователей. И тогда возникает вопрос: а за что браться?

Как в Точка Банке запускали AI‑ассистент для бухгалтера

AI‑ассистент для бухгалтера — это помощник, который готовит ответы на базе нормативных документов.

Как родилась гипотеза

Идея продукта не появилась из ниоткуда. Команда продакта Ксюши Соколовой начала с глубокого погружения в контекст: провели качественные интервью, чтобы понять, как работает бухгалтер, и изучили внешние ресурсы, например, профильные телеграм‑каналы. Это помогло выявить важную деталь: бухгалтеры постоянно в поиске нормативно‑правовой информации, так как нормативная база часто меняется. При этом они используют не только классические системы вроде КонсультантПлюс, но и альтернативные сервисы поиска.

Ценность

Во время изучения пользовательского пути обнаружили, что средний срок получения ответа на вопрос клиента — от одного часа до одного рабочего дня. В темпе работы бухгалтера такие сроки ощутимы, а значит специалистам ценно время. Поэтому команда поставила перед собой амбициозную цель: создать продукт, который будет отвечать за секунды.

От идеи к MVP

Статистика запросов бухгалтеров показала, что чаще всего они задают вопросы про патент. Этот инсайт стал фундаментом для нашего MVP. 

Чтобы протестировать потребность без запуска сложной разработки, решили использовать метод «Волшебник ОЗ». Мы предоставили группе бухгалтеров доступ к функционалу, который выглядел как готовый продукт. Но за кулисами систему обрабатывал сотрудник вручную — клиенты не знали, что с ними общаются люди, а не ИИ. 

Ценность продукта измеряли с помощью метрики удержания третьего месяца (Retention Month 3). До проведения теста сформировали ожидание на уровне 5%, но по факту получили все 10%. А ещё собрали ряд интересных паттернов, на основе которых скорректировали разработку продукта. Удержание на четвёртый месяц стало зелёным светом к разработке продукта.

Пример с AI‑ассистентом бухгалтера отлично вписывается в концепцию «проверили → убедились → сделали». Для проверки гипотезы провели несколько качественных исследований, убедились в гипотезе и подтвердили её ценность с помощью метода «Волшебника ОЗ». И только после полученных данных приступили к разработке.

Вывод

Время от времени нам, продактам, хочется принять решение с опорой на внутреннее ощущение. Но наше субъективное видение может не совпадать с реальными проблемами и потребностями пользователя. 

Важно находить баланс между действиями без подтверждения своих гипотез и боязнью ошибиться при принятии решения. И это, пожалуй, главная задача продакта. С одной стороны, мы рискуем запустить фичу, опираясь лишь на интуицию, а с другой — можем застрять в бесконечном сборе данных, пытаясь построить идеальную модель мира и так и не начать действовать.

Почаще задавайте себе вопросы: «Достаточно ли у меня данных, чтобы быть уверенным в пользе от этой фичи? Я опираюсь на данные, или мне просто кажется?». И если «кажется», то вы в шаге от создания ненужной фичи.