Артефакты: problem brief / PRD-lite
Артефакты Discovery: problem brief и PRD-lite
Section titled “Артефакты Discovery: problem brief и PRD-lite”Эта страница — короткий и понятный справочник по артефактам Discovery: problem brief и PRD-lite. Фокус на поиске проблем, проверке идей и фиксации ключевой информации. Подойдет и продактам на ходу, и командам, которые хотят навести порядок в процессе поиска ценности.
Что такое problem brief и зачем он нужен
Section titled “Что такое problem brief и зачем он нужен”Определение
Section titled “Определение”Problem brief — это одностраничный документ, который фиксирует суть бизнес-проблемы или неудовлетворенную потребность пользователя. Он появляется на самой ранней стадии Discovery, когда цель — отделить реальную проблему от подмены целей, поставить задачу так, чтобы команда и стейкхолдеры говорили на одном языке.
Зачем это нужно
Section titled “Зачем это нужно”Грамотный problem brief позволяет не тратить время на решения без важной причины. Он помогает зацементировать общий фокус: о какой проблеме идет речь, чем она подтверждена, какая есть гипотеза ценности, кто пострадает, если ничего не менять.
Пример: Problem brief для B2B SaaS
Section titled “Пример: Problem brief для B2B SaaS”Допустим, клиент не может быстро найти нужную аналитику по расходам внутри своей компании. В problem brief фиксируется:
Проблема — долгий поиск отчетов → менеджеры тратят слишком много времени → бизнес теряет деньги из-за ошибок.
Дополнительно: как проблема выявлена (интервью, аналитика), краткое описание масштаба, список пострадавших ролей.
PRD-lite: простая спецификация решения
Section titled “PRD-lite: простая спецификация решения”Что это такое
Section titled “Что это такое”PRD-lite — это укороченная версия Product Requirements Document, которая отражает только самое необходимое для быстрой проверки гипотезы. По сути, это логичное продолжение problem brief: команда ускоренно описывает, что и почему будет делать, чтобы быстро валидировать решение.
Почему не стандартный PRD
Section titled “Почему не стандартный PRD”Обычный PRD громоздок и тормозит дискавери. В PRD-lite вполне достаточно 1-2 страниц, где зафиксированы цель, ключевые требования, границы MVP, как успех будет измеряться и на чем NOT to do.
Пример: PRD-lite для нового фильтра в продукте
Section titled “Пример: PRD-lite для нового фильтра в продукте”Проблема — пользователи теряют сделки, потому что не могут быстро фильтровать заявки.
Решение — добавить визуальный фильтр по статусу заявки в основной список.
Метрика успеха — время до нахождения нужной заявки и доля пользователей, применивших фильтр в течение недели.
Как готовить и применять: чек-лист
Section titled “Как готовить и применять: чек-лист”Инструкция по подготовке
Section titled “Инструкция по подготовке”- Сначала зафиксируй проблему в problem brief.
- Проверь, что есть подтверждение из пользовательских интервью или аналитики.
- Уточни, какую цель и метрику успеха должен покрыть эксперимент.
- В PRD-lite коротко пропиши идею решения и почему именно так, укажи MVP, риски и то, что делать не будете.
- Покажи обе бумаги ключевым стейкхолдерам до старта разработки.
Мини-кейс:
Section titled “Мини-кейс:”В практиках discovery-продуктования команды делают такие документы в Notion/Confluence, собирая быстрые ссылки на источники данных, новые инсайты по мере продвижения — а не только единожды.
Ошибки и антипаттерны
Section titled “Ошибки и антипаттерны”Проблемы в реальности
Section titled “Проблемы в реальности”Часто ошибаются так:
— Путают формулировку проблемы с описанием желаемого решения
— Нет подтверждения проблемы (голая гипотеза без опоры)
— PRD-lite превращается в длинную простыню или теряет фокус ценности
— Пропускают коммуникацию с разработкой на старте, теряя детали
Пример из жизни:
Section titled “Пример из жизни:”Внутри команды решили, что юзеру неудобно вводить телефоны — и сразу начали делать автодополнение, не проверив, действительно ли это ключевая боль и часто ли вводят номера вручную.
Без фиксации конкретной проблемы команда легко уходит в производство ненужных фич
Мартин Каган, SVPG
Как выглядит хороший артефакт discovery
Section titled “Как выглядит хороший артефакт discovery”Принципы
Section titled “Принципы”— Ясно, зачем нужен документ: чтобы быстро зафиксировать/защитить гипотезу, а не ради галочки
— Достаточно объема для осознанного решения и планирования быстрых тестов
— Регулярное обновление. Актуальность важнее формата.
Мини-кейс:
Section titled “Мини-кейс:”Для потока discovery-экспериментов в B2B fintech все problem brief и PRD-lite складывались в одну базу, из которой легко выбрать старые инициативы, чтобы не плодить дубли и повторно использовать наработки.
Рекомендованные ссылки для дальнейшего чтения
Section titled “Рекомендованные ссылки для дальнейшего чтения”- Product Discovery Techniques — Google Devs
- Product Discovery Guide — Mind the Product
- How to Create a PRD that isn’t a Waste of Time — SVPG
1. Можно ли объединять problem brief и PRD-lite в один документ?
Section titled “1. Можно ли объединять problem brief и PRD-lite в один документ?”Да, если вопросов немного и аудитория компактная. Главное — не потерять структуру: сначала проблема, потом решение.
2. Когда нужен длинный PRD?
Section titled “2. Когда нужен длинный PRD?”Длинный PRD нужен для согласования масштабных проектов или регуляторных продуктов. В discovery 90% задач закрываются короткими версиями.
3. Кто отвечает за подготовку этих артефактов?
Section titled “3. Кто отвечает за подготовку этих артефактов?”Обычно продакт-менеджер или тимлид Discovery, но важно привлекать аналитиков и дизайнеров для обоснования проблем.
4. Можно ли совсем не писать документы в Discovery?
Section titled “4. Можно ли совсем не писать документы в Discovery?”Без хоть какого-то артефакта команда быстро теряет фокус. Даже минимум в формате заметки лучше, чем ничего.
5. Где вести такие артефакты: Figma, Notion, Google Docs?
Section titled “5. Где вести такие артефакты: Figma, Notion, Google Docs?”Зависит от культуры команды. Лучше так, чтобы легко комментировать, обновлять и делиться ссылками. Чаще всего — Notion или Confluence.
6. Какие хорошие примеры можно посмотреть?
Section titled “6. Какие хорошие примеры можно посмотреть?”Рекомендованы шаблоны от SVPG и сборники на Mind the Product (ссылки выше). Там есть реальные структуры и варианты для быстрых тестов.