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

• где прячется основная проблема при работе с данными: что они могут и не могут нам дать;
• почему подход "сначала исследуем, потом принимаем решение" оказывается нарушенным и неэффективным;
• как проводить исследования правильно, какие элементы искать чтобы действительно развивать продукт и быть на волне трендов.

Ограничения данных в Product Discovery: взгляд в прошлое и будущее

В рамках Product Discovery компании используют данные для:

• управления воронкой;
• оптимизации бизнес-процессов;
• контроля полностью сформированных бизнес-процессов;
• оценки каналов коммуникации с аудиторией.

Однако через призму диффузии инноваций (читайте подробнее: диффузия инноваций, часть первая), аудитория делится на группы:

• инноваторы;
• ранние последователи (первопроходцы);
• раннее большинство;
• позднее большинство;
• отстающие (скептики).

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

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

Пример с Aris BPM (построитель диаграмм на Java) наглядно иллюстрирует эту идею: когда баг в загрузчике был устранен после 2-х лет существования, обновление встретило 100% одобрения пользователей, но многие этого обновления, к сожалению, не дождались.

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

И вот почему:

1. Ресурсы ограничены. Разработка и внедрение новых фичей требует времени, усилий и ресурсов. Если вы сосредотачиваетесь только на текущих потребностях большинства пользователей, вы можете упустить возможность инновации и создания чего-то уникального, что привлечет новых пользователей или удовлетворит более широкий спектр потребностей.
2. Продукт рискует устареть. Продукты должны постоянно развиваться и совершенствоваться. Если ограничиться только удовлетворением текущих потребностей, продукт может стать устаревшим и потерять привлекательность для пользователей в долгосрочной перспективе.
3. Пользователи не знают, что им нужно, пока им это не покажут. Поэтому инновационные решения могут изменить игру в индустрии и привлечь новые аудитории. Такие решения не всегда могут быть выявлены данными о текущих потребностях.

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

Когда подход «сначала исследуем, потом принимаем решение» становится препятствием на пути к успеху продукта

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

1. Пользователи не отвечают или не говорят правду. Это может быть по разным причинам: пользователи опасаются страха критики, хотят угодить или у них нет мотивации для участия в исследовании. Или продукт абсолютно новый и пользователи еще не имеют опыта взаимодействия с ним. Для таких случаев придуманы рабочие методы - предлагать анонимные опросы, проводить наблюдение за поведением пользователей в продукте и собирать фокус-группы с нейтральными фасилитаторами.
2. Исследователи не понимают пользователей, из-за чего исследования могут оказаться неполными или неточными. Когда исследователь не вник в специфику работы специалистов медицины, например, то продукт будет неудачным без достаточного понимания их реальных потребностей. Чтобы избежать таких ситуаций, нужно исследований “превратить” в пользователей: обучить их выполнению задач пользователей, а полученные результаты можно валидировать через экспертов отрасли.
3. Исследователи субъективны. Они могут повлиять на результат исследования пользователей и валидацию ценности. В качестве таких “последствий субъективности” обычно выделяют искажение данных, неверное понимание потребностей пользователей и некорректное принятие решений на основе исследований. Чтобы исключить такие последствия, стоит применять структурированные методики и валидированные инструменты для сбора данных. Также можно проводить проверку результатов исследований с помощью независимых экспертов.
4. Ресурсы ограничены: недостаток времени, денег или иных ресурсов может дать недостаточный для принятия взвешенного решения объем информации или наоборот, информации будет очень много, но ресурсов для отраслевого поиска не было, поэтому вся информация будет очень поверхностной. Здесь можно пробовать различные варианты решения проблемы, все будет зависеть от ваших целей. Из того, что предлагаем рассмотреть: приоритезация задач, фокус на ключевых целях, аутсорсинг некоторых исследовательских задач или использование доступных бесплатных источников данных. Также можно не пытаться сделать всё и сразу, а, например, уменьшить объем исследования, сфокусироваться на наиболее критичных аспектах продукта или проработать более долгосрочное планирование для оптимизации ресурсов.
5. Потребности пользователей меняются со временем: если исследование длилось полгода, то по его завершении результаты могут уже устареть. Если компания не обновляет исследовательские данные в продукте в течение двух лет, то их продукт теряет актуальность и конкурентоспособность. Чтобы следить за развитием рынка, советуют регулярно проводить небольшие “обзорные” исследования, следить за трендами в отрасли и использовать механизмы обратной связи с пользователями.

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

Новый взгляд на Product Discovery: как решить проблему исследований

Управление продуктом, известное как Product Discovery, включает несколько важных шагов:

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

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

Модель Continuous Feature Discovery

