Problem Statement: как сформулировать проблему, чтобы команда не ушла в Solution Space
Подробное руководство по созданию Problem Statement — ключевого артефакта Discovery, который чётко определяет проблему без её решения и служит компасом для команды.
Problem Statement: как сформулировать проблему, чтобы команда не ушла в Solution Space
Одна из главных задач продакт-менеджера — удержать команду от преждевременного прыжка в Solution Space. Как только звучит «а давайте добавим кнопку», фокус смещается с реальной боли пользователя на обсуждение интерфейсов, технологий и сроков.
Problem Statement (формулировка проблемы) — это ключевой артефакт фазы Discovery, который служит «якорем» и не даёт команде сбиться с курса. Это короткое, но ёмкое описание проблемы, полностью очищенное от каких-либо намёков на решение.
Зачем нужен Problem Statement?
- Создаёт общий контекст. Гарантирует, что вся команда — от разработчиков до маркетологов — одинаково понимает, над какой проблемой работает.
- Защищает от «фабрики фич». Не позволяет добавлять задачи в бэклог только потому, что «это кажется хорошей идеей».
- Фокусирует на ценности. Напоминает, что цель — не «сделать фичу», а «решить проблему» и изменить поведение пользователя.
- Служит «бронёй» от стейкхолдеров. Вместо спора о вкусах и мнениях вы обсуждаете факты и данные, которые легли в основу
Problem Statement.
Шаблон Problem Statement в PTOS
Хороший Problem Statement должен отвечать на несколько ключевых вопросов, объединяя данные из WHAT-HOW-WHY анализа.
- Для [сегмент]
- в ситуации [сценарий/триггер]
- ломается [WHAT: наблюдаемый симптом]
- потому что [HOW: механизм/причина]
- из-за этого [последствие для пользователя]
- и это важно бизнесу, потому что [WHY: метрика/ставка]
- доказательства: [2-3 опоры: данные/саппорт/наблюдение]
Пример из практики
Давайте разберём на примере B2B CRM:
- Для новых менеджеров по продажам в первые 2 недели после найма,
- в ситуации «после первого звонка клиенту»,
- ломается фиксация следующего шага (35% лидов остаются без
next stepв течение 15 минут), - потому что форма создания задачи требует слишком много решений и не имеет «дефолтного» быстрого варианта,
- из-за этого менеджер откладывает задачу «на потом», забывает о ней, и лиды «остывают»,
- и это важно бизнесу, потому что мы теряем конверсию в сделку и удлиняем цикл продаж.
- доказательства: [аналитика воронок, жалобы руководителей отделов продаж, записи 5 интервью с новыми менеджерами].
Как это работает?
- Ни слова о решении. Заметьте, в этом
Problem Statementнет ни слова про «кнопки», «интеграции» или «редизайн». Он полностью сфокусирован на проблеме. - Опирается на факты. Он не просто говорит «менеджерам неудобно», а подкрепляет это конкретными данными (35% лидов) и доказательствами из разных источников (триангуляция).
- Объединяет пользователя и бизнес. Он связывает боль пользователя («теряю контроль над сделкой») с болью бизнеса («теряем конверсию»).
Вывод
Problem Statement — это ваш компас. Если после фазы Discovery вы не можете составить такой документ, значит, вы ещё не готовы переходить к поиску решений. Возвращайтесь к исследованию, пока не добьётесь кристальной ясности в понимании проблемы.
Этот простой, но мощный артефакт сэкономит вашей команде бесчисленные часы, потраченные на создание продуктов, которые никому не нужны.