Этот материал - часть практического курса “ProductDo: Tech для продакта”
Один из скиллов опытного продакта - быстро сформулировать главную суть продукта (для кого, зачем, как мерить и тд) и прикинуть его сложность (сервисы, архитектура, особенности и тд). Это позволяет переработать много исследований в простой и понятный документ Full Product Review, который уже можно (с разной степенью погружения) рассказывать стейкхолдерам и использовать для приблизительного моделирования разработки.
Шаблон применим для проектов любой величины, будет просто меняться уровень детализации и название документа - “сложные” вопросы останутся те же:
В реальной жизни финальный документ представляет собой либо 3-5 страниц текстового дока, либо 7-10 слайдов презентации. Для его написания как раз и используется шаблон:
| Название секции | Важность | Что тут надо расписать |
|---|---|---|
| Elevator pitch (краткое описание) | Required | Короткое и ясное саммари всего документа. Представь, что рассказываешь проект директору (это частая ситуация) и у тебя 30 секунд - как выделить главную суть? Если не можешь пока выделить суть - не торопись презентовать. |
| Context (контекст) | Required | Представь себя на месте человека, который видит твою тему в первый раз. Какие факты нужно ему рассказать, чтобы обрисовать текущее положение дел? Ты можешь тут рассказать о предыдущих попытках решить проблему, упомянуть релевантные соседние проекты или, например, рассказать, что команда делала по этой же теме в прошлом году. |
| Problem/requirements (бизнес-проблема/требования) | Required | Что за проблему пользователей/клиентов мы решаем (Пример)? Зачем надо вообще что-то решать? Почему это проблема? Какая у нее цена (1 пользователь или 1000, 1$ или 100000$). Пытайся найти самую суть. |
| Goals (цели) | Required | Что мы планируем по поводу этих проблем сделать. Ты можешь задать либо OKR, либо в более визуальной форме сделать слайд “Before → After”. |
| Metrics/KPI (метрики) | Required | Как мы будем измерять бизнес-успех. Обычно идет рядом с целью. Без метрик любые стратегии это просто теории. Продакт должен уметь сказать что-то вроде: “Главная метрика будет Х (потому что ХХХ), прокси-метрики будут Y и Z (потому что XXX), и я планирую поднять X со значения A до значения Б к концу года”. Страшно обещать? Значит стратегия еще не проработана до конца. |
| ProRoadmap (роадпама) | Required | Критически важно связать цель с тактикой, иначе вам просто никто не поверит. Искусство тут в том, чтобы дать достаточно деталей (например, 20 планируемых экспериментов в течение года), но при этом не перегрузить читателя (например, разбив эксперименты на категории). |
| MVP (Minimal Viable Product) | Optional | Для проектов с уже понятной структурой (например, команды, которая ставит цель на следующий год) MVP является просто “левой частью роадмапы”. Для новых запусков (например, новой линейки продукта) MVP должен отвечать на вопрос: что является абсолютным минимумом проверки описанной стратегии на прочность? Может, достаточно лендинга? Или нужен минимальный функционал приложения? |
| Non-goals (не цели) | Optional | Что мы не планируем делать в рамках этого проекта. Обычно используется, чтобы от вас не ожидали лишнего. |
| Strategic fit | Optional | Как проект соответствует целям компании |
| Background research | Optional | Обычно добавляется в конец дока ссылкой, чтобы показать, что мы наресерчили. Важно, чтобы не изобрести велосипед и отталкиваться от данных, а не иллюзий отдельного продакта. |
| User flows | Optional | Часто подкрепляет requirements секцию визуально. |
| Название секции | Важность | Что тут надо расписать |
|---|---|---|
| High-level architecture (высокоуровневая архитектура) | Required | Рисуем и описываем основные элементы, сервисы и зависимости, нужные для реализации заданной бизнес-логики. |
| Tech MVP and next steps (MVP и следующие стадии) | Required | Какой функционал/сервисы входит в первую итерацию и какие (примерные) дальнейшие шаги. Если проект простой, то определения MVP из бизнес секции выше достаточно. Для сложных проектов необходимо будет доформулировать MVP с точки зрения технических реалий (например, описать несколько API-методов и указать ограничения по безопасности). |
| Main SLIs/SLOs (главные технические метрики) | Required | Выделяем и простым языком объясняем главные метрики уровня сервисов. Связываем их с основными метриками (обычно в развернутом дереве метрик). |
| Client-side tech requirements (особенности клиентской стороны) | Optional | Упоминаем особенности клиентской интеграции: количество клиентов, их требования, трафик. |
| Dependencies (особенности зависимостей) | Optional | Упоминаем особенности интеграции зависимостей: автономность сервиса, критичность зависимостей, сложность интеграции. |
| Resilience requirements (требования к устойчивости) | Optional | Какие есть нефункциональные требования устойчивости/мониторингу? |
| Technology state (Особенности технологий) | Optional | Будем ли мы использовать новые технологии (например, языки/фреймворки)? Насколько подготовленная команда? Насколько автоматизирована инфраструктура? Каково текущее состояние архитектуры? Какие требования к будущему продукта? |
| Security requirements (требования к безопасности) | Optional | Какие есть нефункциональные требования безопасности: защита данных, fraud appetite. |
| Other non-functional requirements (другие нефункциональные требования) | Optional | На что еще нужно обратить особенное внимание: compliance, legal, operational, etc. |
| Tech Insights/Platformisation | Optional | Видишь ли ты "шорткаты", которые при правильном подходе могут быть в будущем использованы для бизнеса? Может ли твой сервис превратиться в платформу? |
| Название секции | Важность | Что тут надо расписать |
|---|---|---|
| Stakeholder matrix (матрица стейкхолдеров) | Optional | Кто участвует в проекте и в какой роли (команда разработчик, команда-клиент, команда-зависимость и тд) |
| Launch details | Optional | Рынки, даты, объемы (часто конфидециальная инфа). |
| Investments (требуемые ресурсы) | Optional | Требуемое количество программистов, дизайнеров, денег, времени, тд. для осуществления идеи. |