Сразу пример: команда разрабатывает приложение для управления личными финансами. Приложение нужно, чтобы человек отслеживал расходы, копил на цели, планировал бюджет.
Главная цель команды — повышать два показателя продукта:
- Количество активных пользователей. Обычно этот показатель считают за месяц, он называется MAU — Monthly Active Users.
- Процент людей, которые продолжают пользоваться приложением спустя какое-то время после регистрации. Эта метрика называется Retention rate.
Приложение, бесспорно, уже хорошее. Но чтобы повышать эти показатели, команда постоянно его улучшает. В какой-то момент продакт решил внедрить фичу — интеграцию с соцсетями. Идея в том, чтобы люди быстро и просто регистрировались через соцсети, копили с друзьями на совместные цели — отдых или крупные покупки, а также автоматически делили с ними расходы, например за ужин в ресторане.
И вот вопрос: стоит ли реализовывать такую фичу?
Как хороший продакт будет искать ответ на этот вопрос, разбирают эксперты WANNABE — соавторы и ведущие нашего интенсива Product Discovery:
- Ольга Звегинцева, Data PO в Smartbroker+, ex-Sberbank;
- Анастасия Сараева, продуктовый исследователь, ex-Emex.
В статье вы узнаете, что такое продуктовая гипотеза и чем она отличается от идеи, как формулировать гипотезы, приоритизировать их и какие исследования покажут, что гипотеза верна.
<<prodakty-kompanii-uchenikov>>
Что такое продуктовые гипотезы и зачем их тестировать
Когда продуктовая команда придумывает интересную идею, есть соблазн сразу же бежать внедрять её в продукт. Но есть риск, что после внедрения в бизнесе ничего не изменится — не увеличится количество пользователей, выручка не станет больше. Получается, продакт не обеспечил бизнесу дополнительную пользу и компания потратила деньги и время на разработку зря.
Так могло бы быть в нашем примере, если бы команда сразу стала делать фичу.
Чтобы сделать работу предсказуемой, нужно построить процесс работы с гипотезами. В продакт-менеджменте это называется Product Discovery: изучаем пользователей, рынок и конкурентов, на этой основе формулируем гипотезы, проверяем их и только тогда решаем, стоит внедрять фичу или нет.
[quote]
Продуктовая гипотеза — это предположение, как конкретное изменение в продукте решит проблему пользователя или улучшит определённые показатели бизнеса.
[/quote]
Правильно сформулировать и проверить гипотезу — практически ключевой этап в процессе внедрения улучшений в продукте. Само название процесса Product Discovery предполагает, что вам нужно что-то найти, открыть (заметьте: не придумать).
В нашем примере гипотезы пока нет. Есть только идея: сделаем интеграцию с соцсетями — будет круто.
Как строится работа с продуктовыми гипотезами: алгоритм
Опытный продакт работает с гипотезами системно. Благодаря такому подходу он никогда не оказывается в ситуации, когда не знает, что делать в продукте, или делает только то, что спускают сверху.
Системный алгоритм работы с гипотезами состоит из следующих этапов:
- Сбор идей и фокусировка на более релевантных.
- Формулирование продуктовых гипотез.
- Приоритизация продуктовых гипотез.
- Проверка продуктовых гипотез.
- Эксперименты с помощью MVP — для некоторых ситуаций нужны, для других нет.
- Выводы: подтвердилась ли гипотеза, а значит, внедряем ли изменения, которые проверяли.
Этап 1. Где брать продуктовые гипотезы
Первый этап алгоритма — это сбор идей (пока ещё не гипотез). На этом этапе продакт собирает идеи из разных источников или анализирует те, что уже есть.
[example]
Ключевая ошибка на этом этапе — когда нет единой базы знаний, куда собираются идеи. В итоге они разбросаны по разным источникам. Если же база знаний есть, длительность этого этапа сильно сокращается.
Базу знаний можно организовать любым удобным способом:
- страница в Notion;
- пространство в Jira, Trello, Kaiten или другом таск-менеджере;
- документ в Google Sheets.
[/example]
Если идея окажется нерабочей, то ресурсы на её тестирование будут потрачены впустую. Поэтому к поиску идей подходят организованно: не придумывают их, а анализируют конкретные ресурсы. Чтобы от дополнений в продукте был результат, они должны решать конкретные проблемы пользователей, а не появляться из ниоткуда.
[quote]
Процесс работы с идеями такой: наблюдаем за чем-то → видим интересную закономерность → предлагаем идею.
[/quote]
[example]
Например, мы заметили, что приложением для финансов пользуются семьи, у которых общий бюджет. И если мы сделаем интеграцию, то они смогут лучше решать свои задачи, поэтому будут дольше оставаться в продукте.
[/example]
Команда выдвинула идею интегрировать финансовое приложение с соцсетями не просто так. Члены команды периодически общаются друг с другом, с отделом продаж, с руководителями, смотрят данные аналитики. Сотрудники техподдержки сообщают о проблемах и вопросах пользователей, которые часто повторяются. Продакт пользуется приложениями конкурентов и смотрит, какие решения они внедряют.
Показываем на примерах, какими ресурсами пользуется команда, чтобы искать идеи.
Пользователи:
1. Качественные и количественные исследования.
2. Каналы сбора обратной связи: (телеграм-каналы продукта, формы для сбора обратной связи на сайте, отзывы и обзоры).
3. Чаты со службой поддержки.
4. Аналитические дашборды, web-аналитика, анализ данных рекламных кампаний.
[example]
Пример 1. В форме для обратной связи люди периодически жалуются, что, когда добавляют новые транзакции, возникает ошибка и данные слетают. Приходится вводить данные заново, это раздражает. Потенциальная идея: пофиксить баг.
Пример 2. Люди часто спрашивают, как посмотреть свои расходы в одной категории за определённый период. Эта фича уже есть, но, видимо, незаметна для пользователей. Потенциальная идея: стоит изменить интерфейс.
[/example]
Внутри команды:
1. Интервью с внутренними экспертами: руководители, коллеги, акционеры, инвесторы.
2. Общение с командами поддержки, продаж, маркетинга, настроенные чаты по сбору информации от них.
3. Открытый ресурс для команды: доска, чат, канал.
4. Коммуникация с бизнес-партнёрами.
[example]
Пример 1. Инвестор хочет, чтобы продукт приносил больше прибыли. Сейчас прибыль идёт только от встроенной рекламы. Потенциальная идея: внедрить подписку с дополнительными функциями и без рекламы.
Пример 2. Маркетолог предложил сделать напоминания о регулярных платежах. Благодаря этому пользователь будет держать уведомления включёнными и можно будет присылать ему вовлекающие пуши. Это уже готовая идея для гипотезы.
[/example]
Рынок и конкуренты
1. Анализ конкурентов.
2. Бенчмаркинг.
3. Mystery shopping.
4. Интервью с внешними экспертами рынка.
[example]
Пример 1. Продакт в качестве пользователя пообщался с чат-ботом нашего приложения. Чат-бот не решил его проблему и отвечал невпопад. Потенциальная идея: переработать алгоритм работы чат-бота.
Пример 2. В приложении есть сложный онбординг. Некоторые пользователи не могут его осилить и выходят из приложения — это метрика Drop-Off Rate. У нас есть бенчмарк (ориентир), что в таких приложениях, как наше, средний уровень Drop-Off Rate в процессе сложного онбординга на уровне 30%. У нас — 45%. Это означает, что у нас что-то не так с онбордингом и нужно его улучшать.
[/example]
Ресурсов множество: если уметь их использовать, со сбором идей не будет особых проблем.
Этап 2. Как формулировать продуктовые гипотезы
Одна из идей, которую выбрал продакт, — добавить в приложение интеграцию с соцсетями. Напомним суть: пользователи смогут регистрироваться в приложении через соцсети, копить на совместные цели с друзьями и делить с ними расходы.
Допустим, продакт уже собрал базу идей. Он прикинул, какие из них точно не стоит реализовывать прямо сейчас, так как на это нет ресурсов — например, сделать интеграцию с кешбэк-сервисами и функцию распознавания чеков через камеру. Отсеял слишком мелкие вроде «перекрасить кнопку» и «поменять иконку» — он разберётся с ними позднее и, возможно, сразу пустит в прод.
В список релевантных попало несколько идей, в том числе наша. Теперь из идей нужно сформулировать гипотезы, чтобы с ними можно было работать.
Методик для формулирования гипотез много. Одна из них — SMART, её ещё используют для формулировки целей. Рассмотрим её критерии прямо на примерах нашей продуктовой гипотезы:
1. Specific (Конкретная). Гипотеза должна быть чёткой и конкретной, без двусмысленности. Все в команде должны понимать её одинаково.
2. Measurable (Измеримая). Гипотеза должна включать метрики, которые связаны с целями бизнеса. У команды должна быть возможность измерить эти метрики.
3. Achievable (Достижимая). Гипотеза должна быть реальной и выполнимой в рамках имеющихся ресурсов и времени.
4. Relevant (Актуальная). Гипотеза должна приближать компанию к достижению бизнес-целей и соответствовать стратегии.
5. Time-bound (Ограниченная во времени). Сроки для проверки гипотезы должны быть ограничены. Это может быть неделя — в случае проверки интерфейса и пары UX-тестов. А может 2–3 недели, если продакт проводит глубинные интервью. Иногда сложно точно сказать, сколько времени займёт тестирование. Однако всё равно необходимо поставить себе какие-то измеримые сроки, чтобы тестирование гипотезы всё ещё имело смысл и не растянулось на срок, когда поменяются уже и предпосылки для её тестирования.
В любом случае команда стремится сократить сроки, чтобы быстро получить результат и пойти работать над фичей. Впоследствии решение будут дополнять, главное — чтобы фича уже работала и улучшала показатели бизнеса.
Сравните две гипотезы:
Обе гипотезы вроде об одном и том же. Но когда начинаешь работать с первой, сразу возникают вопросы:
- что входит в понятие «интеграция с соцсетями»?
- сколько времени нужно будет отслеживать результаты?
- как мы поймём, подтвердилась гипотеза или нет?
- «больше людей» — это сколько?
У продуктовой команды нет никакой конкретики, она не может переложить абстрактную идею на конкретные задачи. Выходит, такая гипотеза не работает на цели бизнеса.
Вторая гипотеза сформулирована конкретно — понятно, что именно делать и какой результат мы ожидаем.
Получается, что хорошая гипотеза — это конкретное, измеримое, достижимое актуальное и ограниченное во времени предположение. Но стоит помнить, что методика SMART — это лишь инструмент, а не единственно возможный способ составления гипотез. Основная задача — составить гипотезу так, чтобы команда могла с ней работать.
[card]
Что ещё важно при составлении гипотезы
- В гипотезе должна быть только одна переменная. Иначе будет сложно отслеживать результаты и определять успешность гипотезы.
Например, если мы одновременно добавим способ регистрации через соцсети и изменим дизайн главного экрана, будет сложно понять, что из этого оказало влияние на метрики.
- «Если» и «то» должны быть прямыми причиной и следствием. Конструкции вроде «Если мы добавим новый способ оплаты, у нас вырастет Retention rate за два года на 3%» тяжеловесны и пропускают логические звенья.
За два года Retention rate действительно может вырасти, но не только из-за одной фичи. Все два года команда будет улучшать продукт и другими способами, и влияние конкретно нового способа оплаты будет невозможно отследить.
[/card]
В итоге гипотеза в нашем примере получилось такой: «Если мы сделаем интеграцию финансового приложения с соцсетями, чтобы пользователи могли регистрироваться через соцсети, копить с друзьями на совместные покупки и делить общий счёт, то в течение двух недель как минимум 30% наших активных пользователей интегрируют продукт со своими соцсетями и воспользуются хотя бы одной из функций хотя бы один раз».
<<bad-good-product>>
Этап 3. Что такое приоритизация гипотез и как её проводить
Когда команда выстроила процесс работы с гипотезами, в бэклоге всегда есть запас, который можно тестировать. Сотрудники добавляют в базу знаний свои идеи, потом команда созванивается и формулирует из них гипотезы. Но потом заниматься всеми гипотезами сразу неэффективно. Нужно их приоритизировать.
[quote]
Приоритизация продуктовых гипотез — это процесс, когда мы определяем, какие идеи или предположения тестировать в первую очередь.
[/quote]
Задача этого этапа — сделать ставку на то, какая гипотеза с большей вероятностью принесёт результат бизнесу. Интуитивный подход тут не работает: выбирать тяжело, действовать рационально тоже тяжело, тратить время на приоритизацию не хочется. Чтобы процесс шёл проще, нужны понятные 2–3 инструмента, которые можно использовать на автомате.
[quote]
Приоритизация гипотез зависит от того, за что вы отвечаете на работе. Можно приоритизировать гипотезы по ключевым метрикам вашего продукта или по KPI команды. Если вы отвечаете за деньги, приоритизируйте по деньгам; если вы увеличиваете конверсию, то приоритизируйте по прогнозируемому росту конверсии.
[/quote]
Но интуитивно выбирать очень сложно, поэтому для упрощения задачи продакты используют разные инструменты. Самый популярный инструмент — фреймворк RICE.
R — reach, или до какого количества пользователей мы «доберёмся».
I — impact, или как много эта фича значит для пользователей.
C — confidence, или уверенность в том, что эта фича принесёт успех продукту.
E — effort, или как долго эту фичу разрабатывать.
Пример
У продакта есть две гипотезы:
1) наша — про интеграцию приложения с соцсетями;
2) ещё одна — про сортировку категорий расходов по цветам вручную, благодаря которой Retention rate увеличится на 3%.
Вот как он будет их приоритизировать с помощью фреймворка RICE.
Воспользуемся формулой:
RICE score 1: (18 000 × 4 × 0,6) / 5 = 8640
RICE score 2: (2000 × 1 × 0,5) / 1 = 1000
Показатель первой гипотезы выше. Вероятно, продакт решит протестировать сначала её.
Есть и другие методы приоритизации гипотез, но они так или иначе основываются на анализе разных критериев.
Фреймворки удобные, но не нужно к ним привязываться. Бывают ситуации, когда все эти способы просто не подходят. Например, у команды нет данных о потенциальном охвате аудитории, времени реализации или влиянии на клиента. Пытаясь следовать RICE, команда будет придумывать всё это. Соответственно, приоритизировать объективно не получится.
[quote]
Анастасия Сараева
Продуктовый исследователь, ex-Emex, соавтор и ведущая интенсива «Product Discovery»
В первую очередь смотрите на показатели, важные для бизнеса. А фреймворки используйте как вспомогательный, но не обязательный инструмент.
[/quote]
Этап 4. Как проверить гипотезы: выбирайте из большого арсенала инструментов
Двигаемся дальше по алгоритму. Продакт отобрал приоритетную гипотезу и теперь будет её тестировать. В результате он поймёт, подтвердилась ли гипотеза, а значит, стоит ли вносить эти изменения в продукт.
Тестирование проводится с помощью исследований — качественных и количественных. Инструментов для проверки гипотез много:
Качественные.
- Глубинные интервью. Общаемся с пользователями один на один, чтобы углубиться в их опыт, узнать чувства и потребности. Результаты порой неочевидны, их не получить другими способами исследования. Подробнее: Большая инструкция по глубинным интервью.
- Юзабилити-тестирование. Даём отдельным пользователям продукт и наблюдаем, как они с ним взаимодействуют. Это помогает понять, работает ли всё так, как мы задумали. Подробнее: Простые исследования: юзабилити-тестирование с прототипом.
- Анализ конкурентов. Изучаем, что конкуренты сделали хорошо, какие их решения можно перенять, а какие — улучшить. Подробнее: Кому нужен анализ конкурентов и как его проводить.
- Анализ фидбэка пользователей. Собираем отзывы о нашем продукте с сайтов и из службы поддержки. Это помогает понять, где возникают проблемы и чего хотят пользователи. Подробнее: Простые исследования: анализ обратной связи, или feedback.
- Сбор обратной связи от фронт-офиса. Опрашиваем сотрудников, которые работают напрямую с клиентами. Они скажут, на что жалуются клиенты, что хвалят и что в целом думают о продукте. Подробнее: Простые исследования: сбор обратной связи от фронт-офиса.
- Мозговой штурм. Собираем в команде как можно больше идей — вообще без критики и анализа. Затем отбираем несколько из них по нужным критериям. Подробнее: Простые исследования: мозговой штурм, или brainstorm.
Количественные.
- A/B-тестирование — сюда можно включить также МВТ (многовариантное тестирование), метод многоруких бандитов и некоторые другие. Делим трафик между двумя или больше версиями продукта. Потом смотрим, какая из них приносит лучший результат. Подробнее: A/B-тестирование: как провести, пошаговый алгоритм тестов и инструменты.
- Опрос. Задаём вопросы большому количеству людей, чтобы понять, что они думают о продукте и какие у них предпочтения.
- Анализ рекламной кампании. Запускаем рекламную кампанию нового продукта или фичи. Затем оцениваем, насколько эффективно она сработала. Смотрим на охват и конверсию.
Подробнее о количественных исследованиях: Методы количественных исследований, их особенности и ошибки.
О глубинках, опросах и A/B-тестах слышали все, поэтому часто для исследований выбирают только их. Но в некоторых ситуациях они не подойдут. В тех же глубинных интервью работы как минимум недели на две, а продакту нужно получить результат как можно скорее. Поэтому не стоит сбрасывать со счетов другие исследования.
А если изменение небольшое, можно использовать ещё более быстрые способы:
- посмотреть данные аналитики и прошлые исследования;
- написать пост в телеграм-канал или сделать лендинг и посмотреть, какая у них отдача;
- найти отзывы на аналогичную фичу конкурентов;
- взять интервью у эксперта;
- проверить гипотезу сразу на практике.
[card]
Важный момент: сначала качественные исследования и только потом — количественные
Допустим, качественного исследования под рукой нет. Продакт вынужден составлять анкету для количественного исследования, исходя из собственных знаний и представлений. Но эти представления могут быть необъективными — не соответствовать тому, что думают и чувствуют пользователи. В таком случае есть большой риск потратить ресурсы бизнеса впустую — на проверку гипотезы, которая изначально была ошибочной.
Качественное же исследование позволяет погрузиться в чужое сознание и в чужой опыт. Информация, которую мы получим, будет отражать другого человека и его мнение, а не подтверждение искажений продакта, которые он, преднамеренно или нет, заложил в анкету.
Получается, оптимальная последовательность такая: сначала проводим качественное исследование, более дешёвое. Понимаем, как думает пользователь, отсеиваем ошибочные гипотезы, а ещё находим идеи, которые бы не удалось получить другим способом. И только потом уже эти объективные данные проверяем на большом количестве людей. Так до количественного исследования дойдёт меньше гипотез и они все будут потенциально рабочими.
[/card]
Итак, чтобы проверить нашу гипотезу, продакт выбрал такую последовательность:
- Глубинные интервью.
- Опрос, если глубинные интервью покажут хороший результат.
- MVP, если всё предыдущее покажет хороший результат.
1. Качественное исследование — глубинные интервью. Продакт отобрал 14 человек разного возраста и социального статуса. Критерий для отбора — люди каким-либо образом беспокоятся о состоянии своих финансов. С каждым продакт провёл один на один беседу, чтобы понять мотивации, поведение, проблемы и желания. Он задавал открытые вопросы — как про отслеживание финансов в целом, так и про пользовательский опыт в приложениях, но фокусируясь на том, что может дать ему ценность в проверке его гипотезы.
Цель глубинного интервью — не просто получить «да» или «нет», а выявить скрытые потребности и инсайты, которые сложно обнаружить другими методами для проверки гипотез.
Из глубинок продакт выяснил несколько моментов, важных для нашей фичи:
- В основном респонденты считают, что финансы — это личная тема. Её обсуждают редко, поэтому точно не хотят выкладывать свои деньги на всеобщее обозрение, даже среди близких друзей.
- Респондентам удобно заходить в приложения по номеру телефона, через Google- или Apple-аккаунты. Не так много сервисов предоставляют возможность заходить через соцсети, поэтому таким способом они почти не пользуются.
- Несколько респондентов с сомнением отнеслись к идее заходить через соцсети в приложение с данными о доходах. Это кажется не очень безопасным.
- Респонденты часто контактируют с друзьями и коллегами и сталкиваются с ситуацией, когда надо поделить расходы. Это всегда долго и неудобно. Многие очень заинтересовались функцией, которая позволит автоматически управлять совместными тратами.
[quote]
Анастасия Сараева
Продуктовый исследователь, ex-Emex, соавтор и ведущая интенсива «Product Discovery»
Если гипотеза подтверждается в 6/6; 7/8; 8/10; 9/12; 10/14; 11/16; 12/18; 13/20 интервью, то на 80% можно быть уверенным, что как минимум половина от всех пользователей подпадает под проверяемую закономерность.
В нашем случае часть гипотезы, связанная с делением расходов с друзьями, подтвердилась в 11/14 случаях. Заходить через соцсети захотели в 6/11 случаях — недостаточно, но ещё проверим в опросе.
[/quote]
2. Количественное исследование — опрос. Получается, из всех потенциальных функций, которые придумал продакт, людей заинтересовала только одна. При этом её можно реализовать даже без интеграции с соцсетями. Чтобы убедиться, что другие люди разделяют такие идеи, продакт запустил опрос. Его прошло около 300 человек.
Итог. Около 65% респондентов заинтересованы в функции автоматически делить расходы с друзьями, около 20% — регистрироваться и заходить через соцсети. Делиться своими финансовыми достижениями с друзьями готовы всего 5%.
В целом люди отнеслись к фиче положительно: в ней заинтересовано не 30%, как продакт предполагал изначально, а 65%. (Хотя, конечно, не стоит считать, что точно 65% юзеров ей воспользуются.)
Это уже отличный показатель, но фича масштабная и требует много времени, поэтому продакт перестраховывается: он проверит поведение реальных пользователей с этой фичей с помощью MVP.
Как не надо проводить исследования, или 20 способов, как их провалить
Этап 5. Что такое MVP и как с его помощью проверить гипотезы
[quote]
MVP, или minimum viable product, — это минимально жизнеспособный продукт, у которого есть базовый набор функций. Как такового целостного продукта ещё не существует, но его функции уже можно показать пользователям.
[/quote]
Цель MVP в том, чтобы быстро проверить гипотезу и получить обратную связь: подтвердилась ли она. Это поможет понять, стоит ли развивать продукт и вкладывать ресурсы в разработку.
Если сама идея продукта работает, значит, её можно постепенно усложнять, добавляя новые функции и возможности. Если действовать наоборот, начиная с разработки сложной системы, есть риск создать продукт со множеством функций, которые никому не нужны.
[quote]
Ольга Звегинцева
Data PO в Smartbroker+, ex-Sberbank, соавтор и ведущая интенсива «Product Discovery»
MVP как способ тестирования используют не всегда в процессе Discovery. Обычно его берут либо для совсем нового продукта, либо при внедрении относительно масштабных фич — например, есть идея внедрить новый раздел, полноценная разработка которого займёт минимум полгода. Такие задачи требуют большого количества ресурсов, и если окажется, что фича или продукт невостребованы, то бизнес понесёт убытки.
Если фича маленькая, например добавить пару экранов или поменять какой-то небольшой элемент интерфейса, MVP не нужен.
[/quote]
В нашем случае интеграция приложения с соцсетями — довольно большая и дорогая задача, особенно учитывая то, что продакт планирует развивать эту фичу и добавлять новые функции. Поэтому безопаснее сначала её протестировать
MVP могут быть низкой и высокой степени проработки — оба варианта нужны и используются в зависимости от поставленных задач.
MVP Low-fidelity (низкая степень проработки). Такой MVP используют, когда хотят проверить спрос и собрать первые впечатления с целевой аудитории. Ещё — чтобы найти эту целевую аудиторию.
- Видеообъяснение продукта — это простое видео, в котором вы объясняете, как бы работал ваш продукт, какие у него будут функции и почему он обладает ценностью для клиента.
- Лендинг, или посадочная страница, — это веб-страница, на которой вы объясняете суть продукта. Лендинг даёт информацию, сколько пользователей показали, что заинтересованы: например, зарегистрировались в листе ожидания или нажали на кнопку «Хочу такой сервис».
- Презентация, где вы описываете продукт для потенциальных клиентов.
В совокупности с этими вариантами запускают рекламные кампании — с помощью Facebook, ВК, Google AdWords или иных площадок. Это помогает узнать о представителях потенциальной аудитории — сколько им лет, где они живут и так далее, а также оценить заинтересованность в самой концепции продукта.
[example]
Один из примеров MVP Low-fidelity — Dropbox. Его основатели, Дрю Хьюстон и Араш Фирдоуси, не хотели сразу разрабатывать сложное ПО. Сначала нужно было проверить, насколько люди заинтересованы в облачном сервисе. Они создали MVP — 5-минутное видео, где Дрю показал, как управляет одними и теми же файлами с разных устройств.
За одну ночь число подписчиков в листе ожидания Dropbox выросло с 5000 до 75 000. И только тогда, убедившись в востребованности, основатели начали разрабатывать продукт.
[/example]
MVP High-fidelity (высокая степень проработки). Такой MVP нужен, чтобы продакт понял, сколько клиент готов заплатить. А ещё чтобы найти первых покупателей и получить фидбэк от реальных юзеров продукта.
- MVP-имитация — нет готового продукта, и может не быть никакой функциональности совсем. Есть только имитация того, как он работает. Так продакт проверяет, нужен ли был бы этот продукт, если бы на самом деле существовал. Например, кликабельный прототип приложения: есть интерфейс, навигация, кнопки. Но при нажатии высвечиваются либо подготовленные результаты, либо сообщение, что функция ещё в разработке.
- Консьерж MVP — ручная работа продукта, обычно применяется в сервисах, которые предполагают оказание услуг. Например, пользователь хочет составить в приложении план питания по своим предпочтениям, но пока что его разрабатывает не программа, а реальные диетологи.
- Разрозненный MVP — продукт создаётся с помощью готовых инструментов, которые объединяются в единую систему. Это может быть интернет-магазин на платформе Shopify, с оплатой через PayPal и доставкой FedEx.
- MVP с одной функцией — в продукте разрабатывается главная фича, которая помогает протестировать ключевую ценность. Пример: приложение для фитнеса, где есть только одна основная функция — подсчёт калорий.
[example]
MVP High-fidelity создала компания Airbnb. В городе, где жили основатели компании, проходила конференция. Отели были дорогими, и Брайан Чески и Джо Геббиа решили сдавать в аренду надувные матрасы в своей квартире. Они предположили, что участники конференции будут платить 80$ за такую ночёвку.
Три человека действительно согласились и арендовали матрасы. Идея оказалась востребованной, и главное — Брайан и Джо не потеряли бы деньги, даже если бы она провалилась.
[/example]
Какой MVP выбрать — зависит от продукта, ресурсов и желаний вашей команды. В нашем случае команда сделала MVP-имитацию продукта. На каждую фичу внутри приложения появились экраны — без «начинки», только с визуализацией.
Например, один из экранов — регистрация и вход в приложение. На нём стали отображаться иконки соцсетей. Люди, которые нажимали на них, чтобы зарегистрироваться или войти этим способом, видели поп-ап: «Эта функция пока в разработке, но скоро станет доступной». Так продуктовая команда проанализировала не только количество заинтересованных людей, но и соцсети, которые они предпочли.
Помимо экрана регистрации и логина, команда сделала несколько экранов для распределения совместных расходов — за поход в ресторан с друзьями или поездку. Функция, где пользователь делится с друзьями финансовыми достижениями, оказалась не востребована на ранних этапах, поэтому в MVP она не пошла.
Итог. Экраны отображались для всех пользователей в течение двух недель. Результаты MVP оказались похожи на те, что показал опрос. 60% пользователей пытались воспользоваться распределением совместных расходов. Попыталось зайти через соцсети больше людей, чем ожидалось, — 30%. MVP показал, что пользователям действительно интересны эти функции.
Этап 6. Выводы по гипотезам
Нам остался последний этап — выводы. Часто он же становится толчком к следующему витку алгоритма. Так произошло в нашем случае.
Гипотеза про интеграцию с соцсетями оказалась верна — как минимум 30% аудитории попыталось воспользоваться этой фичей. Продакт решил её внедрять, но точно без опции «делиться своими финансовыми достижениями», так как люди в основном не хотят этого делать.
Но случилось кое-что ещё. В процессе глубинных интервью продакт обнаружил, что пользователям неудобно самостоятельно вбивать расходы. Продакту пришла идея: добавить фичу, чтобы доходы и расходы автоматически подтягивались из приложений банков на телефоне пользователя.
Эта идея идёт в бэклог — в Google Sheets, Notion или Jira, в зависимости от того, чем пользуется команда. Дальше работа с идеей будет строиться по той же схеме, которую мы описали в статье: команда будет формулировать из идеи гипотезу, приоритизировать, проверять и снова делать выводы.
