Product one pager
Как сформировать описание продукта на одну страницу для всех стейкхолдеров
Содержание:
Что такое one pager
Чтобы понять, что такое One Pager, нужно понять, откуда мы пришли.
Во время классического Waterfal царил культ SRS (Software Requirements Specification). Это были громадные документы на сотни страниц, которые писались месяцами дотого, как была написана первая строчка кода. Логика была проста: если мы опишем всё на бумаге, мы избежим ошибок.
Спойлер: это не сработало.
Мир менялся слишком быстро.
Пока вы дописывали страницу 142 про валидацию поля ввода email, рынок уже ушел вперед, конкуренты выпустили аналог, а технологии устарели.
Agile попытался убить документацию (Работающий продукт важнее исчерпывающей документации), но качнул маятник в другую крайность, в хаос. Команды начали пилить фичи без понимания Зачем. Jira-тикеты стали самоцелью. А документации вообще нет. Только пытаться искать знания в тикетах Jira.
One pager
One Pager (ванпейджер, одностраничник) появился как эволюционный ответ на этот хаос. Это золотая середина между отсутствием документации и бюрократическим адом. Это стратегический документ, который умещается на одной (максимум двух) страницах и отвечает на главные вопросы:
Что мы делаем,
Зачем мы это делаем,
Как мы поймем, что победили.
Это не ТЗ. Это питч.
Критически важно понимать разницу.
ТЗ (Техническое задание)- это инструкция для исполнителя.
ТЗ отвечает на вопрос Как? и Что именно? в мельчайших деталях.
One Pager - это коммерческое предложение вашей идеи, адресованное команде, бизнесу и самому себе. Он отвечает на вопрос Зачем? и Стоит ли игра свеч?.
Как этот вопрос закрыл Amazon
Корни современной популярности One Pager и нарративных документов уходят в корпоративную культуру Amazon.
Джефф Безос, как известно, совершил революцию в менеджменте, запретив презентации в PowerPoint на совещаниях.
Почему? Потому что слайды с буллитами (bullet points) упрощают мысль до абсурда.
Вместо слайдов сотрудники Amazon пишут
6-pagers (шестистраничные нарративные документы) или
Пресс-релизы (PR/FAQ) будущего продукта.
Идея проста: напиши пресс-релиз так, будто продукт уже запущен.
Что вы скажете клиентам?
Чем они будут восхищаться?
Если вы не можете написать крутой пресс-релиз, значит, продукт не стоит делать.
One Pager - это младший брат этого подхода, адаптированный для более быстрых циклов разработки и меньших инициатив.
Если вы не можете объяснить суть своей идеи на одной странице, значит, вы сами её до конца не понимаете.
Отличия от других документов
Устоявшихся терминов нет, поэтому каждый называет документы как хочет. Часто One Pager даже называют PRD на диете.
Нужны четкие границы, где какой документ используется:
One Pager рождается до PRD.
Это фильтр. Если One Pager не прошел защиту (команда сказала это бред, или бизнес сказал денег нет, или юристы сказали это незаконно), то писать PRD не нужно.
Вы сэкономили себе и команде 20-40 часов работы над детальными требованиями. В этом его главная ценность провалиться как можно быстрее и дешевле. Дешевле переписать страницу текста, чем переписать код.
Во время классического Waterfal царил культ SRS (Software Requirements Specification). Это были громадные документы на сотни страниц, которые писались месяцами дотого, как была написана первая строчка кода. Логика была проста: если мы опишем всё на бумаге, мы избежим ошибок.
Спойлер: это не сработало.
Мир менялся слишком быстро.
Пока вы дописывали страницу 142 про валидацию поля ввода email, рынок уже ушел вперед, конкуренты выпустили аналог, а технологии устарели.
Agile попытался убить документацию (Работающий продукт важнее исчерпывающей документации), но качнул маятник в другую крайность, в хаос. Команды начали пилить фичи без понимания Зачем. Jira-тикеты стали самоцелью. А документации вообще нет. Только пытаться искать знания в тикетах Jira.
One pager
One Pager (ванпейджер, одностраничник) появился как эволюционный ответ на этот хаос. Это золотая середина между отсутствием документации и бюрократическим адом. Это стратегический документ, который умещается на одной (максимум двух) страницах и отвечает на главные вопросы:
Что мы делаем,
Зачем мы это делаем,
Как мы поймем, что победили.
Это не ТЗ. Это питч.
Критически важно понимать разницу.
ТЗ (Техническое задание)- это инструкция для исполнителя.
ТЗ отвечает на вопрос Как? и Что именно? в мельчайших деталях.
One Pager - это коммерческое предложение вашей идеи, адресованное команде, бизнесу и самому себе. Он отвечает на вопрос Зачем? и Стоит ли игра свеч?.
Как этот вопрос закрыл Amazon
Корни современной популярности One Pager и нарративных документов уходят в корпоративную культуру Amazon.
Джефф Безос, как известно, совершил революцию в менеджменте, запретив презентации в PowerPoint на совещаниях.
Почему? Потому что слайды с буллитами (bullet points) упрощают мысль до абсурда.
Вместо слайдов сотрудники Amazon пишут
6-pagers (шестистраничные нарративные документы) или
Пресс-релизы (PR/FAQ) будущего продукта.
Идея проста: напиши пресс-релиз так, будто продукт уже запущен.
Что вы скажете клиентам?
Чем они будут восхищаться?
Если вы не можете написать крутой пресс-релиз, значит, продукт не стоит делать.
One Pager - это младший брат этого подхода, адаптированный для более быстрых циклов разработки и меньших инициатив.
Если вы не можете объяснить суть своей идеи на одной странице, значит, вы сами её до конца не понимаете.
Отличия от других документов
Устоявшихся терминов нет, поэтому каждый называет документы как хочет. Часто One Pager даже называют PRD на диете.
Нужны четкие границы, где какой документ используется:
Характеристика | One Pager | PRD | Tech Spec |
Основная цель | Продать идею, синхронизировать контекст, получить "ОК" на старт (Go/No-Go решение). | Описать поведение системы, функциональные требования, краевые случаи, логику работы. | Постановка задачи разработчику: что конкретно кодить в этом спринте. |
Аудитория | Стейкхолдеры, вся команда (для понимания контекста), маркетинг. | Дизайнеры, QA инженеры, разработчики, аналитики. | Разработчики |
Объем | 1-2 страницы А4. | 5-20 страниц | Абзац текста + ссылки на One Pager/PRD + макеты. |
Время жизни | Актуален в начале (Discovery). Обновляется редко, только если меняется стратегия. | Живой документ, меняется постоянно | Живет ровно один спринт, после закрытия умирает в архиве. |
Уровень детализации | Мы строим мост через реку, чтобы сократить путь на 10 км и сэкономить логистике $1M в год | Мост бетонный, ширина 12м, нагрузка 50т, перила высотой 1.2м, освещение LED | Залить опору №3 бетоном марки М500 в соответствии с чертежом А-12 |
One Pager рождается до PRD.
Это фильтр. Если One Pager не прошел защиту (команда сказала это бред, или бизнес сказал денег нет, или юристы сказали это незаконно), то писать PRD не нужно.
Вы сэкономили себе и команде 20-40 часов работы над детальными требованиями. В этом его главная ценность провалиться как можно быстрее и дешевле. Дешевле переписать страницу текста, чем переписать код.
Структура one pager
Product one pager от Lenny (Источник)
Нет единого стандарта, высеченного в камне.
Но есть джентльменский набор блоков, без которых ваш документ будет просто бумажкой с хотелками.
Если вы пропустите Риски, вас уничтожат на ревью.
Если забудете Метрики, вы не поймете, победили вы или проиграли.
Целевая структура базируется на здравом смысле и принципе
"Problem - Solution - Impact".
Мета-данные (Header) - Паспорт документа
Скучно, но жизненно необходимо. Чтобы через год новые сотрудники могли раскопать этот документ и понять, кто его породил и живо ли это вообще.
Название инициативы:
Четкое и понятное (не "Проект Х", а "Внедрение оплаты через единый QR").
Авторы (Owners): PM, Tech Lead, Designer.
К кому бежать с вопросами?
Стейкхолдеры: Кто платит / кто принимает результат?
Статус: Draft (Черновик) / In Review (На ревью) / Approved (Принято) / Deprecated (Отменено/Устарело).
Дата последнего обновления: Документы тухнут быстрее рыбы.
Ссылки: На PRD (если есть), Figma, Epic в Jira.
Блок 1: Проблема - 30% места. Самое важное.
Это фундамент.
Если вы облажаетесь здесь, всё остальное (решение, дизайн, код) не имеет значения. Решение правильной проблемы плохо - это полбеды. Решение неправильной проблемы идеально - это катастрофа.
Контекст
Что происходит в мире/продукте сейчас? Опишите статус-кво.
Наши пользователи жалуются, что чекаут занимает 5 минут. Рыночный стандарт - 2 минуты. Конкуренты внедрили one-click оплату.
Проблема
Четкая формулировка боли.
Плохо: Нам нужно внедрить Apple Pay. (Это решение, а не проблема).
Хорошо: Когда я стою на кассе с телефоном (ситуация), я хочу оплатить заказ одной кнопкой (мотивация), чтобы не искать пластиковую карту и не задерживать очередь (результат).
Доказательства
Почему вы не галлюцинируете?.
Это ваш щит от мнений в духе "Я так чувствую".
Качественные: Мы провели 7 интервью, 5 пользователей сказали, что уходят, потому что сложно. Цитаты из тикетов саппорта. Видео с UX-тестов.
Количественные: По данным Amplitude, 30% отвала на шаге ввода карты. Конверсия в оплату упала на 5% после редизайна.
Блок 2: Решение - 40% места.
Здесь вы описываете суть вашей ставки .
Гипотеза: Формула: "Мы верим, что [изменение] для [персоны] приведет к [результату], потому что [причина/инсайт]."
Описание решения: Не надо описывать JSON-схемы и API-методы. Опишите пользовательский опыт.
Пользователь видит кнопку "Купить в 1 клик". При нажатии подтягиваются данные из профиля. Если данных нет - модалка с вводом.
Объем работ
In Scope (Must Have / MVP): Что делаем в первой версии. Жизненно необходимо для проверки гипотезы.
Out of Scope (Won't Have): Что мы ТОЧНО НЕ делаем сейчас. Это критически важно!
Это ваша защита от "А давайте еще добавим смену аватарки, раз уж мы залезли в профиль". Пропишите это явно.
Дизайн/Референсы: Ссылка на Figma (даже на наброски на салфетке или вайрфреймы). Лучше один раз увидеть. Если нет дизайна - вставьте скриншоты конкурентов.
Блок 3: Успех и риски - 30% места.
Бизнес-часть. Здесь вы продаете идею за деньги или метрики.
Метрики успеха:
Primary Metric: Checkout Conversion Rate.
Secondary Metric: Time to checkout.
Counter Metrics (Что мы боимся сломать):
Количество обращений в саппорт (не должно вырасти),
Fraud Rate(не должен вырасти).
Если вы вырастите конверсию, но увеличите фрод, вас уволят.\
Риски и митигация
Покажите, что вы взрослый человек и понимаете, что мир не идеален. Проведите Pre-mortem (Предсмертный анализ)
Технические:
Не кому будет делать правки в коде, который написали 5 лет назад, а все разработчики, которые его писали уволились -> Закладываем +50% времени на рефакторинг и тесты.
Бизнесовые:
Партнер поднимет комиссию -> Подписываем фикс прайс на год.
Юридические:
GDPR -> Консультация с юристами пройдена.
План
Не диаграмма Ганта по часам, а вехи (Milestones).
Q1 - Дизайн и Прототип, Q2 - MVP на 5% юзеров, Q3 - Раскатка на 100%.
Итого:
Общий принцип: картинка стоит 1000 строк кода. Скриншот "Как есть сейчас" с красными стрелками, указывающими на проблемы, работает лучше, чем страница текста с описанием багов.
Структура:
Но есть джентльменский набор блоков, без которых ваш документ будет просто бумажкой с хотелками.
Если вы пропустите Риски, вас уничтожат на ревью.
Если забудете Метрики, вы не поймете, победили вы или проиграли.
Целевая структура базируется на здравом смысле и принципе
"Problem - Solution - Impact".
Мета-данные (Header) - Паспорт документа
Скучно, но жизненно необходимо. Чтобы через год новые сотрудники могли раскопать этот документ и понять, кто его породил и живо ли это вообще.
Название инициативы:
Четкое и понятное (не "Проект Х", а "Внедрение оплаты через единый QR").
Авторы (Owners): PM, Tech Lead, Designer.
К кому бежать с вопросами?
Стейкхолдеры: Кто платит / кто принимает результат?
Статус: Draft (Черновик) / In Review (На ревью) / Approved (Принято) / Deprecated (Отменено/Устарело).
Дата последнего обновления: Документы тухнут быстрее рыбы.
Ссылки: На PRD (если есть), Figma, Epic в Jira.
Блок 1: Проблема - 30% места. Самое важное.
Это фундамент.
Если вы облажаетесь здесь, всё остальное (решение, дизайн, код) не имеет значения. Решение правильной проблемы плохо - это полбеды. Решение неправильной проблемы идеально - это катастрофа.
Контекст
Что происходит в мире/продукте сейчас? Опишите статус-кво.
Наши пользователи жалуются, что чекаут занимает 5 минут. Рыночный стандарт - 2 минуты. Конкуренты внедрили one-click оплату.
Проблема
Четкая формулировка боли.
Плохо: Нам нужно внедрить Apple Pay. (Это решение, а не проблема).
Хорошо: Когда я стою на кассе с телефоном (ситуация), я хочу оплатить заказ одной кнопкой (мотивация), чтобы не искать пластиковую карту и не задерживать очередь (результат).
Доказательства
Почему вы не галлюцинируете?.
Это ваш щит от мнений в духе "Я так чувствую".
Качественные: Мы провели 7 интервью, 5 пользователей сказали, что уходят, потому что сложно. Цитаты из тикетов саппорта. Видео с UX-тестов.
Количественные: По данным Amplitude, 30% отвала на шаге ввода карты. Конверсия в оплату упала на 5% после редизайна.
Блок 2: Решение - 40% места.
Здесь вы описываете суть вашей ставки .
Гипотеза: Формула: "Мы верим, что [изменение] для [персоны] приведет к [результату], потому что [причина/инсайт]."
Описание решения: Не надо описывать JSON-схемы и API-методы. Опишите пользовательский опыт.
Пользователь видит кнопку "Купить в 1 клик". При нажатии подтягиваются данные из профиля. Если данных нет - модалка с вводом.
Объем работ
In Scope (Must Have / MVP): Что делаем в первой версии. Жизненно необходимо для проверки гипотезы.
Out of Scope (Won't Have): Что мы ТОЧНО НЕ делаем сейчас. Это критически важно!
Это ваша защита от "А давайте еще добавим смену аватарки, раз уж мы залезли в профиль". Пропишите это явно.
Дизайн/Референсы: Ссылка на Figma (даже на наброски на салфетке или вайрфреймы). Лучше один раз увидеть. Если нет дизайна - вставьте скриншоты конкурентов.
Блок 3: Успех и риски - 30% места.
Бизнес-часть. Здесь вы продаете идею за деньги или метрики.
Метрики успеха:
Primary Metric: Checkout Conversion Rate.
Secondary Metric: Time to checkout.
Counter Metrics (Что мы боимся сломать):
Количество обращений в саппорт (не должно вырасти),
Fraud Rate(не должен вырасти).
Если вы вырастите конверсию, но увеличите фрод, вас уволят.\
Риски и митигация
Покажите, что вы взрослый человек и понимаете, что мир не идеален. Проведите Pre-mortem (Предсмертный анализ)
Технические:
Не кому будет делать правки в коде, который написали 5 лет назад, а все разработчики, которые его писали уволились -> Закладываем +50% времени на рефакторинг и тесты.
Бизнесовые:
Партнер поднимет комиссию -> Подписываем фикс прайс на год.
Юридические:
GDPR -> Консультация с юристами пройдена.
План
Не диаграмма Ганта по часам, а вехи (Milestones).
Q1 - Дизайн и Прототип, Q2 - MVP на 5% юзеров, Q3 - Раскатка на 100%.
Итого:
Общий принцип: картинка стоит 1000 строк кода. Скриншот "Как есть сейчас" с красными стрелками, указывающими на проблемы, работает лучше, чем страница текста с описанием багов.
Структура:
- Контекст
- Проблема
- Доказательства
- Гипотеза
- Описание решения
- Объем работ
- Метрики успеха
- Риски и митигация
- План
Промпты для создания Product one pager и примеры
Набор промптов для составления каждого из разделов внутри product one pager, для основы + примеры.
Как вам материалы?
Об авторе:
Еще материалы по теме продакт менеджмента: