Как работать с гипотезами и прототипами в продуктовой команде

Как работать с гипотезами и прототипами в продуктовой команде

25 марта 2021

  • Автор: Егор Кургузов

  • Сложность: норм

  • Время: 9 мин

Чтобы узнать на ранней стадии продукта, какая фича принесет больше ценности, не надо «гадать на кофейной гуще». Продакт формирует гипотезы, а потом проверяет их с помощью прототипов. Попросили Егора Кургузова, Head of Product в Hurma, и спикера курсов  UX Matters и Product Unit, поделиться опытом, как продакту работать с дизайном. 

Привет, меня зовут Егор. За 7 лет в продуктовом менеджменте я успел поработать в компаниях разного направления: от Concepter: hardware&consumer electronics с продажами IT-девайсов по всему миру до выпуска софта для автомобилей с длительным циклом разработки и валидации гипотез на драйверах в CloudMade.

Сейчас мы с командой Hurma развиваем умную HRM-систему, а в Custle — работаем над созданием маркетплейса для индустрии кастинга актеров и моделей. 

Гипотезы и MVP 

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

Для проверки этих гипотез существует куча разных опций. Если мы говорим про какие-то user-facing вещи, то их можно проверять прототипами, выявлять, действительно ли гипотеза сработала. Такие прототипы менеджер может делать вместе с дизайнером.

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

Minimum Viable Product — это совокупность ценностей, которые мы доставляем пользователям. Эрик Райс, автор книги Lean Startup, называет MVP такую версию продукта, которая позволяет собрать максимальное количество полезных сведений с минимальными усилиями.

MVP должно соответствовать двум основным критериям:

  1. Иметь ценность для пользователей. Узнать реальные потребности людей нам помогает правильная работа с гипотезами. 
  2. Генерировать фидбек. Для этого нужно максимально быстро деливирить MVP на рынок.

На этапе Minimum Viable Product еще не стоит вопрос о техническом совершенстве или поддержке миллионов пользователей: мы фокусируемся на ценности и на фидбеке. 

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

Как отсеивать гипотезы

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

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

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

Гипотезы и прототипы 1

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

Более эффективный подход на рисунке справа: мы действуем разного рода экспериментами, итерациями. Это позволяет без высоких капиталовложений проверять гипотезы, откатываться назад, если все плохо и двигаться дальше, когда все хорошо. На рисунке видно, что компания могла уже 5 раз запивотить продукт и, в итоге сделать то, что действительно нужно людям (прим. ред. PIVOT – изменение курса движения стартапа с целью протестировать новое направление развития). 

Поэтому наша задача — двигаться маленькими шагами, короткими итерациями.

ProductMan

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

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

Гипотезы и прототипы 2

Матрицы для приоритизации гипотез

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

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

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

В идеале, стикеры с гипотезами должны мигрировать по матрице, если процесс работы с гипотезами выстроен в более-менее стабильном виде. 

Для наглядности приведу пример гипотезы с low uncertainty:
Когда-то мы консультировали продукт в окологосударственном секторе. И там была низкая степень неопределенности того, что рынок коррумпированный — мы точно знали о бюрократии и коррупции, это был просто факт. 

Зная об этом ограничении, мы добавляли больше секьюрности в продукт: делали двойные и тройные верификации. А в показателях «высокой неопределенности» у нас был другой фактор: насколько продукт нужен потребителям и получится ли перевести в онлайн офлайновую сферу. Чтобы снизить неопределенность, мы дробили гипотезу на конкретные таргет-сегменты, географии, и уже после этого проверяли их one by one.

 Assumptions validation flow

Гипотезы и прототипы 3

Проверка и валидация гипотез сводится к линейному процессу. Первые два пункта — input, и на месте бизнес модели может быть почти любой продуктовый артефакт: Value Prop, Customer Journey Map, просто сырые инсайты из интервью, все зависит от стадии жизни продукта.
И если собрать весь флоу в пошаговую инструкцию, то мы получим что-то такое. Хорошо работает для внутренней innovation lab, когда есть постоянная цель прорабатывать довольно много новых бизнес моделей. 

  1. Define biz models.
  2. Evaluate biz models.
  3. Prioritize the hypotheses — тоже input, который выльется в гипотезы, сформулированные и расставленные в порядке приоритетности.
  4. Build an action plan с расписанными экспериментами для проверки наших гипотез. Форма action plan может быть любой. Я закидываю все в Miro и после появления моей матрицы, стрелочками соединяю другие карточки, которые подразумевают эксперименты. 
  5. Go out of the building. Наша задача здесь — получить реальные данные извне, а для этого нужно провести аналитику или заделиверить что-то на рынок. Например, скрипт интервью — заделиверили вопросы на рынок, и получили в ответ реальный опыт и кейсы для будущей разработки. Либо заделиверили кликабельный прототип малой группе пользователей: взяли 10 early adopters, которые любят и поддерживают нас, показали им как выглядит apk, люди покликали — и стало ясно, что их проблемы не решаются.
    Возвращаемся с полученными инсайтами, переделываем — и снова выходим. Соль в том, что мы не начинаем разработку, пока не подкрепим ее реальными данными. 
  6. Evaluate the results. Любой эксперимент должен подразумевать какой-то результат. Если говорить о валидации позиционирования (например, с разными баннерами на Facebook), то success metric здесь — цена имейла. Ставим себе определенный порог ожидания: например, не больше 2 долларов за имейл и дальше смотрим. Первый вариант баннера — провалил ожидания, получилось 5-6 долларов за имейл, а второй и третий — превзошли: стоимость вышла меньше 2 долларов. Здесь, конечно, важна репрезентативность выборки и охват нужного количества людей для проверки. 

