Любой продукт в Амазоне начинается с PR/FAQ:

1. Одностраничного пресс-релиза как будто продукт уже запускается — описывает проблему пользователя и её решение, это про ценность.
2. 5-страничного FAQ с гипотетическими вопросами пользователей и реальными вопросами внутренних стейкхолдеров — всеобъемлюще описывает стоимость, функционал, интеграции, стратегию выхода на рынок и т.п. в сжатом формате.
3. Неограниченного количества приложений с данными, исследованиями, скриншотами и т.п. — данные, которые помогают доказать, что проблема есть, показать ценность и предоставить детали для всех цифр в документе.

Все эти артефакты содержатся в одном файле, который можно распечатать или переслать, не теряя важную информацию.

Подготовка — 5 вопросов

Работа над PR/FAQ начинается с пяти вопросов (5 questions).

Ответив на самые важные 5 вопросов, у тебя будет вся информация для написания PRFAQ. Письмо пресс-релиза становится относительно механическим процессом.

Итак, пять вопросов:

1. Who is your customer?

Кто твой пользователь/кастомер? Здесь мы описываем аватар пользователя. Не гипотетический, а основанный на исследованиях, метриках и касдеве.

2. What is the customer problem or opportunity?

Какая у него боль? Описываем проблемы пользователей на основе данных, которые у нас есть. Если не хватает данных, не пишем свои мысли, а бежим собирать больше данных.

3. What is the most important customer benefit?

Какая у пользователя будет выгода от использования того, что мы предлагаем? Как она измеряется?

4. How do you know what your customer needs or wants?

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

Ответ на этот вопрос важен не только для того, чтобы доказать вышестоящему руководству и разработке, что это стоит делать. Это нужно в том числе для тебя самого. Чтобы ТЫ был уверен в своём предложении. Если ты будешь уверен, ты сможешь это продать кому угодно. Если ты сам не уверен, то почему тебе должны выделить под это ресурсы?

5. What does the experience look like?

Описываем UX (можно с прототипами и скринами), как это интегрируется в общую экосистему, стоимость и т.п. Всё, что нужно понимать о том, как это будет работать, но не уходя в сильно глубокие дебри.

Обратите внимание, что тут нет ничего про то, какая в этом выгода для нас. Это важно. Мы отталкиваемся от пользователя, а потом уже анализируем есть ли в этом экономический смысл. Мы работаем не от "как заработать бабла?" а от "какую ценность принести? бабло приложится..."

Ответы пишем полными предложениями.

Our customers are mid-level product managers who are stuck in their roles and don't know how to move forward in their careers. They typically work in companies with ~500 employees. Geographically 40% of them are concentrated on the West Coast, 30% on the East Coast and 30% are spread throughout the country. Their median income is $120k/year. There are approximately 40,000 of them in the United States. Their average age is 30, 60% of them are male, and 25% of them have children.

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

Пресс-релиз

Когда написали пять вопросов, отревьювили их неформально с коллегами (другими продактами, разработкой, менеджером), можно приступать к следующему этапу — написанию пресс-релиза и FAQ (отсюда название PRFAQ, который также пишут как PR/FAQ).

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

У пресс-релиза есть определённая структура и ограничения.

Начнём с ограничений:

• Строго одна страница
• Удобочитаемый шрифт (Таймс 12пт)
• Адекватные поля

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

Всегда хочется написать больше, чем можно. Ограничения по объему дисциплинируют и учат выделять важное. Написать пресс-релиз в одну страницу значительно сложнее, чем растечься мыслью по древу на две. Это требует времени и умения приоритизировать.

Структура PR/FAQ

Структурно пресс-релизы всегда следуют одному и тому же шаблону во всей компании. Без исключений.

Пресс-релиз состоит из заголовка и 7 параграфов.

Заголовок

Одно-полтора предложения, своего рода elevator pitch, в котором коротко и ясно описывается ключевая ценность.

Never miss an important infrastructure alert. Get all your AWS notifications in Slack with AWS Chatbot.

