За всё время работы от associate product manager до директора по продукту менялось очень многое, но одна вещь оставалась неизменной и за все эти годы она прошла проверку временем, задачами, процессами, руководителями, целями — это бизнес описание задачи или product brief. Сегодня я расскажу об инструменте, который я использовал с первого дня как стал продактом и использую его до сих пор и лично, и для подчинённых продактов.

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

Product brief состоит из 5 полей и содержит минимум информации. Одновременно с этим он имеет своё преимущество — в нём нет специфики конкретной команды или компании. Это значит что в него не вмешиваются процессы и другая непродуктовая, юридическая, маркетинговая и т.п. составляющие. Это чисто продуктовый шаблон и состоит он из пяти пунктов:

1. Аудитория

2. Проблема(ы)/Точка(и) роста

3. Гипотеза(ы)

4. Решение

5. Метрики

Я пишу эту статью в самолёте, так что представлю себя продактом, который работает в авиакомпании. Допустим, что наша цель в 2024 году — это увеличить лояльность. Возьму себе направление b2b, то есть компании, которые отправляют своих сотрудников в командировки и покупают для них авиабилеты.

ЗЫ: пример с самолётом "не боевой". Цель статьи не оценить инициативу с розетками, а на её примере показать фреймворк.

Итак, у меня есть метрика лояльности, которую мне надо качнуть. После серии брейнштормов/исследований/чтения статей/подставь нужное, один из инсайтов звучит так: компании стремятся к эффективности и хотели бы оптимизировать рабочие часы в период командировок. Зацеплюсь за это и опишу продуктовый бриф для инициативы добавления розеток на борт самолёта, чтобы сотрудники с ноутбуками могли не переживать за заряд батареи и работать на протяжении всего полёта.

Ниже опишу 5 пунктов продуктового брифа и раскрою их суть с примерами.

Аудитория

Раздел описывает объем людей, на которых сфокусировано ваше решение. Раздел группирует людей по наличию "боли" и описывает объём такого сегмента. Иногда может обозначать объём рынка, на который мы хотим выйти. Если по какой-то причине нет возможности определить размер сегмента, то можно описать персону и её поведение. Словесное описание типа «мужчины с двумя и более детьми» уже поможет читателю представить портрет, с которым предстоит работать. Всплывут какие-то ассоциации, появится нужный контекст. В моём случае это будет выглядеть так:

Аудитория
Компании-клиенты, которые оформляют командировочные рейсы > 4.5 часа. Сейчас это Z клиентов, что равняется Х пассажиров или Y рейсов ежегодно.

В данном случае я не могу указать размер аудитории, просто потому что я совершенно его не представляю, но уже из такого короткого описания понятно о ком я говорю. А еще из такого описания понятно, какую статистику надо собрать, чтобы дописать задачу.

Кто-то может возразить, что странно начинать описание задачи с аудитории, когда именно гипотеза первична, а аудитория — это её уточнение. Такое замечание логично, но не всегда работает. Обычно люди встречают сопротивление, когда всё начинается с гипотезы. Я объясняю это так:

1. Тяжело представить проблему без человека. В мире так много всего происходит, что каждая гипотеза кажется каплей в море и формулировка гипотезы, в первую очередь в головах слушателей, применяется сразу ко всем клиентам что “в общей массе” может выглядеть неинтересно.

2. Люди хорошо вовлекаются в числа. Вспомните сами как звучат заголовки 21 века в контенте: 5 способов…, топ-10 лучших…, 3 вещи, которые надо знать…, и так далее.

3. Аудитория быстро даёт понять на какой сегмент из стратегии компании вы работаете. Если перевозчик поставил себе цель развивать в этом году b2b отношения, то даже большой сегмент b2c будет ему менее интересен. Описать аудиторию — значит сфокусировать внимание слушателя на понятном портрете, что позволит лучше усваивать дальнейшую информацию.

Раздел группирует людей по наличию "боли" и описывает объём такого сегмента.

Проблема/Точка роста

Это хлеб продакта. На мой взгляд самое важное в его работе — формулирование проблемы. Чёткая и ёмкая проблема показывает, что вы понимаете пользователя, и позволяет быстро передавать смысл вашей инициативы между людьми. Это сильно упрощает защиту вышей инициативы перед руководителями, а так же помогает команде лучше представлять какую задачу вы решаете для клиента. Такая сплочённость часто сокращает t2m.

