Работа с требованиями и PRDs: практические факапы продакт менеджера

В теории все просто: одна из главных задач продакта — понимать, что нужно клиентам (или пользователям) и строить решение для этих требований вместе с командой разработки. А заодно и всем об этом рассказать в короткой и понятной форме.

Для этого используется структура PRD (Product Requirements Document), и несмотря на модный термин, это всего лишь четкие ответы на главные «сложные» вопросы:

«В чем бизнес-проблема? (Business problem)»
”Какие есть ограничения? (constraints)”
«Что и когда будем делать?»
«Кто делает что?»

Такая структура используется во всех больших компаниях: Uber, Booking.com, Spotify, Amazon, Google и так далее. Поскольку в таких конторах одновременно запускаются десятки проектов/фич, магия одной странички PRD-документа позволяет всем, от программиста до директора понять, что, собственно происходит. Что же может пойти не так?

Представьте, что вы начинаете читать следующий PRD в IT-отделе какой-нибудь авиакомпании:

Проблема: в Q3 этого года нам надо заменить старую систему оповещений о бронировании/изменении авиабилетов на новую.
<И так далее: ограничения/что/кто>

Видите проблему с этой «проблемой»? Если хотите попрактиковаться, то остановитесь здесь и попробуйте дать фидбек Jr. продакту, который это вам принес.

Суровые читатели-Senior-ы отметили верно: вместо бизнес-проблемы нам пытаются подсунуть решение! Причем не со зла, просто наш мозг устроен таким образом, что ему сразу же "все понятно” и факт, что старая система плохая, кажется очевидным (кстати, любителям почитать про открытия в области мышления советую взглянуть на книгу “Думай медленно, решай быстро» Д. Канемана).

Возвращаясь, к Jr-у: он заменил сложный вопрос ("зачем”) простым вопросам (“что"). Опасностей этой мини-замены текста две.

Во-первых, компания может потратить год(ы) на никому не нужное изменение (не все старые системы плохие — куча глубокого банковского и авиационного софта работают на коде 80-х).

Во-вторых, "что" убивает креативность команды (как разработки, так и продуктового департамента). Ведь, возможно, есть другие решения той же проблемы (более эффективные и быстрые), но они автоматически отбриваются, так как "правильное" уже выбрано.

Вы просветили Джуна и он возвращается с улучшением:

Проблема: в Q3 этого года нам надо улучшить конверсию доставки сообщений: сейчас много из них так и не доходят до пассажиров.
<И так далее: ограничения/что/кто>

Что думаете? Опять, если хотите попрактиковаться, дайте Джуну коммент.

Эта постановка проблемы уже гораздо лучше — по крайней мере явно виден вопрос «зачем», но чего-то не хватает. Лично мне не хватает цифр и связи с бизнесом: что такое «много»? 100 - это много? А 1000? В день или месяц? Отправляем Джуна думать.

Вот новая версия:

Проблема: в Q3 этого года нам надо улучшить конверсию доставки сообщений: сейчас около 10% сообщений в день так и не доходят до пассажиров.
<И так далее: ограничения/что/кто>

Вот это другое дело! Вы готовы начинать разработку по таким требованиям?

Я пока не готов. Это, разумеется, грустно, что 10% сообщений теряются, но мы все-таки авиакомпания, а не WhatsApp. Насколько это влияет на главные бизнес-метрики нашего продукта (перелетов)?

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

А может быть, этим 10% и не нужны нотификации — они купили билет, забыли и пришли на свой рейс во-врем? Тогда зачем нам тратить время на обновление системы — есть дела поважнее.

Джун заметно посерел, но начинает чувствовать, что качает скилл и подбирается к сути:

Проблема: в Q3 этого года нам надо улучшить конверсию доставки сообщений: сейчас около 10% в день так и не доходят до пассажиров. Около 24% этих пассажиров звонят в поддержку, что нагружает ее до пиковых 85%. Более того, 2% пассажиров в итоге отменяет поездку. Наконец, в последнем квартале нам пришлось судиться по 16 кейсам, когда мы перенесли рейс, но пассажир не получил никакого уведомления.
<И так далее: ограничения/что/кто>

Вот теперь Джон заслужил похвалу и по-праву может гордиться приставкой «продакт менеджер». А нам с вами теперь явно видно проблему — наши невинные 10% сообщений приводят к вполне серьезным последствиям для бизнеса.

Далее можно собирать остальные требования (например, то, что все ваши внутренние клиенты не могут сразу все бросить и мигрировать на вашу новую систему, и т.д.) и, наконец, собирать команду думать над техническими ограничениями (например, у вас только Python программисты в команде и вы частично в облаке) и, собственно, решением.

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

Вроде бы все! Что еще в реальной компании может пойти не так?

Много чего, но из того, что продакт может контролировать — это события, которые все-таки в итоге перечеркивают необходимость решать задачу немедленно. И так тоже бывает, так что нужно сделать простой «чек» (check) с соседними департаментами и лидерами.

Может случиться, что ваш новый отдел аэро-доставки как раз разработал новую систему для своих нужд (нотификации службам наземной доставки) и вы можете воплотить мечту software-архитектора и переиспользовать систему для двух кейсов (программисты сейчас закрыли глаза от удовольствия, и я, в прошлом девелопер, тоже).

А может быть у вашей компании есть проблемы посерьезней (например, pricing-платформа сломалась) и тогда ваш директор/CEO попросит вас переключить внимание и разработку туда.

Если вы написали PRD коротко и ясно, то все (программист, коллега-продакт, клиент, дизайнер, тестировщик, менеджер, CEO) за 5 минут поймут проблему и примут решения на своих уровнях.

Надеюсь такая практическая история про PRD помогла вам понять важность этого документа, а главное — важность четкого «зачем» внутри него.

Если вам интересны практические заметки из опыта западных компаний, смело приходите к нам в Телеграмм канал "ProductDo: практика для продактов" (productdo) — мы постоянно с чем-то сталкиваемся и делимся этим с вами. До связи!