1) Саммари

Основной текст пресс-релиза начинается с абзаца, где описывается что продукт делает и для кого он.

Этот абзац, написанный мной, был опубликован в реальном пресс-релизе, когда мы запустили AWS Chatbot. Только, как мне помнится, во внутреннем пресс-релизе вместо "you" мы использовали "DevOps teams."

AWS Chatbot is a new service that makes it easy to set up ChatOps for AWS in your Amazon Chime chat rooms or Slack channels. AWS Chatbot provides an interactive agent that enables you to monitor and interact with your AWS resources from team chat rooms. You can receive alerts and execute commands to return diagnostic information so your team can collaborate and respond to events faster.

Обратите внимание, что мы не пытаемся пустить пыль в глаза. Всё по делу. Почти без прилагательных.

Это одна из ключевых черт письма в Амазоне. Мы не используем прилагательные, дающие качественную оценку. Либо пишем метрику, либо это неправда. Если для коммуникации ценности нужно прилагательное, ты недовыполнил дискавери. "Easy" — одно из немногих исключений.

2) Пользовательская проблема

Абзац проблемы — это краткая выдержка второго вопроса — "What is the customer problem or opportunity?" Он формулируется по принципу "раньше был полный пздц, потому что..." только опять же всё по делу.

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

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

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

3) Решение проблемы

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

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

А теперь когда у них есть чатбот, девопсы узнаЮт об упавшей инфраструктуре в считанные секунды и могут в общем чате запросить у бота больше инфы, логи, графики и коллективно всё пофиксить за 5 минут отправив боту команду.

Можно ещё использовать "например", чтобы объяснить сложную концепцию на пальцах.

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

4) Цитата от руководителя внутри компании

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

По факту продакт менеджер придумывает цитату сам, пишет имя своего VP, а потом на ревью с самим VP, вице-президент может подкорректировать "свои" слова.

5) Как начать пользоваться

Здесь мы в одном параграфе описываем UX и как легко начать пользоваться.

Чтобы начать пользоваться AWS Chatbot, зайдите в консоль AWS, нажмите кнопку, пройдите аутентификацию в Slack, выберите канал куда слать уведомления и выберите что слать.

Казалось бы зачем описывать UX словами, если его можно показать на картинке? Если ты описываешь UX словами и кажется, что получается слишком сложно, значит это слишком сложно. Если не можешь объяснить на пальцах без визуала, нужно доработать.

6) Цитата пользователя

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

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

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

7) CTA — призыв к действию

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

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

FAQ

Пресс-релиз никогда не презентуется сам по себе. Только в связке с FAQ. В сумме пресс-релиз и FAQ составляют не более 6 страниц: 1 страница пресс-релиз и 5 страниц частых вопросов и ответов.

FAQ — это моя любимая часть процесса. Это просто список из 100500 вопросов с короткими ответами. Вопрос-ответ, вопрос-ответ. Каждый ответ обычно не больше абзаца.

FAQ делится на две секции: вопросы пользователей и вопросы стейкхолдеров.

Вопросы пользователей

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

• Сколько он стоит?
• Как мигрировать с другого приложения?
• Возвращаются ли деньги при отмене подписки?
• Какие форматы данных поддерживаются?

И так две-три страницы сплошных вопросов. Любой вопрос, который возникнет — пишем сюда и отвечаем.

Вопросы стейкхолдеров

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

• Какие у нас косты?
• Сколько человек нужно, чтобы поддерживать сервис?
• Как это интегрируется с платформой Х?
• Как это масштабируется?
• Какие алгоритмы шифрования используются?
• С какой страны мы начинаем запуск?
• Почему мы думаем, что это взлетит?

В итоге у нас 5 страниц вопросов и ответов, которые мы генерим сами "из головы", в ответ на фидбек на ревью (задали вопрос — включили на него ответ, чтобы на следующем ревью его уже не было) и из шаблонов.