В таком контексте представляется концепция Continuous Feature Discovery, разработанная Терезой Торрес, экспертом в области Product Discovery (смотрите английское саммари ее книги «Continuous Discovery Habits»: Книга в кратком изложении | Continuous Discovery Habits(Английская версия) | Teresa Torres). Она предлагает еще один подход к управлению продуктом.

Суть Continuous Feature Discovery заключается в том, чтобы развивать продукт, добавляя в него новые функции. Этот метод успешно применяется многими компаниями. Здесь нет ничего принципиально нового, кроме одного: говоря Product Discovery, мы подразумеваем Feature Discovery и не выходим на уровень утверждения разработки фичи инвест.комитетом. То есть управление продуктом происходит в плоскости «рынок — операции — разработка». В рамках концепции Feature Discovery компания может организовать свой локальный цикл исследований, который позволяет проводить исследования быстрее и эффективнее.

Ключевые принципы Continuous Feature Discovery

Continuous Feature Discovery фокусируется на каждой фиче продукта, а не на всем продукте в целом, при этом сами принципы работают и на уровне фичи:
1. Подход, основанный на гипотезах (Hypothesis-Driven Approach):

• использование научного метода;
• формулирование и проверка предположений с помощью экспериментов;
• снижение риска и неопределенности.

2. Ориентация на потребителя (Customer-Centricity):

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

3. Быстрые циклы изучения:

• короткие петли обратной связи для быстрого обучения;
• частые исследования, испытания, итерации;
• ранняя проверка идей, экономия времени и ресурсов.

4. Кросс-функциональное сотрудничество:

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

5. Принятие решений на основе данных:

• опора на качественные и количественные данные о том, как реально фича применялась нашими пользователями;
• получение информации о поведении пользователей, предпочтениях, тенденциях;
• принятие обоснованных решений, определение приоритетности функций, измеряемое воздействие.

6. Непрерывное совершенствование:

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

Основные различия Continuous Feature Discovery и Product Discovery

К основным отличиям двух подходов обычно относят следующие характеристики:
1. Непрерывный процесс исследования
Continuous Feature Discovery — это непрерывный итеративный процесс исследования (ориентирован на Agile), в то время как Product Discovery — ступенчатый и следует методологии Waterfall.
2. Создание новых элементов продукта
Continuous Feature Discovery направлен на улучшение существующего продукта, в то время как Product Discovery ориентирован на поиск новых продуктов и ниш на рынке.
3. Реагирование на тренды
Continuous Feature Discovery позволяет компаниям адаптироваться к текущим трендам, а Product Discovery - помогает формировать новые тренды.
4. Масштаб
Continuous Feature Discovery сфокусирован на развитии продукта, в то время как Product Discovery ориентирован на лидерство на рынке и изменения в технологиях.

Примеры компаний, успешно применяющих Continuous Feature Discovery

• Spotify использует непрерывное исследование пользовательских предпочтений чтобы создавать персонализированные плейлисты и предложения. Кроме того, они разрабатывают новые функции, такие как "Spotify Wrapped", предоставляя статистику пользовательских предпочтений.
• Amazon постоянно улучшает интерфейсы своих веб-сайтов и мобильных приложений с помощью A/B-тестирования. Они также разрабатывают новые продукты, такие как Amazon Echo и Alexa.
• Netflix анализирует просмотры своих подписчиков и создает рекомендации на основе этой информации. Они также постоянно выпускают новый оригинальный контент, исходя из предпочтений аудитории.
• Airbnb собирает обратную связь от хозяев и гостей чтобы улучшить свой сервис, внедряет новые функции для улучшения процесса бронирования.

Таким образом, всегда стоит помнить, что исследования пользователей - необходимая и важная часть создания и развития продукта, но они должны применяться с умом и в сочетании со стратегическим видением и процессом проектирования продукта. Баланс между исследованиями, инновациями и проектированием — основа успеха продукта.
Часто при разработке продуктов данные “запаздывают” и мы видим только информацию об удовлетворенных потребностях клиентов, при этом не замечая какие еще перспективы развития у нашего продукта имеются в области “неудовлетворенных потребностей”. Это полезно для управления процессами в зрелых продуктах, но не способствует инновациям и развитию продукта. Подход "сначала разрабатываем, потом измеряем и потом принимаем решение" может оказаться ресурсозатратным, медленным и блокирующим развитие при интерпретации измерений в лоб. Результаты могут быть неточными и не соответствовать реальности, так как пользователи не всегда могут выражать свои истинные потребности, а исследователи могут подвергаться субъективному влиянию. А подход Continuous Feature Discovery позволяет непрерывно и итеративно исследовать рынок, создавать новые элементы продукта и быть на волне трендов. Это помогает продукту оставаться актуальным и востребованным, а исследования делать адаптивными и информативными.

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

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