Семь этапов создания продукта! 🚀 Полный гайд! И Вы сможете создавать продукты - хиты!

Привет всем, мои дорогие друзья! Сегодня у нас очень серьезные обучающие видео. Давайте поговорим о классическом этапе создания продукта. Но сначала давайте вспомним концепции, которые мы обсуждали в последнем видео. И ответим на маленький вопрос. Что такое продукт? Проще говоря, продукт — это все, что помогает нам решать проблемы или удовлетворять какие-то потребности. Это может быть что-то материальное. Например, хлеб или автомобиль. И с точки зрения пользователей, продукт — это то, что помогает вам решить вашу проблему. А с точки зрения бизнесмена, продукт дает бизнесмену возможность получить прибыль за счет решения вашей проблемы. И, в принципе, это не новость. И в мире существует огромное количество способов создания продуктов. И все они нацелены на разные аспекты. Например, есть методология дизайн-мышления, которая особенно фокусируется на понимании человеческих потребностей. Там особое внимание уделяется эмпатии, инновациям и поиску скрытых потребностей. Или, например, есть другая методология — lean startup, которая позволяет как можно быстрее тестировать продуктовые гипотезы с помощью минимально жизнеспособного продукта, когда охват очень ограничен, и быстро собирать обратную связь и быстро адаптироваться к рынку. Мы поговорим о классическом этапе создания продукта. Почему он? Потому что это самый простой способ объяснить, как все работает, и как это должно работать, без всякой ненужной магии или операционных сложностей. Сегодня существует семь основных этапов. Осознание потребностей, генерация идей, тестирование гипотез, проектирование видов выходов, создание минимально жизнеспособных продуктов для выхода на рынок и процесс постоянного совершенствования. Иногда эти шаги могут быть детализированы или взаимозаменяемы. Это совершенно нормально. Главное — пройти весь этот цикл от начала до конца, или попытаться его пройти. Давайте начнем с осознания потребности. Независимо от того, какой продукт вы создаете, клиент всегда находится в центре. Это не просто абстрактный покупатель, а реальный человек или организация, у которых есть конкретная проблема, и решения, которые стоят им определенной суммы денег. Клиенты не тратят свои деньги просто так. Они платят, чтобы избавиться от боли или проблемы. Если мы не сможем четко понять эту боль и не осознаем, что именно беспокоит этого человека, наш продукт будет бесполезен. Он не решит реальных проблем, и, следовательно, останется без спроса. Никто не захочет платить за него деньги. Что обычно происходит с такими продуктами? Есть сайт в Америке, который является виртуальным кладбищем стартапов или продуктов, где вы можете увидеть все созданные продукты, и у них не было никакой проблемы, и они там перечислены. Именно поэтому этап создания потребностей считается чрезвычайно важным. Здесь необходимо как можно глубже погрузиться в проблему клиента. И на этом этапе формируются основные документы. Первое — это миссия и видение. Миссия отвечает на вопрос: зачем мы вообще создаем этот продукт? Это как внутренний путеводный свет для команды. Миссия — это не только про деньги, а про смысл и цель, а видение — это взгляд в будущее, конкретная картина того, как миссия будет достигнута через 5, 10 и даже 20 лет. Эти ориентиры помогают не заблудиться в многообразии возможных решений. Если у вас есть новая идея, вы можете сразу же проверить ее на соответствие миссии и видению компании. Если она совпадает, идите и играйте с ней дальше. Если нет, отложите ее. Или откажитесь от нее совсем. Например, текущая миссия Google — организовать мировую информацию и сделать ее общедоступной и полезной. На самом деле, способов может быть много. От карт до инновационного хранения данных на ДНК. Однако их видение продукта — создать цифровую экосистему, где любая информация будет мгновенно доступна. И именно из этого видения родились поисковые сервисы, заметки, синхронизация, умные предложения и многое другое. То есть, миссия — это общее, а видение продукта — это конкретное, чего мы должны достичь в определенное время. Как только боль клиента четко понята, начинается этап формирования верхнего уровня карты рождения. То есть, некоторые шаги, которые мы предпримем, чтобы туда добраться. На этом этапе не стоит делать слишком много деталей. Еще не проверено достаточно гипотез, но вы должны определить основные блоки работы по кварталам или годам, как будет удобнее вашей команде или партнерам, или инвесторам, к которым вы пойдете. И, наконец, следующий важный шаг — это создание документа под названием MRD, или документ требований к рынку. Это основной документ, который суммирует все, что вы узнали и осознали на этом этапе. MRD содержит документы, которые мы обсуждали. И, кроме того, это еще и анализ рынка, и он обычно рассчитывается в деньгах, чтобы понять, сколько денег вообще есть на рынке. Целевая аудитория, для которой вы конкретно создаете продукт. Например, банки в России недавно начали создавать огромное количество продуктов специально для малого бизнеса, который пользуется сетью OSN. Это именно целевая аудитория. Предприниматели, которые находятся в OSN. Также есть конкурентный анализ, чтобы понять наше положение относительно конкурентов. Уникальное торговое предложение, чтобы понять, почему клиент должен купить наш продукт, и что отличает нас от других. И самое главное — как продукт будет генерировать доход. Существует огромное количество моделей, например, единоразовая покупка. Мы покупаем смартфон, мебель, регулярные платежи, например, Adop, и Netflix, модель Premium, и некоторые базовые функции бесплатны, а затем что-то продается за дополнительные деньги. Например, Zoom, Trello. Генерация идей. Поскольку у нас уже есть осознанная проблема, важно на этом этапе понять, как именно мы будем ее решать. Иногда бывает так, что решение приходит сразу и интуитивно понятно, что нужно делать. А иногда вариантов очень много. Или наоборот, кажется, что ни один из них не работает. Тогда наша задача — собрать недостающую информацию. Например, можно вернуться к пользователям и изучить, что делают конкуренты, какие решения уже есть на рынке, что действительно работает благодаря этому, а что нет. Обсуждения внутри команды также очень помогают. Например, один из эффективных способов — организовать сессию мозгового штурма. Соберите мнения, а затем выложите все, что приходит в голову. Главное — не пытаться сразу выбрать лучшее. Наоборот, соберите как можно больше вариантов и выложите их все. Не вычеркивая ничего. Чем шире список, тем больше шансов найти сильное решение на последующих этапах. Цель этого этапа — получить набор идей и выбрать из них те, которые действительно могут удовлетворить потребность. Но очень важно, когда вы сейчас получаете список, начать приоритизировать здесь. Например, идеи всегда должны быть ранжированы по приоритету, исходя из важности, реализуемости и потенциального влияния. И иногда идеи настолько сильны, что приходится пересматривать видение и дорожную карту. Это совершенно нормально. Если у вас есть идея, которая полностью меняет вашу игру или стратегию, вы должны ее учесть и быть максимально гибкими. Давайте посмотрим на несколько примеров. У нас есть проблема. Пользователи теряют интерес к платформе. Какие идеи могут быть здесь? Например, можно создать персонализированные рекомендации, систему достижений, челленджи или даже улучшения контента. Если проблема в том, что сотрудники тратят огромное количество энергии на повторяющиеся задачи, вы можете подумать об автоматизации. От каких-то шаблонов электронной почты до автоматически заполняемых оповещений. Что угодно. Идеи могут быть любыми. Главное, чтобы ваша идея решала реальную проблему, которую вы осознали на предыдущем шаге. Получив список образов и идей, мы переходим к следующему шагу. На этапе тестирования гипотез мы проверяем. И наша цель — оценить наши идеи и протестировать их, если это возможно. Потому что реализация всего подряд означает сжигание ресурсов, времени и денег, которых у команды и так нет. Важный вопрос. В чем разница между идеей и гипотезой? Идея — это что-то общее и абстрактное. Это как вдохновение. Оно пришло мне в голову, поэтому кажется интересным. Например, давайте добавим персонализированные рекомендации для пользователей. Звучит здорово, хорошо. Но чего именно мы хотим этим добиться? Неясно. Гипотеза — это что-то более реальное и измеримое. Это конкретное предположение, которое можно проверить. Оно обычно формулируется в формате. Если мы сделаем X, то получим Y. Например, если мы добавим блог с персонализированными рекомендациями, время, которое пользователь проводит на платформе, увеличится на 20%. Это гипотеза. Главное отличие между нами — в проверяемости. Идею нельзя проверить напрямую. А гипотезу можно, потому что критерий успеха определен. Можно выбрать метод тестирования. И тогда мы увидим, работает это или нет. То есть, это можно как-то оценить. Гипотезы можно тестировать различными способами. И это могут быть количественные опросы, например, на 3000 человек. Или качественные интервью с несколькими клиентами. Можно собрать фокус-группу, и можно провести тест на ней, показать двум разным группам два интерфейса и сравнить путь наших пользователей. Методов очень много. Главное, что в итоге мы получаем список гипотез, которые были протестированы и отсортированы по важности. То, что находится вверху нашего списка, — это то, над чем мы будем работать в первую очередь. А то, что ниже, не имеет приоритета. Возможно, оно вообще не реализуется. И на этом этапе мы также подходим к одному из основных документов разработки продукта. Документы требований к продукту или Paird. Важно не путать этот документ Paird с MRD, который был на этапе осознания потребностей. MRD больше касается рынка. Он описывает потребности, сегменты, конкурентов. В Paird речь идет о самом продукте. Что мы делаем, как он будет работать, для кого и зачем. Пользовательские сценарии предоставляются в Paird, если они уже готовы. Ссылки на прототипы. И очень важный, но часто упускаемый момент, что команда не делает это. Это позволяет нам избежать раздувания масштаба и сохранять фокус на том, что для нас является приоритетом. Теперь, когда мы протестировали основные продуктовые гипотезы, команда понимает, что стоит разрабатывать. И теперь нам нужно подумать, как это сделать. Мы переходим к дизайну и прототипированию. Это этап, на котором бумажные гипотезы превращаются в какие-то живые образы, к которым можно уже начать прикасаться. Почему это важно? Потому что почти 90% информации воспринимается визуально. Даже самый подробный текст с техническими спецификациями не даст нам такого понимания, какое даст визуальный прототип. Первое, что мы делаем, это рисуем какие-то наброски или каркасы. На бумаге или в цифровом редакторе мы рисуем основные блоки. Где будет кнопка, где будет информационное окно, как наш пользователь, наш клиент, будет перемещаться с одного экрана на другой. А затем все эти рисунки становятся рабочими прототипами. Это значит, что вы можете их уже трогать. Например, нажимать на кнопку в интерфейсе, видеть, как меняются экраны, и убеждаться, что все логично и действительно удобно. И одновременно мы думаем о стиле. Мы выбираем шрифты, цветовую схему, общее настроение продукта, как мы хотим, чтобы он выглядел. Например, строгим, дружелюбным, инновационным, все это имеет значение. И это можно увидеть именно на этапе прототипирования. Если вы создаете физическое устройство, например, то на этом этапе вы работаете над его формой, используемыми материалами, удобством использования, как устройство будет лежать в руке, насколько удобно будет нажимать на кнопки, или будет ли оно шершавым или гладким. Главное, что мы тестируем сценарии взаимодействия, а не просто отдельные экраны, а полные пути пользователя. От запуска приложения или открытия коробки до включения устройства и выполнения задач. Всегда помните два важных правила. Дизайн должен показывать основные моменты, но не отвлекать мелочами, и не нужно перегружать, это еще не финальный продукт. Важно продумать все шаги, которые делает пользователь, от начала до конца, например, что произойдет, если он захочет выйти или отменить какое-то действие. И благодаря такому подходу мы получаем своего рода прототип, который затем можем превратить в минимально жизнеспособный продукт. MVP — это минимально жизнеспособный продукт. Почему этот этап так важен? Потому что на этом этапе вы тестируете свою основную идею, которую вы пропустили через гипотезу, и которую вы рассматривали в прототипах в реальных условиях на реальном рынке. MVP — это продукт, который имеет минимальный набор функций, достаточный для его запуска и получения обратной связи. Зачем это делать? Чтобы быстро понять, действительно ли ваш продукт нужен пользователям, и стоит ли его дальше развивать, или вы идете не в ту сторону. Одна из распространенных ошибок, которую допускают команды, — это добавление слишком большого количества функций, что приводит к затягиванию сроков, потере фокуса и слишком позднему получению ценной обратной связи от клиентов. Вместо этого лучше задать себе такой вопрос. Какие проблемы решает ваш продукт сейчас? Например, мы можем взять службу доставки. Для запуска MVP будет достаточно регистрации, оформления заказа, оплаты и отслеживания доставки. Все остальное уходит в следующий релиз. Но, в целом, не всегда важно реализовывать продукт; есть и другие форматы MVP. Например, можно создать простую посадочную страницу и запустить ее в интернете. Это то, что когда-то сделала служба хранения файлов Dropbox: они сделали видео. Или, например, есть еще MVP-консьерж-сервис. Вы можете вручную выполнять какие-то функции, которые потом будут автоматизированы. Вам не нужно тратить деньги на разработку, но когда клиенты думают, что это реальный продукт, вы тестируете спрос на него. И есть еще один важный момент, который не стоит забывать. Минимально жизнеспособный продукт — это не только базовая функциональность, но и продукт должен быть надежным, удобным и привлекательным внешне. Лучше сделать минимальный набор функций, но чтобы каждый элемент работал и выглядел законченным. Это очень-очень важно. И, пожалуйста, постарайтесь собрать как можно больше данных, готовы ли люди покупать ваш продукт в будущем. Какова ценность продукта? Но как насчет рынков, нужны ли они? Есть ли что-то, что нужно улучшить или нет? Это ли та дорожная карта, которую хотят видеть ваши клиенты? Или им действительно нужно что-то другое? На этапе MVP, как и на предыдущих этапах, многое меняется. Если вы это понимаете, вы можете реализовать одну идею, протестировать одну гипотезу, и на самом деле получить совершенно другое. Выход на рынок — это этап, когда продукт уже находится в финальном состоянии. Основная функциональность готова. Основная механика протестирована, и MVP уже доказал свою жизнеспособность. Основная функциональность была протестирована в этом MVP. И здесь важно, чтобы вы выбрали правильную стратегию выхода на рынок. Создать полноценную маркетинговую кампанию для вашей компании или провести бета-запуск для нескольких клиентов, а затем подумать, как масштабировать ее дальше. Как вы будете работать с вашими первыми клиентами? Нужны ли им бонусы и персональные предложения, или достаточно будет просто подписать стандартный договор с клиентом? Все это нужно продумать на этом этапе. И важно правильно собирать метрики. Как будет происходить конверсия в регистрацию и оплату? Какую пожизненную ценность принесет вам ваш клиент? Эти цифры помогут вам понять, как работает ваша стратегия, где вам нужно усилить маркетинг, и какие функции вам следует развивать дальше. И, как результат, именно для этих вторых функций, которые не являются основными, вы будете корректировать свою дорожную карту. И вы будете строить планы на второй, третий и последующие релизы. Вы будете трансформировать функции, а затем думать, что с ними делать. И, наконец, мы подошли к финальному этапу цикла постоянного совершенствования. Что это значит? Когда продукт живет своей жизнью, приходят пользователи, оставляют отзывы, рынок меняется, важно не стоять на месте, а делать хоть что-то. Ваша задача — постоянно реагировать на новые условия. Добавлять или обновлять функции продукта. Улучшать качество обслуживания. Исправлять ошибки быстрее. И этот процесс называется процессом постоянного совершенствования. Почему? Потому что вы входите в этот своего рода цикл. Другими словами, вы вышли на рынок, затем получили новую информацию, затем вернулись к исследованиям. Затем вы создаете гипотезы, тестируете их, вносите в них коррективы, проектируете прототипы, внедряете их в продукт, получаете больше информации, а затем снова проходите этот цикл. И, кстати, на этом этапе есть отличный способ мотивировать команду. Появляется эта реальная история пользователей. Например, вы идете к каким-то клиентам, затем идете к команде, затем говорите команде: посмотрите, что хочет этот клиент. Нам нужно реализовать эту функцию или внести такие коррективы. Эти изменения улучшат клиентский опыт и помогут ему по-другому показать функциональность. То есть, лучше решить проблему. Люди становятся мотивированными, и это хорошо для всех, как для команды, так и для клиента. И в заключение я хочу сказать вам цитату. Чтобы изменить мир, сначала нужно привести в порядок свои мысли. Главное, что я хочу вам сказать, — это то, что создание продукта — это не хаотичная цепочка действий, а четкая цепочка, где каждый шаг приносит ценность. Желаю вам вдохновения и профессионального роста. Спасибо всем, кто посмотрел это видео. До свидания, до свидания.