Как провести исследования, если ресурсов не хватает

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

Ключевое отличие треугольника эффективности Discovery от проектного треугольника заключается в том, что далеко необязательно, что уменьшение одних ресурсов приводит к росту других. Часть приведенных нами инструментов и хаков позволяют не столько “переиграть” реальность, сколько оптимизировать её. Поэтому используются не только в условиях дефицита ресурсов треугольника, но и при их отсутствии. Как best practices.

В этой статье указаны несколько способов сокращения ресурсов при проведении a/b-тестов, что может вызвать бурю негодования среди специалистов, кто хорошо разбирается в их дизайне и проведении. С одной стороны существует математическая статистика с её законами, а с другой стороны объем ресурсов компаний не бесконечен, а результат получать нужно. По этим причинам можно говорить о существовании неких двух противоборствующих школ:

• идеалисты с лозунгом “если не удается соблюсти все критерии качества эксперимента, значит его результатам доверять нельзя”;
• и прагматики с лозунгом “любая информация важнее её отсутствия”.

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

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

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

Одна из причин потери времени при исследовании потребителей состоит в том, что в результате мы получаем данные, которые совершенно не помогают подтвердить или опровергнуть исходные гипотезы. Все потому, что в качестве брифа на исследования используют общие формулировки вида “разобраться, как потребитель покупает молоко”. Из такого описания сложно понять контекст цели для исследования. Что именно мы хотим узнать? Как он сравнивает разные упаковки молока? Какую жирность предпочитает? Или сколько за раз покупает бутылок?

Точно ли эта информация поможет принять решение об изменениях продукта? Не хватает главного – самих гипотез потребителя. А чтобы про них не забывать, тем самым не повторяя исследование дважды (или еще хуже используя результаты текущего), необходимо потратить немного времени на формализацию гипотез.

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

Например, вот так выглядит карточки гипотезы из методологии Product Architecture Framework - шаблон карточки гипотезы.

Для того, чтобы сократить риски при запуске продукта, не нужно сокращать ВСЕ риски. Можно ограничиться только теми, которые в максимальной степени влияют на результат, что в целом сократит время на проведение комплекса исследований. Такой подход базируется на концепции Riskiest Assumption Test.

В противовес последовательному процессу сокращения рисков, когда мы идем от валидации гипотез потребителя через гипотезы ценности и решений к гипотезам бизнес-модели и привлечения (концепции Customer Development и Lean Startup реализуются по такому принципу), в RAT мы фокусируемся на тех гипотезах, где риски для всей бизнес-инициативы являются максимальными.

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

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

Каденции, или циклы принятия решений, в течение которых мы ставим цели, проводим деятельность для их достижения и, в конце концов, подводим результаты – это тактовый процессор менеджмента. Чем быстрее частота этого “процессора”, тем большее количество решений может быть запланировано, принято или скорректировано. Причем корректировка иногда намного важнее первых двух.

Сделаем быстрый подсчет. Допустим, вы работаете по квартальным целям. Значит у вас есть четыре периода за год, когда вы можете принимать решения и скорректировать следующую итерацию работы. Если вы ставите цели каждый месяц, то уже двенадцать. Если вы работаете по двухнедельным спринтам, то в году у вас есть примерно 22-24 спринта, чтобы реализовывать и корректировать свою работу. Если недельными, то примерно 40-42 цикла.

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

Завершение “классического” a/b теста раньше может серьезно увеличить количество ошибок первого рода и свести на нет весь смысл проведения эксперимента (о проблеме “подглядывания” шикарно написано вот здесь). Однако, если вы ограничены во времени, можно сделать это совершенно легально, если использовать метод последовательного тестирования (simple sequential a/b testing), который не увеличивает вероятность ошибки при раннем завершении и может сэкономить время практически в два раза. Особенно хорошо метод работает при малых конверсиях, которые и требуют больших выборок / времени для получения статической значимости.

Однажды, компания DriverPack, создающая софт для быстрой установки драйверов и настройки Windows, поставила перед собой цель увеличить конверсию в установки с 30% до 40% всего за два месяца. Цель весьма амбициозна, но потенциально достижима, если бы все гипотезы из беклога сработали. Но такая ситуация - мечты. Прошел месяц, команда провела всего около 10 тестов, из которых успешными оказались пара. Бутылочное горлышко лежало не столько в показателе конверсии, сколько в поддерживающей метрике крашей, которая не должна превышать 5%. Здесь на помощь команде и пришел метод simple sequential a/b testing, который не только позволил увеличить в два раза количество проводимых экспериментов в следующий месяц, но и заранее завершить те, которые приводили к опасному проседанию метрик.

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