Характерные черты хорошо написанной проблемы:

• состоит из одного-двух предложений

• проблема имеет последствия

• проблема — это всегда подтверждённый факт

Проблема может быть заменена на точку роста. Это актуально в тех случаях когда у вас всё хорошо в продукте, но вы понимаете, что если оптимизировать, например, канал привлечения, то у вас будет больше лидов за меньшую цену. Вы не рассматриваете стоимость как высокую, потому что деньги есть, и компанию текущее положение дел устраивает. Так что проблемой это не назвать, а вот точкой роста — можно.

Проблема
Когда сотрудник находится в долгом перелёте, то ноутбук может разрядится, а это значит, что он не сможет работать. Для работодателя это фактически убытки.

Характерные черты хорошо написанной проблемы:

• состоит из одного-двух предложений

• проблема имеет последствия

• проблема — это всегда подтверждённый факт

Гипотеза

Навык формулирования гипотезы хорошо показывать грейд продакта. Начинающие продакты частенько формулируют гипотезы в стиле “если мы покажем кнопку, то её будут нажимать, это увеличит конверсии, и мы заработаем денег.” Это не гипотеза, а факт: если что-то лежит на поверхности, это будет использовано. Ваши гипотезы должны описывать поведение человека в ситуации, в которую вы планируете его поставить. При этом гипотеза не должна спускаться до конкретного решения. В гипотезе всегда есть одна метрика. Гипотез, как кстати и проблем/точек роста, может быть несколько. Старайтесь формулировать гипотезу как утверждение, а не предположение. По опыту, это лучше усваивается в головах людей.

Гипотеза
Наличие розеток на борту — это сильный фактор при выборе перевозчика который положительно повлияет на среднее число билетов на b2b клиента.

Тут хочется остановиться и показать всю многоуровневость использования гипотез. Гипотеза — это следующий шаг после знания. Если строить гипотезу на гипотезе, это сильно увеличивает вероятность ошибки, потому Agile пропагандирует регулярные циклы обратной связи, а в продуктовой культуре есть такое определение как MVP.

Я сейчас опираюсь на знание, что мои b2b клиенты ценят операционную эффективность, и это есть в их KPI. Бывают случаи, когда вы вообще ничего не знаете, и тогда можно поставить задачу на исследование или самим его провести. Гипотеза в таком случае может звучать так: “HR в компаниях задумываются о качестве перелёта свои сотрудников, и цена не всегда является решающим фактором в выборе перевозчика”. Если же вы уже знаете что розетки — это важно, но не знаете какими они должны быть, то можно сказать “для бортов совершающих только внутренние рейсы по России будет достаточно сделать розетки 220 вольт” или “две розетки достаточно на ряд из четырёх кресел”. Если у вас уже есть розетки и вы хотите понять их ценность для клиента через исследование на исторических данных, то гипотеза может звучать как “люди, которые используют розетки, чаще выбирают нашу авиакомпанию”. Но на выбор, конечно, влияет много факторов, и дизайнить такое исследование и делать выводы надо аккуратно.

Также в разделе гипотез вы можете формулировать риски, например: “Борт имеет достаточно мощности, чтобы поддерживать активную работу устройства до 1 Кв на каждое сидение лайнера”.

Гипотеза — это следующий шаг после знания. Если строить гипотезу на гипотезе, это сильно увеличивает вероятность ошибки

Решение

Я всегда разделяю гипотезу и конкретное решение, потому что идея может быть правильной, а исполнение посредственным. Например, одна розетка на ряд из четырёх сидений может не повлиять на ваши метрики, как по причинам стат значимости, так и потому что не выработается привычка.

Обычно решение содержит общую информацию без погружения в бизнес требования, ограничения и другие нюансы. Решение, как и остальные пункты, должно быть ёмким и сообщать, что конкретно вы собираетесь делать для проверки гипотезы. Звучит странно, но продакты частенько пишут в гипотезе одно, а решение направлено на что-то другое. Ключевой задачей решения является проверка гипотезы, а не создание фичи. Если ваше решение комплексное, то стоит указать все гипотезы, на которое оно направлено, в противном случае вам надо его сократить, чтобы быстрее получить новое знание. В общем, беспощадно режьте скоуп пока не останется минимально необходимого решения для проверки именно вашей гипотезы. То есть, проверяя гипотезы, вы всегда делаете что-то вроде MVP. Из такого определения полноценное решение никогда не может иметь гипотезы которую надо проверить.

