Процессы, которые работают в большой компании, могут быть вредны в компании маленькой.

Когда компания небольшая, многие вещи можно решить разговором (грубо говоря — “все в одной комнате”). У команды высокий общий контекст и большая автономность (“людей не хватает”). Какой-то процесс поверх этого потенциально может замедлить работу, не добавив пользы.

Когда команда растёт, появляется больше связей, cнижается общий контекст — появляется необходимость в процессах и ритуалах.

Например, если у вас один и тот же продукт меняет десяток продакт-менеджеров — они начнут пересекаться. Появится вопрос — а нет ли у нас ситуации лебеди-рака-щуки, двигаем ли мы продукт к одной цели?

Одно из решений тут — продуктовый питч. Еще его называют RFC (request for comment, request for change), PRD (product requirement document), narrative, design doc и другими словами.

На определенном этапе развития компании эта штука позволяет достичь двух вещей:

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

В интернете можно найти целую россыпь различных темплейтов таких документов разной степени хорошести. От простых до совершенно монструозных.

В своё время я посмотрел на них все и сделал себе свой: взял из разных документов то, что нравится и выкинул то, что считаю лишним.

→ Получился вот такой темплейт (на английском)

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

Особенно хочу обратить ваше внимание, что Problem Alignment и Solution Alignment — разные секции и могут (а часто и должны) писаться отдельно. Одна из частых проблем — готовое решение в голове, которое диктует проблему. Чтобы избавится от этого, проблему стоит описывать отдельно, не пытаясь описывать конкретные решения и изменения.