Зачастую, при значимых изменениях продукта требуется оценить их влияние на долгосрочный retention rate. С учётом периода получения ценности потребителем, эксперимент может растянуться до полугода и даже дольше, иногда становясь блокером для проведения других экспериментов. Как правило, у команд нет столько времени, поэтому вместо исследуемой метрики можно использовать метрики, динамика которых коррелирует с исследуемой, но обладающие меньшим периодом времени для измерения.

Для этого можно использовать коэффициенты Жаккара, позволяющие определить вероятность сходства двух выборок. Ниже представлен кейс компании Flo, лидера среди приложений женского здоровья, в котором рассчитан индекс Жаккара для метрик retention разного периода. В таблице видно, что retention второго месяца (m1, т.к. отсчёт с нуля) на 61% коррелирует с retention со 2 по 8 день после установки приложения. Использование альтернативной метрики снижает качество результатов, но значительно сокращает время эксперимента.

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

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

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

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

Это хорошо известно на любом производстве; Дао Тайота трактует подобные затраты времени как потери. Соответственно, необходимо бороться с этими потерями. Самый проверенный способ борьбы – их не создавать. Для этого нужно подходить к исследованиям не как к проектной деятельности, имеющей начало и конец, а как к процессной, которая совершается на регулярной основе. Ведь если анализ потребителей не прекращается, то и потерь на его старт не будет.

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

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

В 2019 году когда я был в гости у Ultimate Guitar и был поражен насколько подробна их база гипотез в Confluence, накапливаемая ими к тому моменту уже несколько лет. Информации было так много, что у них возникала уже другая проблема - они стали запускать эксперименты, которые уже проводили, потому что было сложно найти результаты среди такого большого объема. Всем бы такие проблемы :)

Несомненно, культура формализации требует некоторой бюрократизации, что в реальности мало кто делает, оставляя результаты валидации гипотез вообще в виде сообщений в Slack или email. Ценностями такой культуры будут:

• формализация гипотез и экспериментов в виде карточек вместо устного изложения или указания в переписках;
• хранение карточек гипотез в едином информационном пространстве вместо индивидуальных папок;
• управление мета-информаций о гипотезах: времени проведения экспериментов, актуальном статусе и результатах, контексте продукта, условий проведения (в том числе одновременно с другими экспериментами);
• предварительный челлендж гипотез коллегами вместо индивидуальной работы;
• совместное обсуждение с другими менеджерами результатов экспериментов для расширения кругозора вместо обсуждений “сотрудник-руководитель”;
• в первую очередь обращение к базе знаний вместо создания эксперимента с нуля и создания велосипедов.

Ключевым критерием для определения, действительно ли ответ статистически значимый (а значит обладает высокой степенью истинности), является доверительный интервал. В качестве “эталона” используется значение 95%. Очень грубо и не совсем математично это значит, что реальное значение показателя (например, конверсии) будет с вероятностью 95% находиться в полученном нами диапазоне значений для конкретной выборки, на которой мы проводим тест.

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

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

Использование классического статистического подхода при проведении a/b тестов требует достаточно строгих условий эксперимента: знаний о показателе на старте, объеме выборки, невозможности подсматривания и расчете показателя p-value. Вся эта строгость необходима, чтобы однозначно сказать, существует отличие вариантов или нет (опровержение нулевой гипотезы).

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

Альтернативным способом проведения a/b тестов, который решает эти проблемы, является байесовский подход. Он базируется на совершенно другой логике принятия решений, в которой ключевую роль играет не бинарный результат сравнения двух альтернатив, а распределение вероятностей того, что один вариант лучше другого (подробнее про математику вы найдете вот здесь). Чем больше данных, тем это распределение “красноречивее” отвечает на вопрос, но чтобы сделать вывод, нет необходимости собирать “максимальное” количество знаний, как того требует статистический подход. Можно получить результаты раньше, хоть и с меньшим качеством.

Например, вот так байесовский подход использовала компания Garage 8 в своей работе:

