Навык #4
Product discovery
Product discovery
Изучение потребностей клиентов для определения направления и ценности продукта
- Концепт Product Discovery
- Что такое Product discovery?
- Когда нужно discovery
- Что такое continuous discovery
- Типы product discovery
- В чем отличия discovery и delivery команд
- Состав discovery команды
- Процесс product discovery
- Методы product discovery
- Инструменты discovery
- Гипотезы для product discovery
- Общение с пользователями во время discovery
- Скорость discovery процесса
- Гайды по внедрению product discovery
- Ошибки в Discovery
- Как измерять product discovery
- Общение со стейкхолдерами во время discovery
- Опыт и примеры внедрения discovery в компаниях
- Документация Product discovery
- Ключевые личности при изучении discovery
- Discovery процессы в знаменитых компаниях
Содержание навыка:
В этом навыке: 103 источника
На полное прохождение уйдет: 1250 минут
На полное прохождение уйдет: 1250 минут
Концепт Product Discovery
Что такое Product discovery
Когда нужно Discovery
Что такое Continuous discovery
Типы discovery
Отличия Discovery и Delivery команд
Состав Discovery команды
Процесс product discovery
Методы discovery
Инструменты discovery
Гипотезы для discovery
Общение с пользователями во время discovery
Скорость discovery процесса
Гайды по внедрению product discovery
Ошибки в Discovery
Как измерять product discovery
Общение со стейкхолдерами во время discovery
Опыт и примеры внедрения discovery в компаниях
Документация product discovery
Ключевые личности при изучении discovery
Discovery процессы в знаменитых компаниях
Квиз на знание discovery
Что такое Product discovery
Когда нужно Discovery
Что такое Continuous discovery
Типы discovery
Отличия Discovery и Delivery команд
Состав Discovery команды
Процесс product discovery
Методы discovery
Инструменты discovery
Гипотезы для discovery
Общение с пользователями во время discovery
Скорость discovery процесса
Гайды по внедрению product discovery
Ошибки в Discovery
Как измерять product discovery
Общение со стейкхолдерами во время discovery
Опыт и примеры внедрения discovery в компаниях
Документация product discovery
Ключевые личности при изучении discovery
Discovery процессы в знаменитых компаниях
Квиз на знание discovery
Концепт Product Discovery
- Product discovery - это бесконечный процесс обучения тому какой продукт надо делать. Разработка продукта в свою очередь отвечает за поставку продукта.
- Очень важно включить клиента во все этапы принятия решений. Это означает, что клиент активно участвует в процессе, и их мнение и потребности учитываются при определении направления разработки продукта.
- Ключевые методы: клиентские интервью, тестирование юзабилити, A/B-тесты, проверка гипотез и другие. Эти методы помогают получить информацию о клиентах, их потребностях и предпочтениях, а также проверить гипотезы и идеи.
- Product discovery - это итерационный процесс, который стремится к постоянному улучшению продукта.
- Быстрые проверки гипотез являются важной частью процесса. Они позволяют команде оценить различные решения и собрать данные, которые помогут принять обоснованные решения о дальнейшей разработке продукта.
- Команда product discovery обычно состоит из менеджера продукта, ведущего дизайнера и ведущего разработчика.
Что такое Product discovery?
В команде product discovery выполняет следующие функции:
- Исследование пользователей: Команда проводит интервью с клиентами, наблюдает за их поведением, анализирует данные и обратную связь, чтобы лучше понять их потребности и проблемы.
- Анализ рынка: Команда изучает конкурентов, анализирует тенденции рынка и понимает, какие продукты и функции могут быть успешными и востребованными.
- Генерация идей: проводит сеансы идей и мозгового штурма, чтобы сгенерировать множество возможных решений и функций, которые могут удовлетворить потребности пользователей.
- Прототипирование и тестирование: Команда создает быстрые прототипы и проводит тестирование с пользователями, чтобы получить обратную связь и понять, какие идеи и решения наиболее эффективны.
- Принятие решений: Команда анализирует собранную информацию, обсуждает и сравнивает различные идеи и решения, чтобы определить наилучший путь развития продукта.
- Составление гипотез: Команда формулирует гипотезы о том, какие изменения или новые функции могут привести к улучшению пользовательского опыта или достижению бизнес-целей.
- Экспериментирование: Команда проводит эксперименты, чтобы проверить гипотезы и получить данные о реакции пользователей на предложенные изменения. Это может включать A/B-тестирование, опросы, пользовательские тестирования и другие методы сбора информации.
- Продуктовая стратегия: Команда использует результаты исследования и экспериментов для определения продуктовой стратегии, определения приоритетов функций и планирования будущих шагов разработки продукта.
Когда нужно discovery
Какие проблемы позволяет устранить процесс discovery:
Product discovery позволяет командам быть автономными
Product discovery - это системный способ отбора идей для разработки, поэтому вы можете положиться на систему в том, что она зарелизит на рынок проверенные идеи.
Discovery продукта помогает сосредоточиться на проблемах пользователей.
Если вы завязли в работе по части delivery, вы не можете исследовать проблемы - вы занимаетесь только решениями.
UX-исследования, UX-стратегии и практически все, что связано с UX, требуют времени на поиск. Если дать UX-дизайнеру все задачи только по части delivery, вы сильно ограничите методы, которые он может использовать.
Discovery продукта легче продать, чем "исследование".
По какой-то причине в технологических компаниях слово "исследование" может восприниматься несерьезно. Дополнительные исследования могут показаться оскорблением для руководителей, гордящихся своей идеей.
Discovery продукта способствует накоплению знаний о клиенте
Проектирование решений для неопределенного, не изученного пользователя - это все равно что проектирование с руками за спиной. То же самое можно сказать и о разработчиках, которые не понимают, что делает клиент с их кодом. Команды, которые вместе изучают клиентов, лучше справляются со своей работой.
Вы сэкономите время и деньги
Продуктовые команды, проводящие недели или месяцы за размышлениями и мало строящие, могут показаться нелогичными для культуры быстрых стартапов, в которой они существуют. Но если отбросить исследование пользователей и заниматься только разработкой, то это чревато очень большими затратами. По сути, вы ставите ставки на предположения о том, чего хотят ваши пользователи, которые могут оказаться ложными, какими бы опытными вы ни были.
Ваши продукты будут более инновационными
Благодаря тому, что мы с самого начала учитываем точку зрения клиентов, discovery продукта вдохновляет вашу команду на пересмотр собственных предположений и нестандартное мышление при принятии решений. Это не только приводит к появлению более инновационных решений, но и подтверждает, какие из ваших идей являются реальными потребностями рынка.
Вы сможете избежать проклятия знаний
Как специалисты по продуктам, мы являемся экспертами своего продукта, зная каждую деталь каждой поддерживаемой функциональности и принцип ее работы.
Но с клиентами дело обстоит иначе. Они не являются экспертами и не знают всех тонкостей нашего продукта. Это приводит к проклятию знаний, и мы начинаем страдать от предвзятости.
Product discovery позволяет командам быть автономными
Product discovery - это системный способ отбора идей для разработки, поэтому вы можете положиться на систему в том, что она зарелизит на рынок проверенные идеи.
Discovery продукта помогает сосредоточиться на проблемах пользователей.
Если вы завязли в работе по части delivery, вы не можете исследовать проблемы - вы занимаетесь только решениями.
UX-исследования, UX-стратегии и практически все, что связано с UX, требуют времени на поиск. Если дать UX-дизайнеру все задачи только по части delivery, вы сильно ограничите методы, которые он может использовать.
Discovery продукта легче продать, чем "исследование".
По какой-то причине в технологических компаниях слово "исследование" может восприниматься несерьезно. Дополнительные исследования могут показаться оскорблением для руководителей, гордящихся своей идеей.
Discovery продукта способствует накоплению знаний о клиенте
Проектирование решений для неопределенного, не изученного пользователя - это все равно что проектирование с руками за спиной. То же самое можно сказать и о разработчиках, которые не понимают, что делает клиент с их кодом. Команды, которые вместе изучают клиентов, лучше справляются со своей работой.
Вы сэкономите время и деньги
Продуктовые команды, проводящие недели или месяцы за размышлениями и мало строящие, могут показаться нелогичными для культуры быстрых стартапов, в которой они существуют. Но если отбросить исследование пользователей и заниматься только разработкой, то это чревато очень большими затратами. По сути, вы ставите ставки на предположения о том, чего хотят ваши пользователи, которые могут оказаться ложными, какими бы опытными вы ни были.
Ваши продукты будут более инновационными
Благодаря тому, что мы с самого начала учитываем точку зрения клиентов, discovery продукта вдохновляет вашу команду на пересмотр собственных предположений и нестандартное мышление при принятии решений. Это не только приводит к появлению более инновационных решений, но и подтверждает, какие из ваших идей являются реальными потребностями рынка.
Вы сможете избежать проклятия знаний
Как специалисты по продуктам, мы являемся экспертами своего продукта, зная каждую деталь каждой поддерживаемой функциональности и принцип ее работы.
Но с клиентами дело обстоит иначе. Они не являются экспертами и не знают всех тонкостей нашего продукта. Это приводит к проклятию знаний, и мы начинаем страдать от предвзятости.
Что такое continuous discovery
Задача discovery состоит не только в том, чтобы понять проблемы и создать то, что нужно людям. Речь идет также о понимании самих людей, среды, в которой они работают, способов приобретения продукта, восприятия ими ценности решения и т.д., что позволяет оптимизировать маркетинг, продажи и т.д.
42% компаний в качестве основной причины закрытия назвали "отсутствие потребности рынка".
Интересно, чем они занимались? Кому они собирались продавать? Зачем они вкладывали деньги в создание чего-либо, не определив ни рынка, который будет покупать их продукт, ни реальной рыночной потребности, которую нужно удовлетворить?
При этом лучшие команды осознают, что цифровые продукты никогда не бывают законченными. Всегда возможно проводить новые итерации и улучшать их. Facebook и Netflix никогда не будут законченными проектами.
Если бы они прекратили итерации и разработки, их догнали бы конкуренты. Например, компания Netflix начинала свою деятельность как сервис по пересылке DVD по почте, затем перешла к потоковому просмотру фильмов, а теперь создает собственные оригинальные программы.
Continuous discovery - это процесс проведения небольших исследований продуктовой команды в виде еженедельных взаимодействий с клиентами.
Другими словами, это мышление, направленное на развитие привычки общения с клиентами и получение от них регулярной обратной связи.
Чтобы победить сегодня и завтра, компании должны создать системы и процессы, которые позволят быстрее создавать нужные продукты.
Именно в этом и заключается суть continuous discovery: в убеждении, что продукт - это живой, дышащий организм и что пользователи играют центральную роль в его формировании.
42% компаний в качестве основной причины закрытия назвали "отсутствие потребности рынка".
Интересно, чем они занимались? Кому они собирались продавать? Зачем они вкладывали деньги в создание чего-либо, не определив ни рынка, который будет покупать их продукт, ни реальной рыночной потребности, которую нужно удовлетворить?
При этом лучшие команды осознают, что цифровые продукты никогда не бывают законченными. Всегда возможно проводить новые итерации и улучшать их. Facebook и Netflix никогда не будут законченными проектами.
Если бы они прекратили итерации и разработки, их догнали бы конкуренты. Например, компания Netflix начинала свою деятельность как сервис по пересылке DVD по почте, затем перешла к потоковому просмотру фильмов, а теперь создает собственные оригинальные программы.
Continuous discovery - это процесс проведения небольших исследований продуктовой команды в виде еженедельных взаимодействий с клиентами.
Другими словами, это мышление, направленное на развитие привычки общения с клиентами и получение от них регулярной обратной связи.
Чтобы победить сегодня и завтра, компании должны создать системы и процессы, которые позволят быстрее создавать нужные продукты.
Именно в этом и заключается суть continuous discovery: в убеждении, что продукт - это живой, дышащий организм и что пользователи играют центральную роль в его формировании.
Типы product discovery
Problem discovery:
это когда мы пытаемся понять
- проблему (или потребность) нашего клиента,
- как эта проблема связана со стратегическими целями бизнеса нашей компании,
- какова мотивация клиента, желающего решить эту проблему,
- когда, где, как и почему возникает эта проблема,
- существуют ли решения этой проблемы,
- что наш клиент думает об этих решениях.
Это все о проблеме, и в основном этим занимаются менеджер по продукту и дизайнер продукта.
Solution discovery:
когда мы начинаем понимать суть проблемы, которую необходимо решить, нам необходимо найти возможные решения этой проблемы.
В этот момент мы генерируем и проверяем идеи и гипотезы решения самым простым способом - с помощью прототипов, proof of concept и других подобных методов вроде low/nocode.
Это помогает всем членам команды разработчиков лучше понять, как максимизировать ценность, получаемую в ходе поставки продукта, и при этом минимизировать риски и время этой поставки.
По этой причине в процессе solution discovery должна быть задействована вся команда разработчиков продукта (менеджеры по продукту, дизайнеры и инженеры).
это когда мы пытаемся понять
- проблему (или потребность) нашего клиента,
- как эта проблема связана со стратегическими целями бизнеса нашей компании,
- какова мотивация клиента, желающего решить эту проблему,
- когда, где, как и почему возникает эта проблема,
- существуют ли решения этой проблемы,
- что наш клиент думает об этих решениях.
Это все о проблеме, и в основном этим занимаются менеджер по продукту и дизайнер продукта.
Solution discovery:
когда мы начинаем понимать суть проблемы, которую необходимо решить, нам необходимо найти возможные решения этой проблемы.
В этот момент мы генерируем и проверяем идеи и гипотезы решения самым простым способом - с помощью прототипов, proof of concept и других подобных методов вроде low/nocode.
Это помогает всем членам команды разработчиков лучше понять, как максимизировать ценность, получаемую в ходе поставки продукта, и при этом минимизировать риски и время этой поставки.
По этой причине в процессе solution discovery должна быть задействована вся команда разработчиков продукта (менеджеры по продукту, дизайнеры и инженеры).
В чем отличия discovery и delivery команд
В одном предложении:
Discovery: Разработать правильную вещь
Delivery: Разработать вещь правильно
Навыки
Discovery: Ориентированные на проблему навык UX исследований и стратегии.
Delivery: Ориентированные на разработку решений и оптимизацию продукта с помощью анализа данных и UI решений.
Задачи и подходы
Discovery:
Проведение исследований, Фокус на проблемах Преимущественно качественные данные Быстрое обучение Подтверждение потребности Быстрое экспериментирование
Delivery:
Детализация решений Фокус на тактике Преимущественно количественные данные Тщательное изучение процессов Валидация деталей Оптимизация
Основная деятельность:
Discovery: интервью, опросы, определение потребностей, слабо-детализированные прототипы, дизайн эксперименты, брейншторминг, анализ конкурентов, юзабилити исследования.
Delivery: высоко-детализированные прототипы, переработка интерфейсных решений, разбор задачи с разработчиками, закрытые карточные сортировки, ускорение работы системы
Команда:
Discovery: Все, кто необходим для принятия решений что должно быть сделано. Это не отдел компании, а рабочая группа. Сотрудники по-прежнему работают в своих обычных отделах. Некоторые из них могут быть на 100% вовлечены в работу группы, но многие - лишь частично.
Delivery: Владелец продукта и ИТ-специалисты: системные аналитики, дизайнеры, разработчики, тестировщики. Это не рабочая группа, а команда. У этих людей есть общая цель - цель продукта, и более важных целей у команды нет. Команда стабильна - все ее члены занимаются только 1 продуктом или проектом. Сотрудники могут находиться в любых отделах, но они на 100% вовлечены в работу команды.
Discovery: Разработать правильную вещь
Delivery: Разработать вещь правильно
Навыки
Discovery: Ориентированные на проблему навык UX исследований и стратегии.
Delivery: Ориентированные на разработку решений и оптимизацию продукта с помощью анализа данных и UI решений.
Задачи и подходы
Discovery:
Проведение исследований, Фокус на проблемах Преимущественно качественные данные Быстрое обучение Подтверждение потребности Быстрое экспериментирование
Delivery:
Детализация решений Фокус на тактике Преимущественно количественные данные Тщательное изучение процессов Валидация деталей Оптимизация
Основная деятельность:
Discovery: интервью, опросы, определение потребностей, слабо-детализированные прототипы, дизайн эксперименты, брейншторминг, анализ конкурентов, юзабилити исследования.
Delivery: высоко-детализированные прототипы, переработка интерфейсных решений, разбор задачи с разработчиками, закрытые карточные сортировки, ускорение работы системы
Команда:
Discovery: Все, кто необходим для принятия решений что должно быть сделано. Это не отдел компании, а рабочая группа. Сотрудники по-прежнему работают в своих обычных отделах. Некоторые из них могут быть на 100% вовлечены в работу группы, но многие - лишь частично.
Delivery: Владелец продукта и ИТ-специалисты: системные аналитики, дизайнеры, разработчики, тестировщики. Это не рабочая группа, а команда. У этих людей есть общая цель - цель продукта, и более важных целей у команды нет. Команда стабильна - все ее члены занимаются только 1 продуктом или проектом. Сотрудники могут находиться в любых отделах, но они на 100% вовлечены в работу команды.
Состав discovery команды
Основная команда
Вместе общается с пользователями на регулярной основе. Драйвит весь процесс product discovery. Cовместно разрабатывает и проводит тесты гипотез. Информирование всех других подразделений и стейкхолдеров должно исходить от основной команды. Основная команда (core) должна состоять из:
1) Продакт менеджер
2) Дизайнер
3) Разработчик
При этом желательно это должны быть лиды своих направлений. Например Design lead, Tech lead.
Если позволяет ситуация и ресурсы в основной команде могут быть:
UX исследователи
Data-аналитики
Команда может генерировать идеи и принимать решения в своем собственном темпе. Чем ниже зависимости от других подразделений компаний, тем выше скорость проверки гипотез. А еще верно, что больше человек в команде discovery НЕ равно увеличению количества проверенных гипотез.
Временная/Ситуативная команда.
Привлекается в зависимости от задачи на нерегулярной основе.
Чаще всего задействована на этапе сбора гипотез.
Состоит из:
- Эксперт в сфере (домене) например логистика, финтех, и др.
- Поддержка пользователей
- Специалист по маркетингу
- Специалисты отдела продаж
- Разработчики, которые детально понимают как технически работает часть продукта
- Архитекторы
- Бизнес аналитики
- Data-science
Саппорт команда.
Должна быть проинформирована о ходе исследований, привлекается в процесс discovery достаточно редко. Состоит из:
- Топ-менеджмент
- Отдел IT инфраструктуры
- Другие discovery команды
- Бизнес стейкхолдеры
Пользователи задействованы в процессе discovery всегда. Но внутри команды не находятся.
Вместе общается с пользователями на регулярной основе. Драйвит весь процесс product discovery. Cовместно разрабатывает и проводит тесты гипотез. Информирование всех других подразделений и стейкхолдеров должно исходить от основной команды. Основная команда (core) должна состоять из:
1) Продакт менеджер
2) Дизайнер
3) Разработчик
При этом желательно это должны быть лиды своих направлений. Например Design lead, Tech lead.
Если позволяет ситуация и ресурсы в основной команде могут быть:
UX исследователи
Data-аналитики
Команда может генерировать идеи и принимать решения в своем собственном темпе. Чем ниже зависимости от других подразделений компаний, тем выше скорость проверки гипотез. А еще верно, что больше человек в команде discovery НЕ равно увеличению количества проверенных гипотез.
Временная/Ситуативная команда.
Привлекается в зависимости от задачи на нерегулярной основе.
Чаще всего задействована на этапе сбора гипотез.
Состоит из:
- Эксперт в сфере (домене) например логистика, финтех, и др.
- Поддержка пользователей
- Специалист по маркетингу
- Специалисты отдела продаж
- Разработчики, которые детально понимают как технически работает часть продукта
- Архитекторы
- Бизнес аналитики
- Data-science
Саппорт команда.
Должна быть проинформирована о ходе исследований, привлекается в процесс discovery достаточно редко. Состоит из:
- Топ-менеджмент
- Отдел IT инфраструктуры
- Другие discovery команды
- Бизнес стейкхолдеры
Пользователи задействованы в процессе discovery всегда. Но внутри команды не находятся.
Процесс product discovery
По процессам product discovery стоит посмотреть гайды ниже:
Методы product discovery
- Клиентские интервью: Проведение бесед с пользователями для понимания их потребностей, проблем и желаний.
- Тестирование гипотез: Проверка предположений и идей путем проведения экспериментов или использования A/B тестов.
- Исследование пользовательских путей: Документация пути пользователя через продукт для определения сильных и слабых мест в опыте пользователя.
- Прототипирование: Создание прототипов продукта для быстрого тестирования и получения обратной связи от пользователей.
- Минимально жизнеспособный продукт (MVP): Создание минимально функциональной версии продукта, которая позволяет получить обратную связь от пользователей и быстро проверить гипотезы.
- Документация возможностей и решений: Создание дерева возможностей и решений для определения наиболее перспективных направлений развития продукта.
- Ретроспектива: Регулярное обсуждение процесса product discovery командой для выявления улучшений и корректировки подхода.
- Данные и аналитика: Использование данных и аналитики для оценки эффективности продукта и принятия решений на основе фактов.
- Кросс-функциональное сотрудничество: Вовлечение различных команд и стейкхолдеров, таких как разработка, дизайн, маркетинг и поддержка пользователей, для совместной работы над product discovery.
Инструменты discovery
Для каждого этапа жизненного цикла продукта не нужен свой инструмент, но в зависимости от целей исследования можно использовать различные типы инструментов:
1. Инструменты исследования пользователей
Огромная часть процесса поиска продукта - это получение информации от реальных пользователей с помощью пользовательских исследований, а также обработка этих данных для принятия решений по продукту. Инструменты UX-исследований и тестирования юзабилити облегчают сбор и анализ отзывов пользователей с помощью интервью, опросов и юзабилити-тестирования.
2. Инструменты аналитики
При тестировании концепций или работы в процессе continuous discovery вам нужны статистические данные, показывающие, какие идеи находят отклик, какие функции работают и где возникают потенциальные проблемы. С помощью инструментов аналитики можно увидеть, как реальные пользователи взаимодействуют с вашими продуктами, и собрать данные, подтверждающие результаты качественных исследований.
3. Инструменты для экспериментов
Инструменты для проведения экспериментов позволяют тестировать различные идеи продуктов и новые функции, а также оценивать их влияние на поведение и удовлетворенность пользователей - с помощью A/B-тестирования, многовариантного тестирования и переключения функций. Подобные инструменты проверки и подтверждения гипотез позволяют сравнивать различные варианты продукта и принимать решения, основываясь на реальном мнении пользователей.
4. Инструменты "Голос клиента"
Инструменты VoC собирают прямую обратную связь от клиентов с помощью анализа настроений, опросов удовлетворенности клиентов и мониторинга социальных сетей, позволяя командам разработчиков получить прямой канал связи с ключевой аудиторией.
5. Инструменты управления проектами
Инструменты управления проектами необходимы любой продуктовой команде. Например Notion и Jira, помогают автоматизировать рабочие процессы, организовать задачи и совместную работу. Отслеживая задачи, сроки и зависимости, вы обеспечиваете согласованность и информированность членов команды на протяжении всего процесса разработки продукта.
Вот несколько инструментов, которые можно использовать на разных этапах процесса discovery продукта:
1. Инструменты исследования пользователей
Огромная часть процесса поиска продукта - это получение информации от реальных пользователей с помощью пользовательских исследований, а также обработка этих данных для принятия решений по продукту. Инструменты UX-исследований и тестирования юзабилити облегчают сбор и анализ отзывов пользователей с помощью интервью, опросов и юзабилити-тестирования.
2. Инструменты аналитики
При тестировании концепций или работы в процессе continuous discovery вам нужны статистические данные, показывающие, какие идеи находят отклик, какие функции работают и где возникают потенциальные проблемы. С помощью инструментов аналитики можно увидеть, как реальные пользователи взаимодействуют с вашими продуктами, и собрать данные, подтверждающие результаты качественных исследований.
3. Инструменты для экспериментов
Инструменты для проведения экспериментов позволяют тестировать различные идеи продуктов и новые функции, а также оценивать их влияние на поведение и удовлетворенность пользователей - с помощью A/B-тестирования, многовариантного тестирования и переключения функций. Подобные инструменты проверки и подтверждения гипотез позволяют сравнивать различные варианты продукта и принимать решения, основываясь на реальном мнении пользователей.
4. Инструменты "Голос клиента"
Инструменты VoC собирают прямую обратную связь от клиентов с помощью анализа настроений, опросов удовлетворенности клиентов и мониторинга социальных сетей, позволяя командам разработчиков получить прямой канал связи с ключевой аудиторией.
5. Инструменты управления проектами
Инструменты управления проектами необходимы любой продуктовой команде. Например Notion и Jira, помогают автоматизировать рабочие процессы, организовать задачи и совместную работу. Отслеживая задачи, сроки и зависимости, вы обеспечиваете согласованность и информированность членов команды на протяжении всего процесса разработки продукта.
Вот несколько инструментов, которые можно использовать на разных этапах процесса discovery продукта:
- Анализ поведения пользователей и приложений: Mixpanel, Amplitude, fullstory или HotJar
- Опросы клиентов: Typeform Google forms
- Составление расписания интервью: Calendly
- Запись интервью: Zoom или Fathom
- Демонстрация экрана: Figma или Marvel
- Документация обратной связи: Notion, Salesforce, ProdPad
- Валидация и приоритизация гипотез: ProdPad
Гипотезы для product discovery
Важнейшая фаза discovery продукта - докопаться до сути потребностей клиента, чтобы переформулировать их в виде гипотезы.
Формулировка проблемы должна быть достаточно общей, чтобы ее можно было решить различными способами, но не настолько расплывчатой, чтобы охватывать множество проблем.
Хорошая постановка проблемы позволяет определить, кто является заказчиком и с какой проблемой он сталкивается, не делая поспешных выводов о том, как должно выглядеть решение.
Хороший пример:
Студенты не получают предупреждения о том, что их задание должно быть выполнено
Плохой пример:
Клиентам нужны оповещения по электронной почте, чтобы они знали, когда должно быть выполнено задание
Хороший пример:
Студенты часто пропускают сроки сдачи задания
Плохой пример:
Клиенты хотят получать уведомления
Формулировка проблемы должна быть достаточно общей, чтобы ее можно было решить различными способами, но не настолько расплывчатой, чтобы охватывать множество проблем.
Хорошая постановка проблемы позволяет определить, кто является заказчиком и с какой проблемой он сталкивается, не делая поспешных выводов о том, как должно выглядеть решение.
Хороший пример:
Студенты не получают предупреждения о том, что их задание должно быть выполнено
Плохой пример:
Клиентам нужны оповещения по электронной почте, чтобы они знали, когда должно быть выполнено задание
Хороший пример:
Студенты часто пропускают сроки сдачи задания
Плохой пример:
Клиенты хотят получать уведомления
Общение с пользователями во время discovery
В отличие от других методик discovery, предоставляющих количественные данные, интервью с клиентами дают качественные результаты, и позволяют понять мотивы и проблемы клиентов. Например, можно узнать, как выглядит повседневная жизнь ваших пользователей, какой язык они используют и что они ценят.
Недостатком интервью с клиентами является то, что они требуют времени на организацию, проведение, повторный просмотр и ведение записей. Если вы платите пользователям за интервью или проводите опрос лично, это также может оказаться дорогостоящим. Как только вы начали общаться с клиентом, очень важно использовать это время с максимальной пользой.
Простого опроса пользователей один или два раза в год недостаточно - их потребности и конкурентная среда постоянно меняются. Вот несколько советов по постоянному привлечению клиентов:
Давайте посмотрим правде в глаза. Набирать участников пользовательских исследований нелегко. Но вот несколько идей, как автоматизировать и упростить составление расписания интервью:
Недостатком интервью с клиентами является то, что они требуют времени на организацию, проведение, повторный просмотр и ведение записей. Если вы платите пользователям за интервью или проводите опрос лично, это также может оказаться дорогостоящим. Как только вы начали общаться с клиентом, очень важно использовать это время с максимальной пользой.
Простого опроса пользователей один или два раза в год недостаточно - их потребности и конкурентная среда постоянно меняются. Вот несколько советов по постоянному привлечению клиентов:
- Организуйте периодические звонки или встречи с представителями текущих пользователей, потенциальных клиентов, ушедших клиентов, отраслевых экспертов и т.д. Сделайте это привычкой раз в неделю или раз в две недели.
- Применяйте этнографический подход - наблюдайте за тем, как клиенты используют ваш продукт в реальных условиях. Ищите болевые точки и неудовлетворенные потребности.
- Используйте социальные сети для постоянного диалога с пользователями через Twitter, группы LinkedIn, Facebook и т.д.
- Следите за отзывами в магазинах приложений и на форумах сообществ, чтобы быть в курсе настроений клиентов и возникающих жалоб.
- Периодически проводите опросы NPS для определения уровня удовлетворенности и лояльности.
- Разработайте персоны клиентов и CJM для выявления ключевых моментов трения и возможностей.
- Пообщайтесь с сотрудниками колл-центра и службы поддержки, чтобы выявить общие проблемы клиентов и повторяющиеся жалобы.
- Регулярно проводите тестирование новых функций с целевыми пользователями перед запуском
Давайте посмотрим правде в глаза. Набирать участников пользовательских исследований нелегко. Но вот несколько идей, как автоматизировать и упростить составление расписания интервью:
- Для B2B-рынков работайте с командами, которые взаимодействуют с клиентами, - попросите их планировать интервью в вашем календаре во время бесед с топ-менеджерами и руководителями высшего звена. Определите триггеры в зависимости от вашей направленности. Например, если клиент сталкивается с определенной проблемой, спросите его, согласится ли он встретиться с вами для проведения интервью, и предложите такой стимул, как ранний доступ к новым функциям.
- Для рынков B2C привлекайте клиентов в то время, когда они пользуются вашим продуктом или посещают ваш сайт, создав всплывающее окно с запросом на интервью, связанное с вашим календарем. Предложите подписчикам подарочную карту.
Скорость discovery процесса
Лучшие команды проводят 15-20 discovery итераций в неделю. При правильном подходе, инструментах и методах это может быстро стать реальностью.
Вы должны быть готовы, что многие идеи не сработают, а те, что сработают, потребуют множества итераций. Вы должны быть открыты для решения основной проблемы с разных точек зрения.
На этапе discovery главное - скорость. Не существует "серебряной пули" в том, сколько раз нужно проводить итерации. Ваша команда может делать больше или меньше.
При всех имеющихся возможностях нет оправдания слабой валидации проблем и целевых потребителей на ранних этапах разработки продукта. Один или даже несколько тестов не делают продукт пригодным для продажи или финансирования.
Чем больше объективных тестов вы проведете на начальном этапе и чем чаще будете повторять их, тем выше вероятность того, что вы придете к отличному решению, которое люди захотят использовать и покупать.
Вы должны быть готовы, что многие идеи не сработают, а те, что сработают, потребуют множества итераций. Вы должны быть открыты для решения основной проблемы с разных точек зрения.
На этапе discovery главное - скорость. Не существует "серебряной пули" в том, сколько раз нужно проводить итерации. Ваша команда может делать больше или меньше.
При всех имеющихся возможностях нет оправдания слабой валидации проблем и целевых потребителей на ранних этапах разработки продукта. Один или даже несколько тестов не делают продукт пригодным для продажи или финансирования.
Чем больше объективных тестов вы проведете на начальном этапе и чем чаще будете повторять их, тем выше вероятность того, что вы придете к отличному решению, которое люди захотят использовать и покупать.
Гайды по внедрению product discovery
Шаги для внедрения product discovery:
- Начните с исследования и понимания пользователей: Проведите исследование рынка и потребностей пользователей, чтобы лучше понять, что они хотят и какие проблемы им нужно решить.
- Формулирование гипотез: Гипотезы должны быть конкретными, измеримыми и связанными с потребностями пользователей или бизнес-целями.
- Планирование экспериментов: Разработайте план эксперимента, определите метрики успеха и выберите методы, такие как A/B-тестирование, прототипирование, опросы или пользовательские тестирования.
- Проведение экспериментов: Реализуйте запланированные эксперименты и соберите данные и обратную связь от пользователей. Анализируйте результаты экспериментов, сравнивайте их с гипотезами и делайте выводы о том, что работает и что нужно улучшить.
- Принятие решений: Используйте результаты экспериментов и данные для принятия обоснованных решений о дальнейшем развитии продукта.
- Итеративный подход: Продукт discovery должен стать постоянным итеративным процессом в жизненном цикле продукта.
- Сотрудничество между командами: Обеспечьте тесное взаимодействие между командами разработки продукта и product discovery командой
Ошибки в Discovery
Ловушка delivery - это концепция, имеющая множество проявлений:
1) Фича-фабрика - команда разработчиков, ориентированная на предоставление фич, а не ценности
2) Ловушка строительства - команда, ориентированная на выпуск продукции, а не на результат
3) Wireframe Monkey - когда дизайнеры не имеют вдохновения и разрабатывают что угодно для кого угодно
4) Pixel Pusher - когда руководство берет на себя управление процессом проектирования и проталкивает дизайнерские идеи.
Люди приравнивают A/B-тестирование к discovery. Они думают, что раз они проводят A/B-тестирование всего, что выпускают, значит, они прекрасно справляются с discovery. Хорошо, но если это 100% всех ваших исследований, то вы учитесь самым медленным и дорогостоящим способом. Вы создаете все, прежде чем узнаете, правильно это или нет?
Список вредных советов:
1. Не обращайте внимания на реальные проблемы пользователей
"Если бы у меня был час на решение проблемы, я бы потратил первые 55 минут на определение проблемы и смог бы решить ее менее чем за пять минут".
2. Не привлекайте разработчиков к процессу поиска
Если вы привлекаете разработчиков к процессу разработки продукта только для разработки, то это ошибка.
Разработчики тоже должны понимать проблемы. Если разработчики не понимают проблему, как они смогут ее решить? Более того, предположим, что менеджер по продукту не привлекает их к фазе discovery. В этом случае на плечи PM ляжет ответственность за объяснение разработчикам тонкостей проекта, что может привести к неправильному пониманию проблемы.
3. Бояться задавать вопросы
Discovery продукта заключается в фокусировке на проблеме. Поэтому при подходе к этому процессу необходимо иметь правильное мышление. Речь идет о:
4 Отдать исследования на аутсорсинг
Аутсорсинговая компания, безусловно, может помочь вам в эффективном discovery продукта, но только в том случае, если вы будете участвовать в этом процессе. Простое получение инсайтов, данных и отчетов не поможет вам определить реальные потребности пользователей.
Чтобы создать полезный продукт, необходимо вступить в прямой контакт с конечными пользователями, проверить идеи и даже помочь в создании прототипа. Помните, что успешные результаты - это всегда результат инновационных и совместных усилий.
1) Фича-фабрика - команда разработчиков, ориентированная на предоставление фич, а не ценности
2) Ловушка строительства - команда, ориентированная на выпуск продукции, а не на результат
3) Wireframe Monkey - когда дизайнеры не имеют вдохновения и разрабатывают что угодно для кого угодно
4) Pixel Pusher - когда руководство берет на себя управление процессом проектирования и проталкивает дизайнерские идеи.
Люди приравнивают A/B-тестирование к discovery. Они думают, что раз они проводят A/B-тестирование всего, что выпускают, значит, они прекрасно справляются с discovery. Хорошо, но если это 100% всех ваших исследований, то вы учитесь самым медленным и дорогостоящим способом. Вы создаете все, прежде чем узнаете, правильно это или нет?
Список вредных советов:
1. Не обращайте внимания на реальные проблемы пользователей
"Если бы у меня был час на решение проблемы, я бы потратил первые 55 минут на определение проблемы и смог бы решить ее менее чем за пять минут".
2. Не привлекайте разработчиков к процессу поиска
Если вы привлекаете разработчиков к процессу разработки продукта только для разработки, то это ошибка.
Разработчики тоже должны понимать проблемы. Если разработчики не понимают проблему, как они смогут ее решить? Более того, предположим, что менеджер по продукту не привлекает их к фазе discovery. В этом случае на плечи PM ляжет ответственность за объяснение разработчикам тонкостей проекта, что может привести к неправильному пониманию проблемы.
3. Бояться задавать вопросы
Discovery продукта заключается в фокусировке на проблеме. Поэтому при подходе к этому процессу необходимо иметь правильное мышление. Речь идет о:
- Изучение тенденций рынка для понимания потребностей пользователей
- Не бояться задавать основные вопросы и проверять предположения.
4 Отдать исследования на аутсорсинг
Аутсорсинговая компания, безусловно, может помочь вам в эффективном discovery продукта, но только в том случае, если вы будете участвовать в этом процессе. Простое получение инсайтов, данных и отчетов не поможет вам определить реальные потребности пользователей.
Чтобы создать полезный продукт, необходимо вступить в прямой контакт с конечными пользователями, проверить идеи и даже помочь в создании прототипа. Помните, что успешные результаты - это всегда результат инновационных и совместных усилий.
Как измерять product discovery
Бизнес-результат позволяет оценить, насколько успешно развивается бизнес (например, удержание персонала).
Продуктовый результат измеряет, насколько хорошо продукт продвигает бизнес.
Бизнес-результаты начинаются с финансовых показателей (например, рост выручки, снижение затрат), они являются запаздывающими индикаторами. 90-дневное удержание - это запаздывающий показатель.
Мы хотим определить опережающие показатели, которые предсказывают направление запаздывающего показателя.
Назначение команде опережающего показателя всегда лучше, чем назначение отстающего показателя. Discovery команда добьется большего прогресса по продуктовому результату, чем по бизнес-результату. Присвоение продуктовых результатов повышает чувство ответственности и сопричастности. Если discovery команде назначить бизнес-результат, то ей будет легко обвинить маркетинг или службу поддержки клиентов в том, что они не достигли своей цели.
Продуктовый результат измеряет, насколько хорошо продукт продвигает бизнес.
Бизнес-результаты начинаются с финансовых показателей (например, рост выручки, снижение затрат), они являются запаздывающими индикаторами. 90-дневное удержание - это запаздывающий показатель.
Мы хотим определить опережающие показатели, которые предсказывают направление запаздывающего показателя.
Назначение команде опережающего показателя всегда лучше, чем назначение отстающего показателя. Discovery команда добьется большего прогресса по продуктовому результату, чем по бизнес-результату. Присвоение продуктовых результатов повышает чувство ответственности и сопричастности. Если discovery команде назначить бизнес-результат, то ей будет легко обвинить маркетинг или службу поддержки клиентов в том, что они не достигли своей цели.
Общение со стейкхолдерами во время discovery
Стейкхолдерам не обязательно видеть все итерации, которые вы проделали. Можно просто показать им основные моменты.
Очень немногие заказчики хотят или у них есть время на то чтобы изучить все итерации, которые мы проводили. Вместо этого они хотят видеть ход мысли, который привел вас к тому, к чему вы пришли сейчас.
Отсутствие ясности в вопросе о том, почему вы занимаетесь именно этими discovery задачами, может привести к таким проблемам, как поиск решений или предвзятое отношение к результатам. Но даже если вы осознаете важность согласований своих действий с заказчиками, не все согласования одинаковы.
Практически каждому менеджеру по продукту знакома ситуация, когда некоторые заинтересованные стороны постоянно предлагают конкретные функции, которые они хотят встроить в продукт (т.е. решения, а не проблемы).
К сожалению, это свидетельствует о недостатке доверия: заинтересованные стороны не верят, что результат работы вашей команды будет соответствовать их ожиданиям.
Лучший способ решить эту проблему - сфокусироваться на согласовании на ранних этапах разработки продукта и взять на себя обязательства по достижению конкретного результата, а не по созданию функций.
Очень немногие заказчики хотят или у них есть время на то чтобы изучить все итерации, которые мы проводили. Вместо этого они хотят видеть ход мысли, который привел вас к тому, к чему вы пришли сейчас.
Отсутствие ясности в вопросе о том, почему вы занимаетесь именно этими discovery задачами, может привести к таким проблемам, как поиск решений или предвзятое отношение к результатам. Но даже если вы осознаете важность согласований своих действий с заказчиками, не все согласования одинаковы.
Практически каждому менеджеру по продукту знакома ситуация, когда некоторые заинтересованные стороны постоянно предлагают конкретные функции, которые они хотят встроить в продукт (т.е. решения, а не проблемы).
К сожалению, это свидетельствует о недостатке доверия: заинтересованные стороны не верят, что результат работы вашей команды будет соответствовать их ожиданиям.
Лучший способ решить эту проблему - сфокусироваться на согласовании на ранних этапах разработки продукта и взять на себя обязательства по достижению конкретного результата, а не по созданию функций.
Опыт и примеры внедрения discovery в компаниях
Теория это хорошо. Но вот как только сталкиваешься с реальным внедрением discovery процессов, то можешь столкнуться с неожиданными трудностями. О таких препятствиях рассказывают профессиональные продакт менеджеры в гайдах ниже:
Документация Product discovery
Когда занимаешься документацией исследований, можно начать с вопроса: "Зачем вообще это нужно?".
Для большинства создаваемых артефактов есть три ответа:
1) Мы создаем артефакты, о том что думаем, делаем и для согласования свои действий в discovery команде.
2) Мы создаем артефакты, чтобы помочь донести наши мысли до стейкхолдеров
3) Мы создаем артефакты, чтобы напомнить себе, что мы уже проверяли.
Самая большая ошибка заключается в том, что команды создают совершенно разные артефакты для каждой из этих трех целей.
Например, они могут создавать:
1) Пользовательские истории, чтобы команда могла определить что им нужно создать в этом спринте;
2) Презентацию, рассказывающую маркетингу и продажам о том, что появится в следующих двух спринтах;
3) Примечания к релизу, чтобы документировать то, что произошло на самом деле.
Чтобы разобраться с решением этой проблемы, сначала определимся какая документация может вообще встретиться.
Условно ее можно разделить в зависимости от этапа:
1) Формулирование гипотез:
Lean Canvas
Business Model Canvas
Value Proposition Canvas
2) Приоритизация гипотез:
Story map
Impact mapping
Idea validation grid
3) Развитие продукта:
Opportunity solution tree
Interview snapshot
Experience Map
Actor-Job-Outcome-Mapping
Первые две группы нужны больше для структурирования идей внутри команды, а третья как раз поможет разобраться с дублированием документации для разных заинтересованных групп.
И для этого можно воспользоваться подходом Терезы Торрес (автора книги Continuous discovery habits)
1) Создаем один набор слайдов для каждого продукта для снимков интервью (interview shots). Удаляем записи интервью или диктофонные записи, чтобы не нести расходы на их хранение и соблюдение конфиденциальности.
2) Создаем одну доску в Miro для каждого результата (outcome - рост прибыли, сокращение расходов, увеличение retention и т.д).
Когда начинаешь разбирать определенный результат, то включаешь в нее самое последнее opportunity solution tree, experience map, story map а также схемы и результаты тестов гипотез.
3) Также можно вести журнал решений. Сюда входят выбор приоритетного результата (рост прибыли, сокращение расходов, увеличение retention и т.д), определение приоритетности возможностей (opportunities) и выбор решения (solution). Можно добавлять соответствующие фрагменты на доску Miro.
Одним словом:
Фиксировать все договоренности в рамках документа Opportunity solution tree в доске в Miro и сохранять все результаты и схемы реализации тоже там.
Все примеры документации есть здесь:
Для большинства создаваемых артефактов есть три ответа:
1) Мы создаем артефакты, о том что думаем, делаем и для согласования свои действий в discovery команде.
2) Мы создаем артефакты, чтобы помочь донести наши мысли до стейкхолдеров
3) Мы создаем артефакты, чтобы напомнить себе, что мы уже проверяли.
Самая большая ошибка заключается в том, что команды создают совершенно разные артефакты для каждой из этих трех целей.
Например, они могут создавать:
1) Пользовательские истории, чтобы команда могла определить что им нужно создать в этом спринте;
2) Презентацию, рассказывающую маркетингу и продажам о том, что появится в следующих двух спринтах;
3) Примечания к релизу, чтобы документировать то, что произошло на самом деле.
Чтобы разобраться с решением этой проблемы, сначала определимся какая документация может вообще встретиться.
Условно ее можно разделить в зависимости от этапа:
1) Формулирование гипотез:
Lean Canvas
Business Model Canvas
Value Proposition Canvas
2) Приоритизация гипотез:
Story map
Impact mapping
Idea validation grid
3) Развитие продукта:
Opportunity solution tree
Interview snapshot
Experience Map
Actor-Job-Outcome-Mapping
Первые две группы нужны больше для структурирования идей внутри команды, а третья как раз поможет разобраться с дублированием документации для разных заинтересованных групп.
И для этого можно воспользоваться подходом Терезы Торрес (автора книги Continuous discovery habits)
1) Создаем один набор слайдов для каждого продукта для снимков интервью (interview shots). Удаляем записи интервью или диктофонные записи, чтобы не нести расходы на их хранение и соблюдение конфиденциальности.
2) Создаем одну доску в Miro для каждого результата (outcome - рост прибыли, сокращение расходов, увеличение retention и т.д).
Когда начинаешь разбирать определенный результат, то включаешь в нее самое последнее opportunity solution tree, experience map, story map а также схемы и результаты тестов гипотез.
3) Также можно вести журнал решений. Сюда входят выбор приоритетного результата (рост прибыли, сокращение расходов, увеличение retention и т.д), определение приоритетности возможностей (opportunities) и выбор решения (solution). Можно добавлять соответствующие фрагменты на доску Miro.
Одним словом:
Фиксировать все договоренности в рамках документа Opportunity solution tree в доске в Miro и сохранять все результаты и схемы реализации тоже там.
Все примеры документации есть здесь:
Ключевые личности при изучении discovery
За кем точно стоит следить чтобы получать новые выводы и подходы о product discovery:
Discovery процессы в знаменитых компаниях
Каждая компания так или иначе адаптирует теорию под свои реалии. Основа у всех практически одинаковая, но есть свои лайфхаки. Подборка дискавери процессов от топовых компаний, голосом их собственных продакт менеджеров:
Поделись обратной связью:)
Насколько хорошо вы знаете product discovery?
Содержание раздела:
Навык 1: Product management от нуля к единице
Навык 2: Что такое продуктовая гипотеза
Навык 3: Шаблон для составления гипотез
Навык 4: Product discovery
Навык 5: Способы генерации идей
Навык 6: Аудит продукта
Навык 7: Pivot продукта
Навык 8: Сравнение конкурентов
Навык 9: ТРИЗ
Навык 10: Нейросети для идей
Навык 11: Источники идей