Прототипы: как research перетекает в дизайн

Гипотезы и прототипы 4
Модель Double Diamond

Гипотезы есть всегда, их постоянно нужно валидировать, просто набор гипотез может трансформироваться и видоизменяться. Мы расширяем этот набор на уровне research: собираем на интервью возможные опции, выявляем проблемы, которые могли бы покрыть. Дальше — сужаемся до конкретной потребности или pain point, который мы и будем решать.

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

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

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

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

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

Sketch

На раннем этапе можно просто нарисовать что-то на бумаге. Если говорить именно о работе менеджера с дизайном и продуктовой командой в целом, раннее тестирование дает результат уже на самом начальном этапе. Это как раз самое важное в lean: мы сразу (a.k.a. «очень быстро»)  что-то строим, измеряем и учимся. 

Мне очень нравится в этом плане кейс Яндекс.Такси. Когда ребята делали навигатор у себя в приложении, они валидировали user experience навигационных инструкций с помощью бумаги. 

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

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

Благодаря этому, они узнали на какой дистанции и когда сообщать о повороте, как должен выглядеть дизайн поворота, в каком месте интерфейса располагать этот элемент и пр. Это пример прототипа очень низкой детализации (low-fidelity), который позволяет провалидировать опыт пользователей. 

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

Wireframe

Это фактически макет без дизайна: одни кружочки, квадраты и текст. Для wireframe — чем проще, тем лучше. Именно так учат прототипировать в топовых бизнес-школах. Дизайнер может посмотреть на wireframe и прикинуть: на странице должны быть вот такие элементы, понятно. А уже как их отобразить, дизайнер  определит сам. 

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

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

Mockup и Prototype 

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

Mockup выглядит как реальный интерфейс, только некликабельный. 

Prototype  — проектируют в приложении типа InVision, чтобы можно было покликать и проанализировать полноценное поведение пользователей. 

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

Например, когда мы переходим на уровень product market fit и пытаемся зарелизить продукт в App Store. Конечно, хочется быстрее сделать зрелый продукт, довести до финала, чтобы все его скачивали, но… 

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

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

Мы можем постоянно откладывать проверку финальной гипотезы, потому что она упирается в разработку и нужно потратить еще два месяца. Обсудите с командой, возможно это все можно «замокать», или сэмулировать поведение пользователей за счет какой-то библиотеки Google (или чего другого, разработчики знают). 

Переиспользуйте вещи. Даже в рамках одной компании часто есть несколько продуктов, допустим, все для e-commerce. Если мы придумали новый маркетплейс для конкретного рынка — перепродавать одноразовую посуду, то чтобы проверить нашу гипотезу, можно взять подпродукты или компоненты из других команд. Они наверняка уже делали что-то похожее и у них есть какие-то building blocks, API, дата-сеты, поэтому подключайте к прототипированию и свою команду, и коммуницируйте свои цели наружу. 

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

Можно также показать такой прототип пользователям, чтобы они прошли по user flow, попробовали найти что-то в интерфейсе. Для такого исследования может быть вполне достаточно базового вида: квадратики и текст. Вы поймете, ориентируется человек в нарисованном интерфейсе или ничего не понимает, путается в кривом флоу и упирается в логические тупики. 

Почти все прототипирование сводится к исследованию user experience. Поэтому всегда апеллируйте к реальным данным. Не используйте прототипы, чтобы просто отдать их дизайнеру как ТЗ. Делайте их для того, чтобы получить знания о пользователях. Любая итерация прототипов должна доставлять вам какое-то знание, а дальше вы адаптируете свой роадмап/беклог/требования (подчеркнуть нужное), согласно новым данным. 

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

И не забывайте работать с гипотезами! Пока вы делаете это осознанно — вы не заблудитесь во всех этих множественных валидациях и экспериментах. 

Егор Кургузов

Head of Product в Hurma и Co-founder & CEO в Custle, спикер курса UX Matters. Более 7 лет опыта в сфере Product Management. Опыт запуска 2 своих продуктов: ML маркетплейс Custle и ed-tech платформа Casers. Работал над B2B и В2С software и hardware продуктами.