Тема «проверка продуктовой проблемы» отвечает на решение: какие свидетельства показывают, что люди уже сталкиваются с препятствием и пытаются его преодолеть. Практика «проверка продуктовой проблемы» помогает проверить существование, серьёзность и повторяемость проблемы до существенных затрат на реализацию решения.
GOV.UK требует развивать глубокое понимание пользователей и проблемы, которую сервис пытается решить. основание
В материале «проверка продуктовой проблемы» факт, локальный замер и гипотеза разделяются. Факт «проверка продуктовой проблемы» получает источник. Замер «проверка продуктовой проблемы» получает версию. Гипотеза «проверка продуктовой проблемы» получает отдельную проверку.
Double Diamond помещает исследование и определение вызова до разработки и доставки решения. основание
Задача и границы решения
Решение «проверка продуктовой проблемы» формулируется через вопрос «какие свидетельства показывают, что люди уже сталкиваются с препятствием и пытаются его преодолеть». Такой вопрос удерживает тему «проверка продуктовой проблемы» возле проверяемого результата.
Компонент «наблюдаемое поведение» задаёт первый вход темы «проверка продуктовой проблемы». Для «наблюдаемое поведение» команда фиксирует источник, владельца и дату.
Компонент «частота ситуации» задаёт точку сравнения темы «проверка продуктовой проблемы». Изменение «частота ситуации» требует нового вывода по теме «проверка продуктовой проблемы».
Компонент «текущая альтернатива» отделяет факт темы «проверка продуктовой проблемы» от предположения. Для «текущая альтернатива» гипотеза хранится рядом с проверкой.
Граница темы «проверка продуктовой проблемы» проходит возле отраслевого решения. Метод «проверка продуктовой проблемы» организует данные, но профильный специалист сохраняет полномочия.
Design Council рекомендует говорить с затронутыми людьми, замечать ошибки рано и итеративно проверять идеи. основание
Состав рабочего контура
Компонент 1: наблюдаемое поведение. Тема «проверка продуктовой проблемы» связывает «наблюдаемое поведение» с действием «провести интервью о конкретных эпизодах». Критерий «известна текущая альтернатива» проверяет «наблюдаемое поведение»; риск «игнорирование существующей альтернативы» блокирует вывод.
Компонент 2: частота ситуации. Тема «проверка продуктовой проблемы» связывает «частота ситуации» с действием «наблюдать текущий процесс». Критерий «сегмент определён» проверяет «частота ситуации»; риск «опрос о желании функции» блокирует вывод.
Компонент 3: текущая альтернатива. Тема «проверка продуктовой проблемы» связывает «текущая альтернатива» с действием «проверить готовность совершить действие». Критерий «следующий тест дешевле полной разработки» проверяет «текущая альтернатива»; риск «прототип до понимания причины» блокирует вывод.
Компонент 4: стоимость проблемы. Тема «проверка продуктовой проблемы» связывает «стоимость проблемы» с действием «сопоставить сегменты». Критерий «условие остановки задано заранее» проверяет «стоимость проблемы»; риск «подтверждение только сотрудниками компании» блокирует вывод.
Компонент 5: доступ к аудитории. Тема «проверка продуктовой проблемы» связывает «доступ к аудитории» с действием «принять решение о следующем вложении». Критерий «есть несколько независимых типов свидетельств» проверяет «доступ к аудитории»; риск «путаница интереса и поведения» блокирует вывод.
Компонент 6: минимальная проверка спроса. Тема «проверка продуктовой проблемы» связывает «минимальная проверка спроса» с действием «собрать сигналы из поддержки и аналитики». Критерий «описано прошлое поведение» проверяет «минимальная проверка спроса»; риск «игнорирование существующей альтернативы» блокирует вывод.
Порядок работы
Шаг 1: собрать сигналы из поддержки и аналитики. В теме «проверка продуктовой проблемы» действие «собрать сигналы из поддержки и аналитики» изменяет «частота ситуации». Критерий «есть несколько независимых типов свидетельств» проверяет результат; ошибка «опрос о желании функции» останавливает переход.
Шаг 2: провести интервью о конкретных эпизодах. В теме «проверка продуктовой проблемы» действие «провести интервью о конкретных эпизодах» изменяет «текущая альтернатива». Критерий «описано прошлое поведение» проверяет результат; ошибка «прототип до понимания причины» останавливает переход.
Шаг 3: наблюдать текущий процесс. В теме «проверка продуктовой проблемы» действие «наблюдать текущий процесс» изменяет «стоимость проблемы». Критерий «известна текущая альтернатива» проверяет результат; ошибка «подтверждение только сотрудниками компании» останавливает переход.
Шаг 4: проверить готовность совершить действие. В теме «проверка продуктовой проблемы» действие «проверить готовность совершить действие» изменяет «доступ к аудитории». Критерий «сегмент определён» проверяет результат; ошибка «путаница интереса и поведения» останавливает переход.
Шаг 5: сопоставить сегменты. В теме «проверка продуктовой проблемы» действие «сопоставить сегменты» изменяет «минимальная проверка спроса». Критерий «следующий тест дешевле полной разработки» проверяет результат; ошибка «игнорирование существующей альтернативы» останавливает переход.
Шаг 6: принять решение о следующем вложении. В теме «проверка продуктовой проблемы» действие «принять решение о следующем вложении» изменяет «наблюдаемое поведение». Критерий «условие остановки задано заранее» проверяет результат; ошибка «опрос о желании функции» останавливает переход.
Типовые ошибки и диагностика
Ошибка 1: опрос о желании функции. В теме «проверка продуктовой проблемы» ошибка «опрос о желании функции» искажает «стоимость проблемы». Действие «наблюдать текущий процесс» проверяет исправление по критерию «сегмент определён».
Ошибка 2: прототип до понимания причины. В теме «проверка продуктовой проблемы» ошибка «прототип до понимания причины» искажает «минимальная проверка спроса». Действие «проверить готовность совершить действие» проверяет исправление по критерию «следующий тест дешевле полной разработки».
Ошибка 3: подтверждение только сотрудниками компании. В теме «проверка продуктовой проблемы» ошибка «подтверждение только сотрудниками компании» искажает «частота ситуации». Действие «сопоставить сегменты» проверяет исправление по критерию «условие остановки задано заранее».
Ошибка 4: путаница интереса и поведения. В теме «проверка продуктовой проблемы» ошибка «путаница интереса и поведения» искажает «стоимость проблемы». Действие «принять решение о следующем вложении» проверяет исправление по критерию «есть несколько независимых типов свидетельств».
Ошибка 5: игнорирование существующей альтернативы. В теме «проверка продуктовой проблемы» ошибка «игнорирование существующей альтернативы» искажает «минимальная проверка спроса». Действие «собрать сигналы из поддержки и аналитики» проверяет исправление по критерию «описано прошлое поведение».
Практический пример
Практический сценарий «проверка продуктовой проблемы»: До автоматизации отчёта команда выясняет, кто готовит его вручную, сколько этапов проходит процесс, какие ошибки исправляются и согласятся ли пользователи предоставить реальные данные для пилота.
Этап 1 сценария «проверка продуктовой проблемы» связывает «наблюдаемое поведение» и действие «собрать сигналы из поддержки и аналитики». Критерий «есть несколько независимых типов свидетельств» оценивает этап; риск «опрос о желании функции» остаётся блокером.
Этап 2 сценария «проверка продуктовой проблемы» связывает «частота ситуации» и действие «провести интервью о конкретных эпизодах». Критерий «описано прошлое поведение» оценивает этап; риск «прототип до понимания причины» остаётся блокером.
Этап 3 сценария «проверка продуктовой проблемы» связывает «текущая альтернатива» и действие «наблюдать текущий процесс». Критерий «известна текущая альтернатива» оценивает этап; риск «подтверждение только сотрудниками компании» остаётся блокером.
Этап 4 сценария «проверка продуктовой проблемы» связывает «стоимость проблемы» и действие «проверить готовность совершить действие». Критерий «сегмент определён» оценивает этап; риск «путаница интереса и поведения» остаётся блокером.
Этап 5 сценария «проверка продуктовой проблемы» связывает «доступ к аудитории» и действие «сопоставить сегменты». Критерий «следующий тест дешевле полной разработки» оценивает этап; риск «игнорирование существующей альтернативы» остаётся блокером.
Финальная запись «проверка продуктовой проблемы» объединяет «минимальная проверка спроса», критерий «условие остановки задано заранее» и риск «игнорирование существующей альтернативы». Изменение «минимальная проверка спроса» переводит вывод «проверка продуктовой проблемы» в исторический статус.
Критерии качества
Критерии темы «проверка продуктовой проблемы» оцениваются раздельно. Средний балл «проверка продуктовой проблемы» не отменяет критический дефект.
Критерий 1: есть несколько независимых типов свидетельств. В теме «проверка продуктовой проблемы» признак относится к «текущая альтернатива». Действие «проверить готовность совершить действие» подтверждает его; риск «подтверждение только сотрудниками компании» проверяется отдельно.
Критерий 2: описано прошлое поведение. В теме «проверка продуктовой проблемы» признак относится к «стоимость проблемы». Действие «принять решение о следующем вложении» подтверждает его; риск «путаница интереса и поведения» проверяется отдельно.
Критерий 3: известна текущая альтернатива. В теме «проверка продуктовой проблемы» признак относится к «доступ к аудитории». Действие «провести интервью о конкретных эпизодах» подтверждает его; риск «игнорирование существующей альтернативы» проверяется отдельно.
Критерий 4: сегмент определён. В теме «проверка продуктовой проблемы» признак относится к «минимальная проверка спроса». Действие «проверить готовность совершить действие» подтверждает его; риск «опрос о желании функции» проверяется отдельно.
Критерий 5: следующий тест дешевле полной разработки. В теме «проверка продуктовой проблемы» признак относится к «наблюдаемое поведение». Действие «принять решение о следующем вложении» подтверждает его; риск «прототип до понимания причины» проверяется отдельно.
Критерий 6: условие остановки задано заранее. В теме «проверка продуктовой проблемы» признак относится к «частота ситуации». Действие «провести интервью о конкретных эпизодах» подтверждает его; риск «подтверждение только сотрудниками компании» проверяется отдельно.
User interviews используются в discovery для понимания опыта, потребностей, ценностей и контекста пользователей. основание
Ограничения применимости
Ограничения темы «проверка продуктовой проблемы» публикуются вместе с выводом. Контекст «проверка продуктовой проблемы» определяет допустимый перенос результата.
Ограничение 1: качественные данные не оценивают размер рынка точно. Ограничение «проверка продуктовой проблемы» относится к «стоимость проблемы». Перенос темы «проверка продуктовой проблемы» требует повторить действие «сопоставить сегменты».
Ограничение 2: ранние пользователи могут отличаться от массовых. Ограничение «проверка продуктовой проблемы» относится к «доступ к аудитории». Перенос темы «проверка продуктовой проблемы» требует повторить действие «принять решение о следующем вложении».
Ограничение 3: обязательная задача не всегда означает готовность платить. Ограничение «проверка продуктовой проблемы» относится к «минимальная проверка спроса». Перенос темы «проверка продуктовой проблемы» требует повторить действие «собрать сигналы из поддержки и аналитики».
Ограничение 4: корпоративная закупка отделена от поведения пользователя. Ограничение «проверка продуктовой проблемы» относится к «наблюдаемое поведение». Перенос темы «проверка продуктовой проблемы» требует повторить действие «провести интервью о конкретных эпизодах».
Ограничение 5: проверка проблемы не гарантирует успех решения. Ограничение «проверка продуктовой проблемы» относится к «частота ситуации». Перенос темы «проверка продуктовой проблемы» требует повторить действие «наблюдать текущий процесс».
Вывод
Тема «проверка продуктовой проблемы» связывает решение «какие свидетельства показывают, что люди уже сталкиваются с препятствием и пытаются его преодолеть» с проверяемым результатом. Комплект «проверка продуктовой проблемы» содержит вход, версию, отклонения и дату.
Критерий «есть несколько независимых типов свидетельств» направляет следующий шаг темы «проверка продуктовой проблемы». Риск «игнорирование существующей альтернативы» остаётся видимым после решения «проверка продуктовой проблемы».
Практика «проверка продуктовой проблемы» автоматизирует повторяемое измерение. Ответственный человек подтверждает границы «проверка продуктовой проблемы» при неполных данных или высокой цене ошибки.
