Problem framing и assumptions
Что важно знать о Problem framing и assumptions в Discovery
Section titled “Что важно знать о Problem framing и assumptions в Discovery”В продуктовой разработке ценится не скорость запуска, а попадание в цель — решение реальных проблем пользователей. Для этого есть две фундаментальные практики: problem framing и работа с assumptions. Ниже — разбор того, как ими пользоваться в фазе discovery, чтобы твоя команда реально двигалась к ценности, а не строила догадки.
Зачем нужны problem framing и assumptions
Section titled “Зачем нужны problem framing и assumptions”Почему просто перейдём к решению — плохая стратегия
Section titled “Почему просто перейдём к решению — плохая стратегия”Любой продуктовой команде знаком соблазн: быстрее в прототипирование и пилот. Но без ясного определения проблемы легко строить ненужные фичи. Фрейминг и критика гипотез помогают направить усилия в правильную точку.
Пример из практики
Команда B2B SaaS решила добавить чат-бота для поддержки на сайт. Без четкого понимания проблемы через месяц получили низкий usage. Фрейминг показал: у пользователей была не нехватка поддержки, а неудобная навигация в продукте. Фокусировка на другой проблеме сохранила месяцы работы и бюджет.
Роль assumptions в discovery
Section titled “Роль assumptions в discovery”Assumptions — то, что ты считаешь правдой без доказательств. Без проверки они превращаются в ловушки и дорогостоящие ошибки.
Мини-кейс
Команда мобилки «здоровье» предположила, что пользователи не заполняют дневник из-за слишком длинной формы. Убрали лишнее, но всё равно retention не вырос. Потом интервьировали пользователей и выяснили: дело в неровных напоминаниях. Проверка assumptions изменила весь фокус discovery-итерации.
Самое опасное — делать красиво не то, что действительно нужно.
— Мартин Каган, Inspired
Как грамотно формулировать проблему
Section titled “Как грамотно формулировать проблему”Определяй, что блокирует пользователя, а не что хочется сделать
Section titled “Определяй, что блокирует пользователя, а не что хочется сделать”Фрейми проблему в формате: «Пользователь испытывает X, потому что Y, что приводит к Z».
Реализация в командах
На старте discovery сессии команда выписывает не фичи (‘добавить кнопку’), а сценарии: покупатель бросает корзину на этапе оплаты, потому что боится ошибочного списания. Это помогает помнить: фокус — всегда на пользователе, не на технологиях.
Хороший problem framing: примеры и ошибки
Section titled “Хороший problem framing: примеры и ошибки”Хорошо:
Пользователь часто теряет доступ к чату поддержки, потому что неясно, где и когда он работает, из-за чего затягивается решение вопроса.
Плохо:
Давайте сделаем онлайн-чат без расписания работы.
Антипаттерны:
Переход к решению сразу (feature framing), нечёткая формулировка (‘сделать удобнее’, ‘добавить что-то’).
Нет смысла запускать решение, если потребность осталась неясной
— Product Team, Atlassian
Как работать с assumptions
Section titled “Как работать с assumptions”Как найти assumptions и приоритизировать их
Section titled “Как найти assumptions и приоритизировать их”Для каждой формулированной проблемы выпиши, что команда считает самоочевидным: что пользователь хочет, знает, умеет.
Дальше применяй matrix impact/risks: если assumption окажется ложным, насколько сильно это влияет на успех решения?
Применение:
В группе обсуждают: предполагаем, что клиенты купят подписку ради новой функции. Ставим это на первое место для проверки через custdev или эксперимент.
Как проверять assumptions — быстрые техники
Section titled “Как проверять assumptions — быстрые техники”1. User interviews — дойти до корня, услышать реальную мотивацию.
2. Fake door experiments — дать возможность нажать-пробовать недоступную фичу и измерить интерес.
3. Анализ данных — подтвердить гипотезу действиями, а не словами.
Мини-кейс
В продукте обнаружили: пользователи якобы хотят шаблоны. Кнопка «Шаблоны» ведёт на заглушку с анкетой. Только 4% кликов — остальные проходят мимо. Значит, assumption о высокой потребности не подтвердился.
Как документировать работу: фреймворки и форматы
Section titled “Как документировать работу: фреймворки и форматы”Форматы problem statement
Section titled “Форматы problem statement”Есть стандартные канвы и формулы:
Jobs To Be Done:
Когда [ситуация], я хочу [мотивация], чтобы [ценность].
HMW (How might we…):
Как мы можем помочь [персонажу] сделать [что-то], чтобы получить [ценность]?
Пример JTBD в реальной команде
Когда пользователь возвращается в сервис после перерыва, он хочет быстро вспомнить, что запланировано, чтобы не тратить время на навигацию.
Простой шаблон для assumptions
Section titled “Простой шаблон для assumptions”Обычно записывают:
Мы считаем, что [допущение], и если мы ошибаемся, произойдет [негативное последствие].
Пример:
Мы считаем, что пользователи захотят запускать экспорт, а если ошибаемся — инвестируем время впустую, а фича не будет востребована.
Доп. чтение про фреймворки смотри на ProductPlan
Как не скатиться в ловушки
Section titled “Как не скатиться в ловушки”Типовые ошибки
Section titled “Типовые ошибки”1. Начать строить решение до проверки проблемы
2. Не отделять личные мнения от пользовательских инсайтов
3. Не фиксировать assumptions явно
4. Считать, что любой assumption подтвердился после одного интервью
Антипаттерны команд
Section titled “Антипаттерны команд”— На встрече обсуждают «что бы вы сами хотели», не опираясь на данные
— Не задаются вопросом: «Что будет, если assumption неверен?»
Что конкретно дает problem framing на старте discovery?
Он фокусирует команду на реальной потребности, позволяет не увлекаться решениями, которые не нужны пользователям.
Как понять, что assumption критичен для успеха?
Оцени риск: если это допущение неверно — команда потеряет больше всего времени или ресурсов на ненужной работе.
Как убедиться, что проблема отражает реальное поведение пользователей?
Наблюдай за пользователями, общайся с ними, ищи подтверждение в данных и аналитике.
Допустимо ли менять problem framing после первых этапов discovery?
Да, это нормальная практика. Часто фокус смещается после первых интервью, экспериментов или анализа.
Когда assumptions можно считать проверенными?
Когда получены независимые подтверждения через разные методы: интервью, эксперименты, метрики.
Где найти шаблоны и чек-листы по теме?
Рекомендуются Atlassian Team Playbook, ProductPlan. Там есть структуры для фрейминга и валидации допущений.