Как мы перестали хвататься за гипотезы и начали выбирать точки максимального потенциала

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

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

Проблема в том, что сама по себе хорошая идея ещё не означает, что именно её сейчас стоит делать. Например, у наших покупателей есть вполне реальная боль: им неудобно повторять предыдущий заказ и заново добавлять товары. Можно увидеть эту проблему, придумать решение, провести A/B-тест и даже получить статистически значимый результат.

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

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

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

Почему я не начинаю с гипотез

Я вижу как минимум три риска в подходе «увидели проблему — побежали решать».

Первый — решить не самую приоритетную боль пользователя.

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

Второй — потратить ресурсы на задачу с небольшим потенциалом для бизнеса.

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

Третий — выбрать решение, которое затрагивает только небольшую часть самой проблемы.

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

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

Если это получилось, точки роста во многом становятся очевидными сами.

Шаг 1. Понять, что действительно болит у пользователей

Один из инструментов, который нам сильно помог, — исследование пользовательских болей.

Мы собрали вместе всё, что уже знали о проблемах нашего продукта:

• результаты кастдевов;

• UX-тесты;

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

• отзывы в сторах;

• уже известные команде боли;

• гипотезы о проблемах, которые ещё требовали проверки.

После этого мы провели исследование удовлетворённости и болей. С помощью метода Johnson's Relative Weights оценили, какие аспекты продукта сильнее всего влияют на общую удовлетворённость пользователей. Отдельно посмотрели результаты по разным сегментам аудитории — например, новичкам и более опытным пользователям.

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

В моём продукте исследование помогло выделить три ключевые боли:

1. товара нет в наличии на этапе сборки;

2. покупателю непонятно, когда привезут заказ;

3. сложно изменить список товаров в уже оформленном заказе (например, убрать что-то или добавить).

Это исследование делается не “один раз и навсегда”. Мы выпускаем новые фичи и постепенно закрываем проблемы, поэтому картину нужно обновлять. Я бы возвращалась к такому исследованию, например, раз в квартал.

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

Шаг 2. Понять, как каждый участок продукта влияет на деньги

Знать боли пользователя недостаточно. Следующий вопрос: как мой продукт влияет на прибыль компании?

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

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

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

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

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

Именно поэтому важно не останавливаться на очевидных связях.

Как мы это исследуем с аналитиком

У меня есть регулярные еженедельные синки с аналитиком. Мы можем взять конкретную боль, участок CJM или экран продукта и задать себе простой вопрос: понимаем ли мы, как это влияет на прибыль компании?

Например: 

Покупатель не может изменить время доставки. Как это влияет на прибыль?

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

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

Важно искать не только положительное влияние

Отдельная ловушка — смотреть только на то, сколько продукт может дополнительно заработать.

Продукт может влиять на бизнес и отрицательно.

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

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

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

Шаг 3. Понять контекст стейкхолдеров

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

С ними важно регулярно общаться и понимать:

• какие у них сейчас приоритеты;

• как устроены их процессы;

• какие у них стратегические фокусы;

• где изменения нашего продукта могут повлиять на их показатели.

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

Поэтому при выборе фокуса важно смотреть не только внутрь собственной продуктовой зоны, но и по сторонам.

Шаг 4. Понять роль разных пользовательских работ в продукте 

Ещё один слой — понимание пользовательских работ.

Здесь я опираюсь на JTBD, но дополнительно использую собственную рабочую классификацию: разделяю пользовательские работы по их роли для пользователя и бизнеса на core, must-have, delighters и growth. Это не отдельный общепринятый фреймворк, а способ структурировать работы и понять, какую роль каждая из них играет в продукте.

Core — ключевые работы, ради которых пользователь в принципе обращается к этой части продукта. Если продукт плохо их выполняет, он не решает основную задачу пользователя.

Например, к core-работам в моём продукте относятся:

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

И:

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

Must-have — базовые ожидания от категории. Они могут быть не главной причиной использования продукта, но их отсутствие воспринимается как недостаток, особенно если такая возможность уже стала стандартом рынка.

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

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

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

И только теперь — гипотезы

В результате у меня постепенно складывается несколько слоёв знания о продукте.

Я понимаю:

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

• как разные части продукта влияют на доходы и расходы компании;

• сколько это влияние составляет в деньгах;

• какие работы пользователь считает базовыми и наиболее важными;

• как мой продукт связан со стейкхолдерами;

• какие фокусы сейчас есть у компании.

Теперь я начинаю соединять всё вместе и искать точки, в которых сходятся несколько факторов.

Например, возьмём редактирование уже оформленного заказа.

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

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

И вот здесь происходит важный для меня сдвиг: мне уже не нужно садиться и придумывать, какую гипотезу взять следующей.

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

Сквозной кейс: прогноз времени доставки

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

Шаг 1. Начать с пользовательской боли

В исследовании болей моего продукта регулярно возникала проблема ожидания заказа.
После оформления покупатель не всегда понимал, когда именно приедет его заказ. Из-за этой неопределённости часть пользователей шла искать дополнительную информацию или обращалась в поддержку.
Масштаб был заметен и в данных: по теме «Статус заказа» в поддержку обращались около 5 тысяч пользователей в неделю.
На этом этапе я ещё не пыталась придумать решение. Формулировка была именно про проблему:

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

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

Шаг 2. Понять, что именно нужно пользователю

Мы отдельно исследовали сценарий ожидания заказа и выяснили, что пользователю недостаточно просто знать, что заказ «собирается» или «едет».
Главный вопрос был гораздо конкретнее:

Когда именно приедет мой заказ?

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

Шаг 3. Проверить проблему через аналитику

Качественного исследования было недостаточно, чтобы определить приоритет.
Следующим шагом я пошла к аналитику и начала смотреть, что происходит с пользователями, которым не хватает информации о заказе.
Мы увидели не только большое количество обращений в поддержку, но и связь с отменами.
За одну из анализируемых недель в поддержку по статусу заказа обратились 5 402 пользователя. Из них 652 впоследствии отменили заказ — около 12%. Часть пользователей затем перезаказала товары в тот же день, но значительная часть выручки всё равно терялась.
Здесь важно аккуратно работать с причинностью.
Эти данные не означают, что все 652 заказа были отменены именно потому, что пользователь не видел прогноз. Но они показали, что проблема ожидания заказа связана уже не только с субъективным неудобством: вокруг неё есть измеримые бизнес-показатели, которые стоит исследовать дальше.
В результате у нас появилось несколько уровней проблемы:
пользовательский: человек не понимает, когда приедет заказ;
операционный: он обращается в поддержку;
бизнесовый: среди пользователей с таким проблемным сценарием мы видим отмены и потерю выручки.

Шаг 4. Положить проблему на дерево метрик

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

неопределённость во время ожидания → обращение в поддержку → стоимость обработки обращения → рост расходов.

Вторая — с результатом самого заказа:

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

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

Шаг 5. Перевести проблему в деньги

Дальше я стараюсь понять не только наличие эффекта, но и его потенциальный масштаб.

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

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

И здесь масштаб оказался ещё больше: потенциальные потери на отменах в несколько раз превышали расходы на поддержку.

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

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

Шаг 6. Понять пользовательскую работу

Следующий слой — пользовательская работа, которая стоит за проблемой.
Для прогноза она звучит примерно так:

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

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

• среди разных типов информации наиболее ценным оказался прогноз времени доставки;

• основным местом считывания информации об активном заказе была детализация заказа.

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

Шаг 7. Разобраться со стейкхолдерами и зависимостями

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

Шаг 8. Понять, стоит ли брать задачу в работу

К этому моменту у меня уже было несколько независимых аргументов в пользу одной области.
Мы знали, что:

• проблема регулярно возникает у пользователей;

• вокруг неё есть несколько тысяч обращений в поддержку в неделю;

• пользователям важнее всего знать именно прогноз времени доставки, а не просто видеть дополнительные статусы, карту курьера или другие способы информирования;

• основным экраном получения информации является детализация заказа;

• прогноз уже существует, но на этом экране не показывается;

• проблема связана с операционными расходами на поддержку;

• среди пользователей с таким сценарием мы видим отмены;

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

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

• для проверки гипотезы не нужно строить новую систему прогнозирования с нуля.

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

И только теперь — гипотеза

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

1. Пользователю нужен прогноз.

2. Прогноз у нас уже есть.

3. Пользователь ищет информацию в детализации заказа.

4. Прогноза там нет.

Отсюда гипотеза:

Если начать показывать существующий прогноз времени доставки непосредственно в детализации заказа, то покупатель сможет быстрее получить ответ на главный вопрос во время ожидания — когда приедет заказ. Это снизит неопределённость и, как следствие, количество обращений в поддержку по статусу заказа.

Изначальная постановка задачи также связывала появление прогноза в детализации со снижением беспокойства пользователя и количества обращений.

Шаг 9. Что мы сделали

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

Шаг 10. Что получили

Гипотезу проверили через АБ-тест.
После появления прогноза непосредственно в детализации заказа количество обращений в поддержку снизилось на 19%, что является стат. значимым эффектом.
После подтверждения эффекта решение раскатали на всех пользователей.
В результате весь путь выглядел не как:

«Мы придумали фичу с прогнозом и решили её сделать».

А как:

Нашли боль → исследовали, какая информация действительно нужна пользователю → выяснили, что прогноз ценнее других способов информирования → определили основное место считывания информации → обнаружили разрыв между существующей возможностью и пользовательским сценарием → проверили влияние проблемы на метрики → оценили финансовый потенциал → определили пользовательскую работу → разобрали зависимости → сформулировали гипотезу → проверили её в АБ-тесте → получили −19% обращений.

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

Хорошая гипотеза должна сойтись в трёх точках

Если совсем упростить мой подход, хорошая продуктовая сильная точка роста должна отвечать сразу трём условиям:
1. Решать значимую боль покупателя.
2. Быть финансово эффективной.
3. Встраиваться в текущую стратегию компании.
Если глубоко изучить продукт со всех этих сторон, найти место, где сходятся три условия, становится гораздо проще.
Но важно понимать масштаб работы за этой схемой.
Исследование болей у нас заняло около трёх месяцев. Исследование взаимосвязей продукта и финансовых показателей вместе с аналитиком — ещё примерно месяц. Просчёт P&L — тоже около месяца. Отдельно потребовались десятки часов исследований пользовательских работ.
То, что в конце выглядит как несколько аккуратных артефактов — исследование болей, дерево метрик, P&L, карта стейкхолдеров, — на самом деле результат месяцев погружения в продукт.
И это не система, которую можно один раз построить и больше не трогать. Продукт меняется, появляются новые фичи, закрываются старые боли, меняются приоритеты пользователей и компании. Поэтому все эти знания нужно регулярно обновлять.
Но в результате меняется сам принцип работы.
Вместо:
«Какую бы гипотезу нам придумать?»
появляется другой вопрос:
«Что мы уже знаем о продукте — и где из этих знаний складывается самая сильная точка роста?»