На некоторые вопросы ответы могут быть очень длинными. Например, нужно приложить таблицу с моделью P&L. В таких случаях в ответе просто ссылка на "приложение Х", которое приложено в этом же документе.

Приложения (Appendix)

Приложения могут быть любой длиной. На моём опыте их страниц 20-30. Там разного рода расчеты ТАМ, скрины дизайна, P&L, детальное саммари касдевов и т.п.

Обычно приложения нумеруются буквами — Appendix A, Appendix B и т.п.

Процесс ревью

PRFAQ как культ внутри компании**

Итак…

Документы — это здорово. Они приводят в порядок ум и систематизируют понимание продукта стейкхолдерами. Однако, причина эффективности PRFAQ, как инструмента создания новых продуктов, кроется не столько в самом документе, сколько в процессах, на которые он ложится. Переняв только саму структуру и начав писать пресс-релизы, легко свалиться в карго-культ.

Начну с самого важного — безоговорочной стандартизации на одном процессе во всей компании, в которой работает 1,5 миллиона сотрудников.

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

Образованию уделяется огромное внимание. Продакт менеджеров учат писать PRFAQ в обязательном порядке после найма. Все другие функции тоже могут пройти воркшопы, так как практически любому человеку в компании, кто так или иначе связан с созданием продукта — разработчику, дизайнеру, руководителю — рано или поздно понадобится описать свою идею в PRFAQ (иначе её никто не будет рассматривать).

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

У каждой команды обязательно есть PRFAQ для их продукта. Это работает как магия.

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

Это очень эффективно.

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

Когда возникает вопрос по продукту другой команды, архив PRFAQ почти всегда доступен на внутренней wiki любому сотруднику компании. Для доступа к более секретным PRFAQ можно написать продакт менеджеру этого сервиса и попросить расшарить с тобой приватно. Тебе не нужно ни с кем встречаться и ничего обсуждать. Почти всё, что кому-либо в компании нужно знать о продукте, уже содержится в PRFAQ.

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

Любые попытки поменять этот процесс не приветствуются и всячески не поощряются. Всех, кто пытается поменять процесс, культура попросту выдавит.

Кто к нам с powerpoint-ом придёт, тот знает, где дверь

(с) народная мудрость. В Амазоне запрещены слайды.

Иерархический процесс ревью

Каждый PRFAQ проходит множество итераций и несколько раундов ревью. Любой более-менее важный документ идёт на уровень твоего менеджера + 1. Особо важные документы идут вплоть на уровень VP, SVP и даже CEO.

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

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

2. Далее обычно идёт ревью с твоим менеджером. Это может быть руководитель продуктовой команды или руководитель руководителей разработки (об орг. структуре тоже напишу позже). На это ревью в том числе приглашаются менеджер разработки, тех лид, дизайнер, другие продакты из команды (если им это релевантно), принципал продакт менеджер организации (моя последняя роль в Амазоне) и принципал инженер.
   
   В зависимости от того, на какой стадии находится документ, может быть ещё 1-2 дополнительных ревью с той же группой, если требуются существенные доработки.

3. Следующее ревью, как правило, происходит с директором (это около 100 человек в подчинении, включая разработку и продактов). На этом ревью обычно присутствуют большинство тех, кто был на предыдущих — руководитель продактов, менеджер разработки, его менеджер, принципалы и зачастую тех лид команды, отвечающей за разработку. На таком митинге может запросто быть 10-12 человек. Для большинства PRFAQ на этом всё заканчивается.

4. Далее идёт ревью с VP (как правило, 1000+ человек) и выше. На таких митингах может быть до 20 человек, включая всех руководителей и директоров по линии продукта, разработки и дизайна, руководителей смежных организаций и т.п. На этом этапе также могут быть приглашены юрист, финансист и маркетинг. Большинство ревью на этом заканчиваются, но могут пойти и выше, вплоть до СЕО, если этого требует масштаб продукта.

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

Может случиться так, что продукт будет отменён на одном из этапов. Это лучше продукта, отменённого в процессе написания кода.

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

Как проходит само ревью