Решение

1. Положить в райдер для HR информацию, что на рейсе присутствуют розетки и это позволит сотруднику долететь с комфортом и поработать.

2. Оборудовать розетками 200 - 240 V ~0.75A розеткой под евровилку часть бортов, которые совершают рейсы более четырёх часов.

В данном случае решением может быть и опрос среди b2b клиентов, который подтвердит гипотезу и создаст точку роста, но в данном случае я хочу, чтобы оно было именно проверено на практике. Статья содержит намерение передать полноту вариантов, а не решить реальную задачу перевозчика.

проверяя гипотезы, вы всегда делаете что‑то вроде MVP

Метрики

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

И не надо писать в этот блок всё подряд. Вас должны интересовать только те значения, которые позволят вам принимать дальнейшие решения о том оставить фичу, модернизировать или убить. Мерить всё просто чтобы было, значит не понимать что вы делаете. Именно на основе данных вы принимаете дальнейшие решения, и если, например, retention четвертой недели не будет влиять на ваши дальнейшие решения — не надо его измерять, по крайней мере в рамках конкретной инициативы.

Отдельно напомню, что метрики могут измерять и отрицательные эффекты. Например, у вас может быть каннибализация смежного продукта и тогда стоит замерить это и также указать в разделе гипотез. В нашем случае такого нет, так что метрики будут выглядеть так:

Метрики

• Ключевая: рост среднего числа билетов на юр лицо за период квартала изменится с Х на Y или Z% относительных.

Побочные

• Число людей среди командировочных перелётов, которые пользуются розетками во время рейса, вырастет на 10% (не спрашивайте почему 10, установка бейзлайнов метрик это не тема текущей статьи).

• Лояльность b2b сегмента изменится с Х на Y или Z% относительных. 

• Среднее число невыкупленных мест на рейс не изменится

Побочными метриками могут оказаться метрики из ключевых результатов (key results) из фреймворка OKR, если он применяется в вашей компании или другие метрики высокого порядка. Также я не указываю в гипотезе влияние на лояльность — главную метрику компании на год. Эта метрика идёт в блок побочных, потому что я не оч верю что смогу её прокрасить.

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

Итог

Мы разобрали пять признаков продуктового брифа, написав который вы сможете чётко определить сегмент и проблему, понять метрики и определить возможные решения. Такое ёмкое описание будет понятно как и “борду”, так программистам вашего отдела. Вы будете на одной странице — а это уже сильно увеличивает шансы инициативы на успех и хороший t2m.

Итак, еще раз коротко:

• Аудитория поможет вам сфокусировать слушателя или читателя вашей инициативы, представить портрет и проблемы людей, для которых вы создаёте своё решение, связать вашу инициативу с вектором компании.

• Проблемы и точки роста покажут, что вы понимаете, что делаете, позволят лучше формулировать свои мысли.

• Гипотезы научат вас мыслить абстрактно и фокусироваться на поведении людей, для которых вы что-то создаёте, а не мыслить конкретными решениями.

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

• Метрики измеряют ваш вклад в развитие бизнеса и позволяют на числах оценить исполнение решения.

Все остальные поля/разделы — это детали, которые стоит вынести в отдельные части, чтобы не размывать фокус непосвящённого читателя. Они нужны конкретным исполнителям и потому не должны быть интегрированы в бизнес описание задачи.

Применяйте, прокачивайте себя, создавайте классные продукты. По любым вопросам на тему статьи, развития продуктов и "вообще" пишите в телегу t.me/rubilov.

Удачи.

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

Аудитория
Опишите примерный размер сегмента, его поведение

Проблемы/Точки роста
У проблемы есть последствия, проблема умещается в паре предложений. Если длиннее, то что-то не то. 

Гипотезы
Гипотеза содержит метрику, но не её точное значение. Гипотеза про поведение, а не конечную реализацию

Решение и дизайны
Что и как конкретно мы будем делать.

Метрики
Ключевые (те, что из гипотез)

• (метрика) изменится с X% на Y% или Z% относительных

Побочные

• (метрика) изменился с X% на Y% или Z% относительных

• Retention 1ого месяца изменился с X% на Y% или Z% относительных