[Управление разработкой, Развитие стартапа, Управление продуктом, Карьера в IT-индустрии] Создание программного продукта и управление его развитием. От реализации идей — к проверке гипотез
Автор
Сообщение
news_bot ®
Стаж: 6 лет 4 месяца
Сообщений: 27286
Привет, Хабр! Мы продолжаем говорить о продакт-менеджменте из прошедшего курса и этот пост посвящен работе с гипотезами, которые вы хотите реализовать при разработке программного продукта. Многие хорошие идеи “не взлетают”, потому что не соответствуют потребностям рынка, и сегодня мы рассмотрим способы поиска того, что нужно делать. В этом посте вы найдете способы анализа рынка, правила выбора источники информации о требованиях к продукту, методы проверки гипотез, а также полезный опыт одного бренда с мировым именем.
Оглавление курса
1. Роль менеджера по продукту и фреймворк
2. Сегментирование рынка и конкурентный анализ
3. Пользовательские персоны
4. Проверка гипотез < — Вы здесь
— Продолжение следует
Продуктовые гипотезы
В прошлых постах мы говорили о пользовательских персонаж и рыночной нише. Но когда ниша уже выбрана, стратегия для борьбы с конкурентами определена, казалось бы, нужно воплощать в жизнь все существующие идеи. Так вот, одна из очень важных обязанностей менеджера по продукту — превращение в гипотезы всех светлых идей, которые возникают в головах руководства и специалистов… да и в своей собственной.
Гипотезы отличаются от простых идей тем, что их, как известно, нужно проверять. И для этого есть несколько эффективных методов:
- Сделать сайт-лендинг. Распространить информацию, получить обратную связь от рынка. Кстати, именно так мы презентовали наш курс лекций и проверяли, о чем хотят поговорить слушатели
- Провести онлайн-опросы. Сделать это можно в виде форм Google или, например, используя SurveyMonkey. Опросы позволяют понять, что хотят видеть клиенты, какие качества они ожидают от продукта. Наполнение нашего курса пришлось немного поменять после анализа анкетирования
- Запустить телефонные опросы. Этот метод может показаться устаревшим, но он очень даже неплохо работает, если речь идет не о холодных звонках, а о потенциальных партнерах и клиенты, друзьях и коллегах. Такой подход позволяет получить быстрый и эмоционально насыщенный фидбек. И при начальной проработке продукта определенно стоит сделать 15-20 звонков заинтересованным людям
- Запланировать личные встречи. Чашечка кофе и 15-20 минут непринужденной беседы помогают глубоко погрузиться в вопрос. Обсуждение на встречах особенно важно, если вы создаете продукт не для массового рынка, а нечто узко специализированное, либо для B2B сегмента
- Создать и запостить видео-ролик, чтобы показать интерфейсы, рассказать о фичах нового продукта. Количество лайков и просмотров, а также содержимое комментариев помогут понять первичную реакцию пользователей. При этом интерфейс приложения, который вы показываете на видео, не обязательно должен существовать в виде рабочей программы. Достаточно интерактивного графического макета
- Послушать коллег, которые ежедневно работают с вами:
Менеджеры по продажам уже владеют живым откликом от рынка
Служба поддержки выслушивает боль и страдания клиентов
Партнеры продвигают продукт, делают промо, помогают в его обслуживании
Когда я рассказываю об этом, очень часто мне говорят о том, что в процессе валидации гипотез идею о новом продукте могут украсть. Но на самом деле идея ничего не стоит без команды, которая может ее реализовать, без реального воплощения. Идей сегодня — миллионы. Если у вас нет идеи, можно легко найти подходящую на Reddit и попробовать построить на ее базе продукт.
Защищать нужно технологии, решения, продукты, в конечном счете. Следует получить патент на детали, на конкретные схемы и способы реализации. Но сами идеи, наоборот, нужно обсуждать. Только так можно создать успешный продукт.
Пример DropBox
Кстати, именно так и поступали многие компании, продукты которых мы используем сегодня, и которые сформировали свои ниши на рынке. Взять, например, DropBox. Вряд ли кто-то будет спорить, что это реально успешная компания. Ее рыночная стоимость исчисляется миллиардами.
Но более 10 лет назад будущее руководство DropBox задавалось вопросом — нужно ли все это потребителям? На тот момент на рынке уже были продукты, которые синхронизировали файлы на разных устройствах. У команды была гипотеза, что синхронизацию нужно сделать удобнее, и они просто нарисовали в видеоредакторе, как мог бы выглядеть пользовательский интерфейс продукта.
Извините, данный ресурс не поддреживается. :(
Видеоролик демонстрировал, какие могут быть возможности клонирования, сохранения версий, работы с файлами. Обратите внимание, они не написали ни строчки кода на тот момент! Но опубликованное на Reddit и на других форумах видео вызвало большой интерес. Разработчики увидели гигантской отклик, узнали, какую именно программу хотят видеть люди, какие возможности требуется реализовать для простых пользователей, не обладающих знаниями в сфере ИТ.
Нарисовать макет пользовательского интерфейса стоит в сотни раз дешевле, чем написать код, подготовить продукт и начать его продажи. DropBox было бы намного сложнее развивать, если бы разработчики узнали, чего ждут их пользователи уже после выпуска первой версии решения.
Правила работы с материалом
Когда вы собираете информацию с рынка, нужно учитывать, что весь материал — сырой. Для начала нужно разбить его на категории, структурировать. Я предпочитаю добавлять мета-данные к каждому фидбеку, чтобы знать, от кого пришел ответ, какому количеству клиентов нужны новые функции, о чем идет речь — об исправлении, добавлении, изменениях. Если не структурировать информацию, через некоторое время появится одна большая и непонятная куча данных.
Когда есть структура, можно и нужно использовать как можно больше источников. Просто подойти к менеджерам по продажам и расспросить их будет недостаточно. Необходимо также собирать мнения с форумов и из социальных сетей, запрашивать данные от маркетинга и у существующих клиентов. При этом главное — не забывать сохранить источник в метаданных.
Изучение рынка должно происходить с определенной периодичностью. В раннем фидбеке вы обязательно узнаете о проблемах, и это нормально. А пока инженеры работают над исправлениями, найдите тех людей, которым помог даже прототип или MVP, изучите опыт и профиль этих компаний. Так вы сможете найти наилучшее позиционирование для еще «сырого» продукта.
Где брать новый фидбек? Просто повторяйте сбор отзывов из тех же источников — через месяц, квартал, полгода. У людей могло поменяться мнение, проблема могла решиться, могло измениться отношение к продукту в целом. Но если негативный фидбек сохранился, нужно уделять ему пристальное внимание.
Тем не менее, я советовал бы больше проводить времени с потенциальными клиентами, а не с существующими. Как правило, потенциальным клиентам чего-то не хватает, и выяснить, чего именно — святая обязанность продакт-менеджера.
Формируя концепции новых фич, фокусируйтесь на долгосрочной стратегии. Не зацикливайтесь на функционале для одного клиента или для конкретной ситуации. Каждый раз анализируйте, будет ли востребован этот функционал через 1 год или через 5 лет? Сможет ли он пригодиться хотя бы 50% потенциальным потребителям?
Нужно ли брать новую фичу в работу?
Когда речь заходит о том, чтобы добавить продукту что-то новенькое, нужно классифицировать доработку по трем критериям:
● Feasibility — насколько просто это реализовать, сколько придется потратить сил и времени
● Importance — насколько это важно, можно ли обойтись без фичи
● Satisfaction — насколько клиент будет удовлетворен новшеством
Пересечение по всем трем зонам — значит это фича, которую точно нужно добавлять в продукт.
Позиционирование продукта
Следующая задача, которую нужно решить — это позиционирование продукта и самого бренда. Об этом мы подробно поговорим в следующем материале. Также мы в коснемся вопросов использования ресурсов и формирования портфолио. Не забудьте подписаться на наш блог, чтобы не пропустить следующую публикацию.
→ Видео-запись всех лекций курса доступна на YouTube
Лекция про проверку гипотез:
Извините, данный ресурс не поддреживается. :(
===========
Источник:
habr.com
===========
Похожие новости:
- [Учебный процесс в IT, Карьера в IT-индустрии] В США стартапы начали набирать студентов, которые оказались на карантине из-за пандемии
- [Управление персоналом, Карьера в IT-индустрии] Бесплатные образовательные курсы: бэкенд-разработка
- [Управление персоналом, Карьера в IT-индустрии, Лайфхаки для гиков, Удалённая работа] Что кроется за “проактивностью” в ИТ-вакансиях?
- [Учебный процесс в IT] Мой опыт. Онлайн-магистратура в России. МФТИ, «Технологическое предпринимательство»
- [Венчурные инвестиции, Управление e-commerce, Развитие стартапа, Управление продажами, Управление персоналом] Зачем нужны 100 000 электрофургонов Rivian и почему Amazon финансирует ИТ-курсы для учащихся из неблагополучных семей? (перевод)
- [Анализ и проектирование систем, CAD/CAM, Визуализация данных, Управление продуктом] CATIA: из истории одного проекта
- [IT-эмиграция, Карьера в IT-индустрии, Интервью, IT-компании] [Личный опыт] Amazon vs Microsoft: чем отличается процесс собеседований в крупных ИТ-компаниях
- [Беспроводные технологии, Монетизация IT-систем, Развитие стартапа, Финансы в IT, IT-компании] Инвестиции, клиенты и прибыль: история успеха выпускников первого трека «Московского акселератора»
- [Дизайн мобильных приложений, Agile, Управление продуктом, Интернет вещей, Будущее здесь] Как мы хакнули умные подушки и запустили приложение для умной спальни «Асконы»
- [Карьера в IT-индустрии] В какую сторону течёт вода?
Теги для поиска: #_upravlenie_razrabotkoj (Управление разработкой), #_razvitie_startapa (Развитие стартапа), #_upravlenie_produktom (Управление продуктом), #_karera_v_itindustrii (Карьера в IT-индустрии), #_acronis, #_mfti (МФТИ), #_product_management, #_upravlenie_produktom (управление продуктом), #_menedzher_produkta (менеджер продукта), #_proverka_gipotez (проверка гипотез), #_blog_kompanii_acronis (
Блог компании Acronis
), #_upravlenie_razrabotkoj (
Управление разработкой
), #_razvitie_startapa (
Развитие стартапа
), #_upravlenie_produktom (
Управление продуктом
), #_karera_v_itindustrii (
Карьера в IT-индустрии
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 06-Июл 23:25
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 4 месяца |
|
|
Привет, Хабр! Мы продолжаем говорить о продакт-менеджменте из прошедшего курса и этот пост посвящен работе с гипотезами, которые вы хотите реализовать при разработке программного продукта. Многие хорошие идеи “не взлетают”, потому что не соответствуют потребностям рынка, и сегодня мы рассмотрим способы поиска того, что нужно делать. В этом посте вы найдете способы анализа рынка, правила выбора источники информации о требованиях к продукту, методы проверки гипотез, а также полезный опыт одного бренда с мировым именем. Оглавление курса 1. Роль менеджера по продукту и фреймворк 2. Сегментирование рынка и конкурентный анализ 3. Пользовательские персоны 4. Проверка гипотез < — Вы здесь — Продолжение следует Продуктовые гипотезы В прошлых постах мы говорили о пользовательских персонаж и рыночной нише. Но когда ниша уже выбрана, стратегия для борьбы с конкурентами определена, казалось бы, нужно воплощать в жизнь все существующие идеи. Так вот, одна из очень важных обязанностей менеджера по продукту — превращение в гипотезы всех светлых идей, которые возникают в головах руководства и специалистов… да и в своей собственной.  Гипотезы отличаются от простых идей тем, что их, как известно, нужно проверять. И для этого есть несколько эффективных методов:
Когда я рассказываю об этом, очень часто мне говорят о том, что в процессе валидации гипотез идею о новом продукте могут украсть. Но на самом деле идея ничего не стоит без команды, которая может ее реализовать, без реального воплощения. Идей сегодня — миллионы. Если у вас нет идеи, можно легко найти подходящую на Reddit и попробовать построить на ее базе продукт.  Защищать нужно технологии, решения, продукты, в конечном счете. Следует получить патент на детали, на конкретные схемы и способы реализации. Но сами идеи, наоборот, нужно обсуждать. Только так можно создать успешный продукт. Пример DropBox Кстати, именно так и поступали многие компании, продукты которых мы используем сегодня, и которые сформировали свои ниши на рынке. Взять, например, DropBox. Вряд ли кто-то будет спорить, что это реально успешная компания. Ее рыночная стоимость исчисляется миллиардами.  Но более 10 лет назад будущее руководство DropBox задавалось вопросом — нужно ли все это потребителям? На тот момент на рынке уже были продукты, которые синхронизировали файлы на разных устройствах. У команды была гипотеза, что синхронизацию нужно сделать удобнее, и они просто нарисовали в видеоредакторе, как мог бы выглядеть пользовательский интерфейс продукта. Извините, данный ресурс не поддреживается. :( Видеоролик демонстрировал, какие могут быть возможности клонирования, сохранения версий, работы с файлами. Обратите внимание, они не написали ни строчки кода на тот момент! Но опубликованное на Reddit и на других форумах видео вызвало большой интерес. Разработчики увидели гигантской отклик, узнали, какую именно программу хотят видеть люди, какие возможности требуется реализовать для простых пользователей, не обладающих знаниями в сфере ИТ. Нарисовать макет пользовательского интерфейса стоит в сотни раз дешевле, чем написать код, подготовить продукт и начать его продажи. DropBox было бы намного сложнее развивать, если бы разработчики узнали, чего ждут их пользователи уже после выпуска первой версии решения. Правила работы с материалом Когда вы собираете информацию с рынка, нужно учитывать, что весь материал — сырой. Для начала нужно разбить его на категории, структурировать. Я предпочитаю добавлять мета-данные к каждому фидбеку, чтобы знать, от кого пришел ответ, какому количеству клиентов нужны новые функции, о чем идет речь — об исправлении, добавлении, изменениях. Если не структурировать информацию, через некоторое время появится одна большая и непонятная куча данных. Когда есть структура, можно и нужно использовать как можно больше источников. Просто подойти к менеджерам по продажам и расспросить их будет недостаточно. Необходимо также собирать мнения с форумов и из социальных сетей, запрашивать данные от маркетинга и у существующих клиентов. При этом главное — не забывать сохранить источник в метаданных.  Изучение рынка должно происходить с определенной периодичностью. В раннем фидбеке вы обязательно узнаете о проблемах, и это нормально. А пока инженеры работают над исправлениями, найдите тех людей, которым помог даже прототип или MVP, изучите опыт и профиль этих компаний. Так вы сможете найти наилучшее позиционирование для еще «сырого» продукта. Где брать новый фидбек? Просто повторяйте сбор отзывов из тех же источников — через месяц, квартал, полгода. У людей могло поменяться мнение, проблема могла решиться, могло измениться отношение к продукту в целом. Но если негативный фидбек сохранился, нужно уделять ему пристальное внимание. Тем не менее, я советовал бы больше проводить времени с потенциальными клиентами, а не с существующими. Как правило, потенциальным клиентам чего-то не хватает, и выяснить, чего именно — святая обязанность продакт-менеджера. Формируя концепции новых фич, фокусируйтесь на долгосрочной стратегии. Не зацикливайтесь на функционале для одного клиента или для конкретной ситуации. Каждый раз анализируйте, будет ли востребован этот функционал через 1 год или через 5 лет? Сможет ли он пригодиться хотя бы 50% потенциальным потребителям? Нужно ли брать новую фичу в работу? Когда речь заходит о том, чтобы добавить продукту что-то новенькое, нужно классифицировать доработку по трем критериям: ● Feasibility — насколько просто это реализовать, сколько придется потратить сил и времени ● Importance — насколько это важно, можно ли обойтись без фичи ● Satisfaction — насколько клиент будет удовлетворен новшеством Пересечение по всем трем зонам — значит это фича, которую точно нужно добавлять в продукт.  Позиционирование продукта Следующая задача, которую нужно решить — это позиционирование продукта и самого бренда. Об этом мы подробно поговорим в следующем материале. Также мы в коснемся вопросов использования ресурсов и формирования портфолио. Не забудьте подписаться на наш блог, чтобы не пропустить следующую публикацию. → Видео-запись всех лекций курса доступна на YouTube Лекция про проверку гипотез: Извините, данный ресурс не поддреживается. :( =========== Источник: habr.com =========== Похожие новости:
Блог компании Acronis ), #_upravlenie_razrabotkoj ( Управление разработкой ), #_razvitie_startapa ( Развитие стартапа ), #_upravlenie_produktom ( Управление продуктом ), #_karera_v_itindustrii ( Карьера в IT-индустрии ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 06-Июл 23:25
Часовой пояс: UTC + 5