Working Backwards: почему продукт надо писать с конца

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

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

Именно для этого существует Working Backwards.

Что такое Working Backwards

Working Backwards — это метод продуктового определения, при котором команда начинает не с требований и задач, а с финального артефакта: пресс-релиза для клиента о готовом продукте. Если вы не можете написать его чётко и честно — значит, продукт ещё не понят.

Метод появился внутри Amazon как ответ на типичную болезнь растущих компаний: команды уходили в разработку, имея смутное представление о том, что строят и зачем. Джефф Безос ввёл правило: прежде чем начать работу над продуктом, нужно написать внутренний пресс-релиз — так, как будто продукт уже вышел и его читает обычный покупатель.

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

Когда это нужно

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

«Мы полгода строили аналитический модуль. Когда выкатили — оказалось, что каждый понимал под словом "аналитика" что-то своё. Один хотел дашборд, другой — выгрузку в Excel, третий — алерты» — типичная ситуация, когда пресс-релиз не был написан в начале.

Команда застряла в пространстве решений. Обсуждение крутится вокруг технических вариантов, а не вокруг клиентской ценности. Возврат к пресс-релизу и FAQ возвращает разговор в нужное русло.

Смена стратегии или пивот. Продукт существует, но не растёт. Прежде чем менять архитектуру или добавлять фичи, полезно переписать пресс-релиз — и посмотреть, изменилось ли ваше понимание клиента.

Выход на новый сегмент или рынок. То, что работало для одного клиента, не обязательно работает для другого. Working Backwards помогает заново прояснить ценность для новой аудитории, не перенося старые предположения автоматически.

Как внедрить: 4 шага

01. Напишите пресс-релиз

Одна страница. Структура: заголовок → проблема клиента → как продукт её решает → главные функции → цитата от вымышленного пользователя → призыв к действию. Писать нужно на языке клиента, не на языке команды. Никаких «оптимизированный движок» и «инновационная платформа» — только конкретные слова о конкретной пользе.

Критерий успеха: незнакомый человек прочитал пресс-релиз и сразу понял, кому это нужно, зачем и почему это лучше, чем то, что есть сейчас.

02. Составьте FAQ

Выпишите все вопросы, которые возникли при написании пресс-релиза, плюс те, что задают клиенты и скептики внутри команды. Ответьте на каждый честно. Если ответа нет — это не слабость документа, это риск, который нужно зафиксировать.

Команды в этот момент часто обнаруживают, что не знают ответа на вопрос «почему клиент выберет нас, а не текущее решение» — и это ценная находка до начала разработки, а не после.

03. Опишите пользовательский опыт

Для продуктов с интерфейсом — это мокапы или описание экранов. Для сервисов — сценарии использования, написанные от первого лица клиента: «Я зашёл, увидел X, нажал Y, получил Z». Цель — не дизайн, а ясность: как именно клиент решает свою задачу с помощью продукта шаг за шагом.

Хороший сигнал: команда читает сценарии и говорит «вот это я понимаю, буду делать именно это». Плохой сигнал: каждый видит сценарий по-своему.

04. Напишите руководство пользователя

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

Критерий: мануал можно передать новому человеку в команде, и он поймёт продукт без дополнительных объяснений.

Варианты применения

Полный цикл (все 4 артефакта) — для новых продуктов и крупных стратегических решений. Занимает 2–5 дней, но экономит месяцы разработки не того.

Только пресс-релиз + FAQ — для фич среднего масштаба или когда команда застряла в дискуссии. Занимает полдня и часто достаточно, чтобы выровнять понимание.

Пресс-релиз как валидационный тест — показать черновик нескольким реальным клиентам до старта разработки. Реакция «я бы это точно попробовал» или равнодушие дают честный сигнал раньше, чем MVP.

Большинство команд, впервые пробующих написать пресс-релиз, замечают одно и то же: «мы думали, что у нас есть продукт — оказалось, у нас есть список функций без внятного ответа на вопрос, зачем это клиенту».

Что это меняет в работе

Решения о том, что строить, начинают приниматься исходя из клиентской ценности, а не из технических предпочтений или аргумента «я так думаю». Пресс-релиз становится точкой, к которой команда возвращается при каждом споре о приоритетах.

Исчезает дорогостоящая ошибка «мы построили правильно, но не то». Команды, которые прошли через Working Backwards хотя бы один раз, перестают удивляться, почему клиент не пользуется продуктом: ответ был ещё в пресс-релизе — или его не было.

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

Попробуйте прямо сейчас

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

Посмотрите, где вы застряли. Именно там и находится настоящая неопределённость.