Во время разработки флоу a/b тестирования рекламных креативов мы поставили перед собой цель: сократить длительность a/b тестов и, как следствие, рекламные бюджеты. В качестве альтернативы классическому (частотному) подходу, где требуется не только заранее рассчитать выборку, но и набрать ее для достижения статистической значимости, мы выбрали байесовский подход, который позволяет принять решение на основе меньшей выборки. Ключевая метрика здесь P2BB (Probability to be the best или Вероятность того, что креатив лучший). На выходе мы получаем распределение вероятностей. Например, вариация А лучшая с вероятностью 80%, вариация Б – с вероятность 20%. Мы используем отметку P2BB 75% для определения победителя. За 2023 мы провели более 150 a/b тестов на рекламной платформе. Благодаря использованию байесовского подхода большинство a/b тестов длились 4-7 дней. В одном из наших регионов за 2023 на рекламной платформе 53% конверсий принесли победители a/b тестов. На скриншоте приведен пример, когда статистическая значимость не достигнута, однако байесовский подход позволяет принять решение о победителе.

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

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

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

Ключевой источник для получения таких case study - кейсы с конференций и вебинаров: Product Sense, подкаст Make Sense, Product Camp, Epic Growth.

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

• за аналогичный исторический период (то есть той же сезонности);
• за прошлый период (то есть без учета сезонности);
• прошлых когорт (целевой аудитории с другими характеристиками);
• смежных продуктов внутри вашего портфеля (например, если продукты - это курсы по Java и Python).

В 2023 году компания Optimizely опубликовала отчет на основании анализа 127.000 экспериментов, проведенных на их платформе. Одним из выводов отчета стало, что большое количество тестов (на одного разработчика/аналитика) приводит к ухудшению качества проводимых экспериментов. Если это число превышает 11 в год, то импакт падает на 40%, если больше 30 - на 87%. Обратный вывод из этой ситуации можно сделать, что если вы сократите количество тестов за год, то это либо не снизит ваше качество (или вообще его увеличит), но уж точно снизит бюджет.

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

Источники с такой информацией:

• Исследовательские и консалтинговые агентства:
• зарубежные: Gartner, McKinsey, Boston Consulting Group, Naumen, NPD Group, Deloitte, Nielsen Norman Group, etc;
• российские: РОМИР, OMI, Data Insight, АКИТ;
• Исследования лидеров отрасли: компании-лидеры, как правило, проводят количественные исследования, основанные на собственной клиентской базе (например, Яндекс Исследования);
• Лидеры мнений и отраслевые эксперты: независимые эксперты часто проводят собственные рыночные исследования, в которых можно узнать важные инсайты (например, Федор Вирин);
• Компании-агрегаторы информации: классификаторы (g2, Capterra, TAdviser), агрегаторы статистики (Statista, SimilarWeb, StatCounter, Sensor Tower).
• Отраслевые дайджесты событий и СМИ: источники новостей о продуктах в целом (Product Hunt, TechCrunch, VC, etc.) и под конкретную отрасль;
• Отчеты инвесторам публичных компаний: кроме информации о самой компании могут содержать интересную информацию об отрасли в целом;
• Венчурные фонды и стартап-акселераторы: некоторые фонды делятся аналитической информацией о трендах рынка (например, YCombinator, a16z, ФРИИ);
• Государственные источники статистики: открытые источники исследований по разным показателям экономики (например, Росстат, ВЦИОМ);
• Площадки с информацией по менеджменту продуктов: статьи GoPractice, Reforge, https://growth.design/case-studies.

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

Не существует такой вещи, которую нельзя было бы заменить Excel. Эффективным способом сокращения затрат при проверке гипотез решений является использование no- или low-code инструментов, когда вместо разработки кода используется настройка уже существующих платформ (подборки инструментов собраны тут https://nocodelist.co/ и тут https://www.nocode.tech).

Существуют универсальные “процессоры”, которые особенно хороши для автоматизации операционных процессов и прототипирования внутренних продуктов: Staker, Bubble, Fibery, ClickUp.

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

Создание мобильных приложений: Glide, Adalo.

Чат-боты: ManyChat, Chatfuel, Botmother, Aimylogic.

Автоматизация форм: Google Формы, TypeForm.

Создание сайтов, лендингов, интернет-магазинов, обучающих площадок: Tilda, Ecwid, Webflow, Wordpress.