Форсаж: гонка продактов. Почему «давай быстрее» часто не работает на благо продукта и бизнеса?

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

В конце мая мы dthink.ru проводили исследования на мероприятии Startup Village в Сколково и подтвердили свое предположение, что скорость и быстрая проверка гипотез важна бизнесу. Однако, мы также нашли зону роста в области понимания своих пользователей. И под пониманием пользователей я имею ввиду не проверку гипотез. Хотя, давайте обо всем по порядку.

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

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

Шпаргалка для того, кто создает продукт
Шпаргалка для того, кто создает продукт

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

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

По итогам того самого исследования в Сколково мы поняли, что чаще всего команды под исследованиями понимают проверки гипотез. Что такое проверка гипотезы? Это просто подтверждение или нет, что твое предположение работает для людей. Это делается через такие исследования, как A/B-тесты, юзабилити-тесты, короткие интервью или аналитика данных. Зачастую это происходит, когда продукт уже обрел какую-то форму, как правило есть MVP.

Сегодня, ко многим командам приходит понимание о важности проверки идеи, чтобы убедиться что концепция имеет «под собой почву», прежде чем тратить деньги на разработку MVP. Например, такой подход активно используют Google в рамках своего дизайн-спринта. Как правило команда там работает с уже имеющейся крупной идеей-задачей, собирает много информации по ней, генерит идеи, как сделать, создает юзер стори, прототипирует и тестирует прототипы. Это происходит после того, как идеи сформировались в виде задач и хотелок, но до того, как они приняли форму продукта или дизайна.

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

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

Пространство решений, где у нас уже есть идея в какой-либо форме (MVP).

Пространство стратегии, где есть идея/гипотеза, но нет MVP или дизайна.

И пространство проблем, где нет идей, а есть проблемы, цели и поведение клиентов.

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

Источник https://indiyoung.com
Источник https://indiyoung.com

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

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

Если вы в пространстве стратегии, примерные вопросы, которые вас будут беспокоить: Будет ли полезна наша идея приложения для тренера тренажерного зала? Могут ли клиенты помочь нам придумать функции? Рассмотрели ли мы идею со всех сторон? Можно ли адаптировать нашу идею для других людей, не только тренеров? Какая из наших идей принесет наибольшую пользу?

Еcли вы в пространстве проблем, то в этом случае вопросы будут: Что происходит в головах людей, когда они посещают тренировки, чтобы оставаться в хорошей физической форме, сбросить вес, восстановиться после травмы, подготовиться к соревнованиям или нарастить мышцы? Чем руководствуются и какой стиль мышления у разных персон относительно этих задач? Как мы можем поддержать образ мысли персон сейчас? А позднее? Есть ли возможности сделать наш продукт таким, чтобы люди сами хотели воспользоваться им? Как мы можем создавать ценность для людей, основанную не только на деньгах?

Помимо того, что вы видите вопросы, выделенные курсивом, на которые сложно ответить с уверенностью, потому что эти вопросы требуют глубокого понимания того, что происходит в сознании людей. Также вы точно заметили разницу в глубине вопросов и в глубине тех ответов, которые мы получаем. С уверенностью можно сказать, что если вы начинаете процесс создания продукта или услуги в зоне проблем вы точно сможете найти идеи, которые будут закрывать стремления и желания людей. А что это значит для бизнеса? Что у вас будет продукт, который захотят люди.

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

Спасибо, что дочитали до конца, чтобы не пропустить следующую часть подписывайтесь на мой телеграм-канал

И на рассылку от dthink

22
9 комментариев

Ты меня, конечно, извини, но при чем здесь lean startup, если пост про разработку продукта? Т.е. инкрементальные изменения бизнес-модели vs. итеративная разработка на основе тестирования гипотез.

1
Ответить

Ну как зачем? А Лин стартап не является ли для многих моделью запуска продукта? Делаю МВП на основе идеи и пошел ее тестить. все заточено на скорость. А правильно ли это? Про это мои размышления в статье.

Ответить

Пространство проблем звучит интересно 💭

1
Ответить

важно уметь в нем бывать

Ответить