Самое любопытное для новичка в Амазоне — это то, как проходит митинг ревью документов.

Формат документа

Если люди встречаются в офисе — документ распечатывается. Документ может запросто быть 50 страниц со всеми приложениями. Ты распечатываешь сотни страниц в нескольких экземплярах и сшиваешь их. Это такая медитация, занимающая полчаса. И не дай Бог найти ошибку, которую ты хочешь исправить перед презентацией...

Если люди встречаются онлайн (или кто-то звонит на митинг, проходящий в офисе), у них есть электронная копия документа в приложении, где можно оставлять комменты. В моё время Амазон использовал свой собственный сервис WorkDocs и тул Quip от Salesforce. Не знаю чем они пользуются сейчас. Идеальные тулы для таких ревью — Google Docs или Microsoft Word 365, но Амазон не пользуется облачными инструментами конкурентов.

Чтение

Ревью длится 1 час. Первые полчаса все сидят в тишине и читают документ.

Если кто-то начинает комментировать, на него коллективно шикают. “Тишина! Идёт ревью!” Шикнуть могут даже на VP. Такое иногда бывает, если человек новенький в культуре и ещё не стал частью культа. Новым людям некомфортно полчаса сидеть в тишине. Во всех других компаниях митинги — для того, чтобы “тереть” и спорить. В Амазоне не так.

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

Болтовня по ходу чтения запрещена, это всех отвлекает. Если у тебя возник вопрос на второй странице, возможно, он будет отвечен на четвёртой. Зафиксируй вопрос и читай молча. Если вопрос не отпал сам собой, его можно задать во время обсуждения.

Пока все читают, ты сидишь и смотришь, где люди делают помарки в документе. Так как ты знаешь свой документ вдоль и поперёк, ты примерно понимаешь к какой части возникли вопросы, когда видишь, что человек пишет что-то на полях. Если ревью онлайн, то ты видишь комментарии в файле и можешь заранее подготовиться к вопросам.

У меня обычно во время ревью с руководством сводило спазмами живот 🙈

Люди читают очень быстро и обычно, когда они закончили читать, они кладут документ на стол и начинают заниматься своими делами. Когда достаточное количество людей закончили читать, особенно, самые важные стейкхолдеры, презентующий спрашивает “все закончили или нужно ещё время?” Если кто-то говорит, что нужно ещё время, обычно им даётся ещё минут 5 и потом начинается следующая часть митинга.

Обсуждение

Когда люди заканчивают читать, начинается обсуждение.

Обсуждение может быть жёстким, но оно всегда по делу. Как правило обсуждение начинается с вопросов типа “почему так”, “какие подтверждающие данные у нас есть”, “какие другие варианты мы рассматривали”, “говорили ли мы с другой командой и что они сказали”, и т.п.

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

Все обсуждения максимально объективны и справедливы. Люди стараются использовать данные и не говорить голословно (это часть культуры). Никто не спорит в сердцах, никого не оскорбляет и не говорит субъективные суждения. Если в группе Амазоновцы со стажем, то любая дичь будет сразу же пресечена.

Когда тебе задают вопрос и ты не знаешь ответа, все ожидают, что ты скажешь “я не знаю, дам ответ к такому-то числу”. Никого не интересует твоя сообразительность на месте. Булшит видят сразу и пресекают в корне. Не знать — нормально, пытаться выкрутиться — нет.

Ревью проходит очень структурно, особенно, когда это уже не первая итерация и качество документа на высоте.

Когда вопросы заканчиваются, у нас четыре потенциальных исхода: 1) аппрув, 2) условный аппрув — всё норм, но нужно добавить инфу, которую попросили, 3) нужно доработать и прийти снова и 4) отклонено.

Финализация документа

После успешного ревью ты дорабатываешь документ, чтобы учесть все комментарии и вопросы с ревью, и отправляешь его всем стейкхолдерам как “FYI, дайте знать, если есть ещё вопросы”. Документ становится своего рода архивным и больше не меняется.