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