Артефакты: problem brief / PRD-lite

Артефакт discovery должен сохранять логику решения: наблюдение, проблема, сегмент, доказательства, допущения и следующий тест. Если документ нельзя быстро обновить после нового факта или он не влияет на выбор команды, его форма стала важнее самой работы.

Что такое problem brief и зачем он нужен

Определение

Problem brief — это одностраничный документ, который фиксирует суть бизнес-проблемы или неудовлетворенную потребность пользователя. Он появляется на самой ранней стадии Discovery, когда цель — отделить реальную проблему от подмены целей, поставить задачу так, чтобы команда и стейкхолдеры говорили на одном языке.

Зачем это нужно

Грамотный problem brief позволяет не тратить время на решения без важной причины. Он помогает зацементировать общий фокус: о какой проблеме идет речь, чем она подтверждена, какая есть гипотеза ценности, кто пострадает, если ничего не менять.

Пример: Problem brief для B2B SaaS

Допустим, клиент не может быстро найти нужную аналитику по расходам внутри своей компании. В problem brief фиксируется:
Проблема — долгий поиск отчетов → менеджеры тратят слишком много времени → бизнес теряет деньги из-за ошибок.
Дополнительно: как проблема выявлена (интервью, аналитика), краткое описание масштаба, список пострадавших ролей.

PRD-lite: простая спецификация решения

Что это такое

PRD-lite — это укороченная версия Product Requirements Document, которая отражает только самое необходимое для быстрой проверки гипотезы. По сути, это логичное продолжение problem brief: команда ускоренно описывает, что и почему будет делать, чтобы быстро валидировать решение.

Почему не стандартный PRD

Обычный PRD громоздок и тормозит дискавери. В PRD-lite вполне достаточно 1-2 страниц, где зафиксированы цель, ключевые требования, границы MVP, как успех будет измеряться и на чем NOT to do.

Пример: PRD-lite для нового фильтра в продукте

Проблема — пользователи теряют сделки, потому что не могут быстро фильтровать заявки.
Решение — добавить визуальный фильтр по статусу заявки в основной список.
Метрика успеха — время до нахождения нужной заявки и доля пользователей, применивших фильтр в течение недели.

Как готовить и применять: чек-лист

Инструкция по подготовке

1. Сначала зафиксируй проблему в problem brief.
2. Проверь, что есть подтверждение из пользовательских интервью или аналитики.
3. Уточни, какую цель и метрику успеха должен покрыть эксперимент.
4. В PRD-lite коротко пропиши идею решения и почему именно так, укажи MVP, риски и то, что делать не будете.
5. Покажи обе бумаги ключевым стейкхолдерам до старта разработки.

Пример:

В практиках discovery-продуктования команды делают такие документы в Notion/Confluence, собирая быстрые ссылки на источники данных, новые инсайты по мере продвижения — а не только единожды.

Ошибки и антипаттерны

Проблемы в реальности

Часто ошибаются так:
— Путают формулировку проблемы с описанием желаемого решения
— Нет подтверждения проблемы (голая гипотеза без опоры)
— PRD-lite превращается в длинную простыню или теряет фокус ценности
— Пропускают коммуникацию с разработкой на старте, теряя детали

Пример из жизни:

Внутри команды решили, что юзеру неудобно вводить телефоны — и сразу начали делать автодополнение, не проверив, действительно ли это ключевая боль и часто ли вводят номера вручную.

Как выглядит хороший артефакт discovery

Принципы

— Ясно, зачем нужен документ: чтобы быстро зафиксировать/защитить гипотезу, а не ради галочки
— Достаточно объема для осознанного решения и планирования быстрых тестов
— Регулярное обновление. Актуальность важнее формата.

Пример:

Для потока discovery-экспериментов в B2B fintech все problem brief и PRD-lite складывались в одну базу, из которой легко выбрать старые инициативы, чтобы не плодить дубли и повторно использовать наработки.

Рекомендованные ссылки для дальнейшего чтения

1. Product Discovery Techniques — Google Devs
2. Product Discovery Guide — Mind the Product
3. How to Create a PRD that isn’t a Waste of Time — SVPG

FAQ

1. Можно ли объединять problem brief и PRD-lite в один документ?

Да, если вопросов немного и аудитория компактная. Главное — не потерять структуру: сначала проблема, потом решение.

2. Когда нужен длинный PRD?

Длинный PRD может быть оправдан для сложной межкомандной или регуляторной инициативы. В discovery начинайте с минимального документа, который сохраняет проблему, evidence, риски и следующий тест; расширяйте его, когда растут цена ошибки и число участников решения.

3. Кто отвечает за подготовку этих артефактов?

Обычно продакт-менеджер или тимлид Discovery, но важно привлекать аналитиков и дизайнеров для обоснования проблем.

4. Можно ли совсем не писать документы в Discovery?

Без хоть какого-то артефакта команда быстро теряет фокус. Даже минимум в формате заметки лучше, чем ничего.

5. Где вести такие артефакты: Figma, Notion, Google Docs?

Зависит от культуры команды. Лучше так, чтобы легко комментировать, обновлять и делиться ссылками. Чаще всего — Notion или Confluence.

6. Какие хорошие примеры можно посмотреть?

Рекомендованы шаблоны от SVPG и сборники на Mind the Product (ссылки выше). Там есть реальные структуры и варианты для быстрых тестов.