В создании инновационного продукта очень важен validation («проверка») – построить минимально жизнеспособный продукт и посмотреть, как люди ведут себя с ним.
Важная вещь – пользоваться информацией о том, что мы знаем о пользователях, рынке и других его игроках. Чтобы команда не тратила ресурсы на создание продукт, на который нет спроса.
У пользователей есть:
Проблема 1…
Проблема 2…
Проблема 3…
На самом деле все эти проблемы – и есть дорожная карта – центральный момент в построении продукта. Если вы будете структурировать дорожную карту по проблемам юзера, она будет зависеть от проблем, которые вы должны решить на каждом этапе.
Решая эти проблемы маленькими шажками, легко проверять жизнеспособность идеи и ее востребованность для клиентов. Когда вы строите продукт, вы все время тестируете его и смотрите на эти метрики. Будут моменты, когда вы увидите, что метрики не двигаются в правильную сторону. Значит, какое-то решение, которое вы приняли, не совсем правильное. Когда люди точно понимают конечную маленькую цель, заметить ошибку гораздо проще.
Последний очень важный вопрос: «Как мы будем поймем, что решили проблемы и сделали свою работу хорошо»?
Ответ на это – понимание нашей цели и метрики, которые мы будем выбирать, чтобы измерять дошли мы до нашей цели или нет.
Например, если продолжить пример с видео, мы можем сказать: «Окей, мы сделали субтитры. Пользуются ли ими люди?».
Если пользователи стали досматривать видео до конца, потому что стали понимать язык или могли посмотреть его без звука, значит мы идем к цели. Досмотры в этом примере – одна из возможных метрик.
Еще раз важное:
- Дорожная карта состоит не из технологий, а из проблем, которые мы хотим решить.
- Все проблемы сразу не решить. Мы не будем строить идеи на каждую из проблем, которые у нас есть. Давайте начнем с проблемы номер один и посмотрим в правильном ли мы направлении идем
- Приоритезация и последовательность – проблема номер один – это очень важный момент. Мы хотим построить эти дорожную карту так, чтобы все время было больше и больше ценностей для пользователей.
4 важных принципа MVP в построении инновационного продукта
Давайте возьмем проблему. Построим минимальное решение, которое подходит для этой проблемы, начнем тестировать его вместе с пользователями. В этом важно смотреть и слушать, что получается, и делать итерации в зависимости от того, что мы увидели.
- MVP должен решать конкретную минимальную проблему, а не сразу множество проблем.
- MVP тестируют не только пользователи и тестировщики, но все люди, работающие в компании. Когда вы строите какую-то версию продукта, и отправляете ее всем, кто работает рядом с вами с просьбой: «Пожалуйста, пользуйтесь и рассказывайте о возникающих проблемах», вы сразу получаете большое количество информации о продукте еще до его взаимодействия с внешними клиентами. Тестировщики обычно просто ищут баги. Большое количество непрофессиональных тестировщиков с разным опытом и без конкретных технических знаний именно по этому продукту имеют иной взгляд и могут дать новое видение. Это отличный способ выпустить внешним пользователям продукт, близкий к MVP, но все-таки намного более сильный.
- Информация очень важна. Например, многие разработчики говорят: «Давайте не будем писать логи (отчеты) для первой версии продукта, может она и нерабочая совсем». Но на самом деле эти логи могут дать принципиально важную информацию о том, что работает и не работает в продукте. Поэтому собирать данные с самого начала очень-очень важно. Они помогут сделать вывод, решаете ли вы проблему или нет, а также подскажут, какие метрики нужно измерять на следующих этапах. Особенно важно собирать информацию от пользователей, потому что то, что люди говорят, и то, что они делают, часто различается между собой. Ваши клиенты могут рассказывать о своем опыте работы с продуктом, но их конкретные действия, нажатия кнопок и другие факты могут сказать гораздо больше.
- Важно уметь говорить «нет» и останавливаться. Мы говорим о том, что будем строить минимальную версию, которая решит главную проблему. Но в процессе начинаем навешивать на продукт дополнительные фишки, кажущиеся важными. В конце концов это приводит к неэффективной трате ресурсов и тому, что на построение продукта уходит гораздо больше времени, чем нужно.
Очень важно приоритезировать функции и не забывать, что главная цель – не готовый продукт, а минимальная версия, чтобы понять движемся ли мы в правильном направлении или нет.
Провалы – важная часть построения продукта
Кажется, зачем вообще говорить об этом, если мы хотим построить хороший, успешный, инновационный продукт.
Но инновации – всегда тяжелый процесс с большим количеством идей, неизвестности и тестов. И если все ваши идеи оказываются рабочими, нет ни одной пустой, высока вероятность, что вы делаете в своей работе недостаточно.
Провалы – часть жизни и часть бизнеса, когда вы пробуете, учитесь на этом и вырабатываете следующий этап. Раз за разом, проходя эти процессы, вы можете понять, какой продукт нужен пользователям сейчас и в будущем.
В Кремниевой долине к провалам относятся без негатива. Здесь считают, что если что-то не получается, это гораздо полезнее: есть четкое понимание что не работает, а значит можно пробовать следующие идеи. И, напротив, когда что-то получается сразу, мало кого волнует, почему это сработало, мало кто инициирует масштабные исследования на тему «почему у нас получилось». А значит пропускает огромные объемы информации, полезные для масштабирования.
Провалы дают понимание, как решать похожие проблемы или даже искать подход к абсолютно другим, новым проблемам.
В Долине поощряют исследование прошлого опыта. Это значит, что когда кто-то задумал новый проект, сначала он идет к тем, кто пытался построить что-то похожее. Поговорить, чтобы узнать, какие знания уже известны: что работает и не очень, какие идеи получили положительный отклик, а какие – критику, какие технологии оказались слишком сложными для реализации.
Провал = Знания
А точнее – способ накапливать знания, быстро их осознавать и использовать, и идти дальше. И это одна из причин, почему необходимо писать логи даже для mvp.
Новая идея -> Тест -> Идея не работает -> Причина -> Новая идея
И, конечно, на провалы и успехи стоит смотреть через призму цели.
Допустим, мы создали приложение, которым пользуются 1 млн. человек. Это успех? Возможно… Но что если на самом деле наша цель – создать приложение для 100 млн. Важно понимать цели, ожидания и то, как конкретные действия меняют отношение ожиданию.
Любое использование материалов разрешается только при указании прямой ссылки на источник.
Присоединяйтесь к
#maliktrip, чтобы увидеть, как работают и учатся в Америке.