Команда запускает фичу. Пользователи не приходят. По коду всё сделано, по заданию тоже. Открываешь исходник: 47 страниц экранов, полей, состояний кнопки. Ни строчки, зачем человеку это утром во вторник.
В 2012-м я вёл несколько коммерческих проектов и раз за разом получал одно и то же. Клиент приносил требования, мы делали точно по ним, потом выяснялось, что он хотел другой результат. Не другие кнопки. Другой исход в его кассе или в его очереди.
Тогда я завёл себе несколько страниц и назвал их «план проекта». Термина PRD я не знал. Документ начинался не с экранов. Начинался с дыры, с того, что изменится после запуска, и с признака, по которому поймём, что попали. Этот план я таскал почти по всем проектам того периода.
За десять с лишним лет добавились метрики, версии, чужие привычки больших контор. Костяк тот же: сначала зачем, потом что умеет человек, и только потом как это собрать. Документ либо не пишут («мы agile, у нас Jira»), либо пишут так, что ко второй неделе это уже археология. Оба края я видел.
Хороший PRD отвечает на три вопроса: зачем, для кого, как поймём, что получилось. Плохой перечисляет, что система должна. «Поддержать OAuth» и «70% бросают регистрацию на пароле» это разные бумаги. «Дашборд раз в пять секунд» и «оператор решает по вчерашним цифрам, это 50 тысяч долларов в месяц» тоже.
ТЗ для подрядчика это контракт, как делать. Роадмап это что и когда. Юзер-стори это одна плитка. PRD держит одну инициативу целиком: боль, цель, край, неизвестное. Если в тексте уже Redis, имя таблицы и выбор библиотеки, вы съехали в технический дизайн. Граница: что должен суметь человек и как измерим успех. Как это уложить в код живёт рядом, в ADR.
Писать его стоит, если работа больше двух недель, трогает несколько команд, меняет бизнес-логику или ещё не ясно, чего хотим. Очевидный баг, мелкий интерфейс, задача на день-два одному человеку бумагу не кормят.
Почему бумага умирает на второй неделе
Чаще всего её пишут после решения. Фаундер уже знает, что строит, и задним числом подгоняет боль. Документ начинается с «мы хотим сделать», не с «человек спотыкается здесь».
Цели без числа. «Ускорить загрузку» нельзя сдать. «Главная с 4.2 с до 1.5 с, конверсия с 2.1% до 2.8%» можно спорить и резать.
Нет полки «чего не будет». Тогда на второй неделе к верификации почты пришивают мобильное приложение, «раз уж вы там».
Пользователь написан как «B2B-сегмент». Команда строит для среднего человека, которого нет. Бухгалтер Мария, 42 года, 200 человек в фирме, закрывает период в 1С, бесится, когда одни данные вводит дважды: уже можно рисовать экран.
Дата в шапке совпадает с датой создания. Процесс ушёл, бумага нет. Через месяц это враньё с красивым статусом «утверждён».
Когда последняя задача по документу доехала до Done, бумагу надо либо положить в архив со статусом «выпущен», либо перенести сердце (боль, цели, метрики) в базу знаний как историю решения. Держать «утверждён» полгода после запуска значит дезинформировать следующего, кто откроет папку.
Как я собираю документ
Перед текстом пишу абзац: что станет иначе в жизни человека после запуска. Не что мы сделаем. Что у него перестанет болеть или сколько часов он перестанет терять. Если абзац не встаёт, цели ещё нет.
Раздел про проблему пишу так, чтобы разработчик, который продукт никогда не видел, понял, кому и как больно. Если после чтения не ясно, кто страдает, бумага не работает.
Версии, история изменений, статус, один человек с фамилией, который отвечает за свежесть. Не «продуктовая команда».
Шапка: имя инициативы, статус, версия, ответственный, даты, кому это вообще адресовано.
Резюме пишу последним. Три-пять предложений: видим дыру, она бьёт вот этих, стоит вот столько, предлагаем вот это, ждём вот такое число.
Проблема тремя ходами. Что происходит сейчас, с цифрой и цитатой. Почему это дыра, кому и на сколько. Что будет, если не делать. Иногда ответ «ничего страшного», и тогда инициативу надо отложить, не героизировать.
Плохо: пользователи жалуются на медленную загрузку, надо ускорить.
Можно нести: главная на медленном 3G грузится 4.2 с (P75). Каждые 100 мс режут конверсию примерно на процент. Наша конверсия с лендинга 2.1% при среднем по рынку 3.8%. 43% уходят, не дождавшись отрисовки. На 50 тысячах визитов в месяц это около 21 тысячи потерянных людей, из них сотни могли конвертироваться.
Почему сейчас. Алгоритм поиска с марта 2026 начинает жёстче смотреть на отрисовку. LCP 4.2 с может отъесть 15-20% органики. Сосед уже на 1.1 с. Делать позже значит отвоёвывать позицию, не держать её.
Пользователь один-три, не все обитатели продукта. Алексей, 34, маркетинг в B2B SaaS, каждый день собирает отчёт совету, бесится, когда цифры «не сходятся», часто открывает с телефона на встрече. Или работа: когда готовлю ежемесячный отчёт, хочу собрать метрики в один лист, чтобы не убить три часа руками.
Цели в форме «метрика с A до B за срок». Не-цели отдельным списком, без извинений: редизайн всего онбординга не в этой версии, соцсети в третьем квартале, тарифы решает бизнес. Это полка хороших идей, которые сознательно ждут.
Метрики тремя слоями. Одна главная: если она не сдвинулась, инициатива не взлетела. Две-четыре рядом для контекста. Ограничительные: что не имеем права ухудшить. Для верификации почты это может выглядеть так: доля активированных за 7 дней с 27% до 45%; бросают шаг верификации не больше 35% вместо 68%; до первой пользы не больше дня вместо трёх; спам-регистрации не выше нынешних 3%; нагрузка на почту не выше 120% текущей.
Функции языком человека, не модулей, с полками обязательно / желательно / если останется время / не в этой версии. Без верификации человек попадает в продукт, видит ограничение, через сутки и через трое получает одно письмо с одной кнопкой. Соцвход и автозаполнение профиля из сети в первой версии нет.
Нефункциональное коротко: первая интерактивность до двух секунд на 3G, живые браузеры, данные неверифицированных никуда не уезжают, если почтовый шлюз лёг, регистрация всё равно проходит.
Путь одним сценарием, не макетом каждого экрана. Заполнил почту и пароль, создал аккаунт, видит «проверьте почту», кнопка «начать с ограниченным доступом», в продукте баннер, через сутки письмо.
Зависимости списком: шаблон письма, флаг в токене, макеты ограниченного режима до старта разработки. Риски таблицей: вероятность, удар, что делаем. Спам после упрощения, юристы и GDPR, гипотеза «люди бросают именно на письме» может оказаться ложной. Последнюю проверяют пятью разговорами до кода, не после релиза.
Вне рамок: то, что не будет сделано в этой инициативе никогда или уйдёт другой команде. Редизайн онбординга у роста, правила триала у директора, CRM-follow-up в дорожной карте на осень.
Открытые вопросы не слабость. Скрытый вопрос всплывает в середине спринта. Что с аккаунтом через 30 дней без письма. Нужно ли юротдел. Как это ляжет на тех, кто уже внутри. У каждого вопроса имя и дата.
Шаблон
# PRD: [имя]
Статус / версия / кто ведёт / даты / кому адресовано
## История изменений
версия, дата, автор, что сдвинули
## Коротко
дыра → кто страдает → масштаб → ход → число
## Проблема
сейчас / почему это дыра / что будет, если не делать
## Почему сейчас
## Для кого
один живой человек и работа, которую он нанимает
## Цели
метрика, сейчас, цель, срок
что не имеем права уронить
## Не в этой версии
## Умения продукта
обязательно / желательно / если останется / не делаем
## Ограничения
скорость, объём, безопасность, браузеры, деградация
## Путь
основной сценарий по шагам
## Зависимости
кто, что, когда
## Риски
технические, продуктовые, рыночные, операционные
## Вне рамок
## Открытые вопросы
вопрос, имя, датаЖивой кусок резюме, с которого я чаще всего начинаю чужой документ:
Бросают форму на шаге письма, 68% drop-off, около 120 тысяч долларов в месяц недополученной выручки. Пускаем в продукт без верификации, режем функции, через сутки и через трое одно письмо с одной кнопкой. Цель: бросают не больше 35%, активированных плюс 40%.
Если этот абзац нельзя написать, экраны ещё рано рисовать.
Черновик с честными дырами. День-три асинхронных комментариев. Полчаса живьём только если спор не закрылся в тексте. Потом «утверждён» и можно копать. Идеальной бумаги ждать не надо: разработка сама закроет часть вопросов данными.
Бумагу убивают ещё четыре привычки. Пятьдесят страниц каждого поля: устаревает после первого теста. Использование как улики в споре «ты обещал»: команда начинает соответствовать документу, не человеку. Свалка исследований и конкурентов: решение тонет. Продающий слайд без рисков: совет кивает картинке, через месяц спрашивает, почему в проде не так. Лечится одним ответственным с фамилией и стартом ревью с проблемы, не с макета.
Писать может тот, кто лучше видит боль. В ранней конторе это часто основатель, техлид, человек из поддержки. Важно одно: один ответственный с именем.
Согласование начинаю с проблемы и метрик, не с решения. Если человек не может назвать дыру иначе, чем через уже выбранный экран, это флаг. Риски в тексте не пессимизм. Это зрелость. Бумага, которой продают идею совету без раздела «что может сломаться», потом взрывается фразой «почему не сделали как на слайде».
Agile здесь ни при чём. Итерации в коде не отменяют общей картины, зачем копаем. Хорошая бумага как раз даёт команде свободу решать «как», потому что «зачем» уже лежит на столе. Владельцу не надо пересказывать контекст на каждой планёрке. Новому человеку не надо восстанавливать его из тикетов.
Три проекта из пяти, куда я заходил как CTO, болели одним: умные люди строили не то. Не потому что плохо писали код. Потому что не было общей картины, зачем, для кого и какое число значит «получилось». Шаблон занимает два-четыре часа. Эти часы обычно возвращаются неделей, которую команда не тратит на спор о кнопке, которую никто не просил.
