Каждый из продуктов и функций в вашей дорожной карте, скорее всего, будет отражен в одном или нескольких документах, называемыхспецификации продукта, или сокращенно «спецификации продукта». Эти документы помогают структурировать, упростить и расставить приоритеты при создании вашего продукта. Но они не ваш продукт . Пока ваша команда не создаст что-то реальное, ваша спецификация продукта не будет иметь абсолютно нулевой ценности для ваших пользователей.
Плохие продакт-менеджеры рассматривают спецификации продукта как возможность продемонстрировать свои сильные стороны и опыт. Их спецификации продукта пытаются ответить на все возможные вопросы и рассмотреть все возможные детали реализации, и все это без участия их команды. Эти продакт-менеджеры ожидают, что люди , создающие продукт, просто выполнят свою идеально разработанную спецификацию продукта, не задавая слишком много вопросов и не поднимая лишней суеты. И, безусловно, их продукты — и, в конечном счете, их пользователи — от этого страдают.
Хорошие продакт-менеджеры думают о спецификациях продуктов как о способе зафиксировать и обобщить общие сильные стороны и опыт своей команды. Спецификации их продуктов часто представляют собой незавершенную работу, полную вопросов без ответов, над которыми они могут работать в тесном сотрудничестве со своими коллегами. Они следят за тем, чтобы люди, создающие продукт, были вовлечены и инвестировали в то, как и почему создается продукт. Если кто-то ставит под сомнение спецификацию их продукта, он видит в этом возможность улучшить продукт, а не личную атаку.
Как только менеджеры по продукту поймут, что спецификации их продуктов не обязательно должны быть идеальными, они смогут лучше сосредоточиться на том, чтобы сделать их полезными, а в некоторых случаях даже забавными . Дженни Гибсон, феноменальный руководитель продукта, с которым я имел удовольствие работать в течение последних нескольких лет, просит свою команду описать версии «Юго», «Тойота» и «Ламборгини» каждого предлагаемого продукта или функции. Я прочитал много спецификаций продуктов и могу с уверенностью сказать, что они более информативны, чем большинство (вы можете многому научиться, сравнивая и сопоставляя несколько решений одной и той же проблемы), и более приятны, чем большинство.
Точно так же, как спецификация вашего продукта — это не ваш продукт, помните, что ваши «пользовательские истории» — это не ваши пользователи. Как мы обсуждали в главе 8 , простое описание того, что вы планируете создать, в формате, якобы ориентированном на пользователя, не означает, что вы создаете что-то, что хотят или в чем нуждаются ваши пользователи. Если вы не уверены в целях ваших пользователей или в том, что они хотят сделать, чтобыдля достижения этих целей — задайте эти вопросы своей команде и обсудите их вместе. Написание длинной и подробной спецификации может помочь вам почувствовать, что вы проделали большую работу по созданию продукта, но это не всегда правильная работа. Как менеджер по продукту, вы никогда не можете думать, что только потому, что вы сделали сброс мозгов, вы освобождаетесь от ответственности.работа по переводу этой мозговой свалки в реальный продукт.
Документ с требованиями к продукту содержит проблему, цель и решение в одном месте. Вы знаете, PRD бывают разных форматов и размеров, но мне нравится иметь следующую структуру: заинтересованные стороны, проблема, цель, требования, дизайн и часто задаваемые вопросы. Давайте рассмотрим образец PRD для продукта в Pinterest. Итак, начните с заинтересованных сторон, перечислите всех ключевых заинтересованных сторон, вовлеченных в продукт, вместе со ссылками на любые важные документы. Итак, в этом примере мы пишем PRD для эксперимента в Pinterest. Мы хотим создать селектор темы Pinterest во время регистрации нового пользователя. Итак, PRD датирован, вы знаете, апрелем 2019 года, менеджером проекта является Джо Смит, дизайнером является Анна, инженером Беном, аналитиком является Джефф, а затем мы также связались с дизайном и инженерной эпопеей на вершине PRD. . Это позволяет любому, кто читает PRD, легко узнать, кто ы вовлечены и получить доступ ко всем важным ссылкам. Следующий раздел — это постановка задачи. Вы должны ответить на эти вопросы в одном или двух четких абзацах. В чем проблема клиента, как мы узнаем, что это проблема, и почему так важно, чтобы мы решили эту проблему? Итак, в этом примере проблема заключается в том, что люди хотят просматривать и пинговать контент по интересующим их темам. Сегодня каждый, кто подписывается на Pinterest, видит одну и ту же ленту самого популярного контента. Теперь в этом контенте преобладают несколько категорий, таких как женская мода и декор. Мы считаем, что предоставление людям возможности выбирать темы во время регистрации для персонализации своей ленты повысит уровень активации и поможет Pinterest расти. Следующий раздел должен быть вашей гипотезой. Вы хотите обобщить свою целевую метрику и то, как выглядит успех в одном предложении. Это' Это предложение обычно построено так, как вы знаете, мы можем увеличить целевую метрику на сумму, если создадим эту функцию. Таким образом, для Pinterest, возможно, мы можем увеличить коэффициент активации, который представляет собой процент новых подписчиков, которые снова посещают Pinterest через семь дней, добавив экран «выберите темы для персонализации своей ленты» в поток регистрации. После гипотезы вы должны перечислить ключевые показатели. Опять же, вы должны перечислить его как выходные метрики, которые являются вашими целевыми метриками, и входные метрики, которые являются метриками, которые вы можете продвигать и перемещать, чтобы увеличить свою целевую метрику. Таким образом, в нашем примере выходом является коэффициент активации, а входными данными могут быть количество пользователей, посетивших ленту выбора тем, количество выбравших тему, количество выбранных тем и количество пользователей, которые фактически пингуются во время их первого сеанс после открытия приложения. После метрик следует перечислить требования к продукту. И вы знаете, именно здесь вы должны точно определить, что представляет собой продукт, который вы пытаетесь создать. Я думаю, что полезно писать требования в виде пользовательских историй. Итак, как тип пользователя, когда я выполняю действие, это происходит, верно? Например, вы знаете, как пользователь, когда я регистрируюсь в Pinterest, я вижу экран выбора темы. Вы знаете, на этом скрине я вижу сетку тем и кнопку внизу и тд и тп, Конечно, картинка стоит тысячи слов, поэтому везде, где это возможно, вы должны включать черновой дизайн со своим требования. Теперь было бы здорово начать работать с вашим дизайнером заранее, чтобы набросать грубый каркас, но даже если дизайнер недоступен, вы знаете, не стесняйтесь набросать грубый каркас самостоятельно, хорошо? Каркас слева, который вы видите здесь, может легко сделать даже менеджер по продукту, просто нарисовав блоки. По сравнению с дизайном файла справа, даже каркас дает людям представление о том, какую функцию вы пытаетесь создать. После дизайна вы должны включить примерный план запуска. Так, например, в этом случае мы проводим эксперимент. Итак, наш план запуска заключается в том, какие пользователи имеют право на эксперимент, как выглядит опыт тестирования и контроля и каков план расширения, верно? Итак, в примере с Pinterest съедобные люди — это люди, которые регистрируются в Pinterest и видят процесс онбординга. Тест описанных требований. Элемент управления — это процесс адаптации без этого нового экрана выбора темы. И план рампы мы' мы собираемся получить 50% пользователей, увиденных на новом экране выбора темы, а 50% - нет, и мы собираемся измерить, улучшились ли показатели активации в результате эксперимента. Наконец, я хотел бы включить FAQ. И вы знаете, когда вы делитесь своим PRD с другими заинтересованными сторонами, постоянно возникает несколько очень распространенных вопросов. Поэтому полезно включить ответы на эти вопросы в раздел часто задаваемых вопросов, чтобы, если они возникнут снова, вы могли просто отослать людей к часто задаваемым вопросам в своем PRD. Итак, общий вопрос, который может возникнуть в этом примере, звучит так: почему мы вынуждаем пользователей выбирать как минимум пять тем, прежде чем продолжить процесс онбординга? И ответ может заключаться в том, что, основываясь на разговорах о науке о данных, мы считаем, что выбор как минимум пяти тем даст пользователям более разнообразный первоначальный поток. Что, как говорится, мы будем экспериментировать с минимальным количеством тем на основе наших первоначальных результатов эксперимента. Подводя итог, PRD, документ с требованиями к продукту, должен быть единственным местом, где вы фиксируете проблему клиента, показатель цели, который вы пытаетесь изменить, а также подробные требования к продукту, который вы пытаетесь создать. Теперь, для основных функций, в дополнение к PRD, я люблю писать пресс-релизы. Мы рассмотрим это далее. Мне нравится писать пресс-релиз. Мы рассмотрим это далее. Мне нравится писать пресс-релиз. Мы рассмотрим это далее.
Пресс -релиз
Пресс-релиз — это документ, который пишут все менеджеры по продуктам Amazon для основных продуктов. Я очень люблю пресс-релизы, потому что они воплощают работу в обратном направлении от проблемы клиента. Пресс-релиз должен описывать ваш продукт, используя клиентоориентированный язык. Вы знаете, когда вы пишете свой пресс-релиз, вы в основном пишете его для своего клиента, а не для внутренних заинтересованных сторон. Итак, вот структура пресс-релиза, заголовок и дата, описание проблемы, включение цитаты клиента, описание решения, включение цитаты руководителя и завершение пресс-релиза призывом к действию и, возможно, часто задаваемыми вопросами. Итак, давайте рассмотрим пример пресс-релиза для важной функции, которую я представил Twitch, компании, занимающейся потоковой передачей видеоигр и принадлежащей Amazon. Начните пресс-релиз с заголовка и даты. Заголовок — это одна строка, описывающая, что вы запускаете, и почему это должно волновать клиента. Дата устанавливает ожидания относительно того, когда вы ожидаете, что ваш продукт будет запущен. Итак, в этом примере заголовок «Twitch запускает Squad Stream, чтобы до четырех авторов могли вести совместную прямую трансляцию», а дата — апрель 2019 года. И этот пример также включает подзаголовок, который просто оживляет продукт. чуть чуть больше. Таким образом, подзаголовок звучит так: «Объедините свои сообщества и помогите друг другу расти с помощью Squad Stream. Первый абзац вашего пресс-релиза должен быть действительно сосредоточен на описании проблемы клиента, и вы также должны попытаться выделить наиболее важного клиента. Преимущество заключается в том, что ваш продукт работает. Итак, в этом примере проблема клиентов, как вы знаете, создателей, они транслируются вместе, чтобы повеселиться и представить друг другу свои сообщества. А раньше было больно позволять зрителям смотреть, как они вместе транслируются в прямом эфире. Вы знаете, этот процесс был очень сложным, у него было плохое обнаружение зрителями, и он не работал на разных платформах, таких как веб и мобильные устройства. Что делает Squad Stream, так это то, что создатели могут легко транслировать вместе, а зрители могут смотреть все сразу. В третьей части пресс-релиза должна быть описана цитата клиента. Таким образом, эта цитата может быть реальной цитатой клиента или гипотетической цитатой. Но цель состоит в том, чтобы объяснить, почему клиенты должны заботиться о вашем продукте, на их родном языке. Так что в нашем примере цитата может быть такой: «Сотрудничество с другими авторами — один из лучших способов расти на Twitch. Я могу». Я не жду возможности использовать Squad Stream, чтобы люди могли смотреть, как я играю в игры с друзьями». И эта цитата принадлежит Бену, партнеру Twitch, который регулярно играет в Fortnite, которая является игрой, с другими создателями. опишите свое решение, и вы также должны указать, как клиенты могут найти ваш продукт в вашем описании. Итак, вы знаете, «создатели могут использовать свою панель инструментов, чтобы легко приглашать, присоединяться и покидать потоки Squad на лету. После того, как команда настроена, зрители могут принять участие, нажав «Посмотреть команду» в прямом эфире. Наблюдая за тем, как создатели играют вместе в Squad Stream, зрители могут изменить свой макет, а также следить за создателями и подписываться на них в любое время». Я также думаю, что очень полезно включить цитату из руководства компании. Эта цитата должна переопределить, как ваш продукт связан с общей миссией и стратегией компании. Вот пример цитаты: «Создание сообщества лежит в основе всего, что мы делаем в Twitch», — сказал Эммет, генеральный директор Twitches. «Мы собираемся продолжать улучшать трансляцию Squad, чтобы создатели могли делиться зрителями в прямом эфире, а также внедрять новые продукты, чтобы они могли делиться зрителями, когда мы заканчиваем их трансляцию или в автономном режиме». Наконец, я считаю важным завершить пресс-релиз призывом к действию. Вы знаете, призыв к действию — это, по сути, то, как клиенты могут начать использовать ваш продукт прямо сейчас? «Как создатель, вы можете начать групповую трансляцию прямо сейчас со своей панели инструментов. Как зритель, если вы хотите увидеть групповую трансляцию в действии, используйте тег групповой трансляции на странице просмотра, чтобы увидеть, какие групповые трансляции транслируются прямо сейчас. . Это означает, что вы должны включить самую важную информацию в первый абзац вашего пресс-релиза. Вспомните, мы говорили, что первый абзац должен включать проблему клиента и самую важную выгоду для клиента, которую вы собираетесь предоставить. Знаете, если этой информации нет в первом абзаце, есть вероятность, что люди потеряются на середине страницы. Третий совет — убедитесь, что вы просматриваете, просматриваете и просматриваете свой пресс-релиз. Постоянно просматривайте его сами, а также делитесь им с людьми, которым вы доверяете, чтобы заранее узнать их мнение. И, наконец, иногда пресс-релиз не нужен. Вы знаете, возвращаясь к нашему предыдущему разделу, если вы проводите простой эксперимент для Pinterest, что-то, что довольно просто и легко построить, тогда пресс-релиз действительно не нужен. Итак, теперь, когда мы рассмотрели написание документов с требованиями к продукту и пресс-релизов для отдельных функций, мы, по сути, находимся в конце этапа идентификации цикла разработки продукта. Теперь мы собираемся перейти к захватывающей части, работая с вашей командой над фактическим выполнением и выпуском продукта.
оглавление
Настройки
очередь
Выводы
- Давайте подытожим, что мы узнали на этапе идентификации цикла разработки продукта. Мы начали с того, как вы можете определить общую миссию, видение и стратегию для вашей команды. Подводя итог, вы должны выбрать миссию и видение, которые решают реальную проблему клиента, вдохновляют вашу команду на успех и помогают им принимать решения каждый день. Вы должны определить стратегию, в которой есть диагностика текущей ситуации, всеобъемлющий план достижения вашей миссии и видения, а также набор действий для их достижения. Если у вас есть действительно отличная миссия, видение и стратегия для команды, вы можете перейти к разбиению своей стратегии на действенную дорожную карту с целями и ключевыми результатами. Дорожные карты должны состоять из ваших целей и ключевых результатов, а также списка функций, которые вы планируете создать для достижения ваших ключевых результатов. Мы также говорили о том, как вы можете расставить приоритеты для целей и ключевых результатов, используя три линзы: ценность, клиент, бизнес и видение, а также работу инженеров по оценке стоимости создания каждой функции. Наконец, мы говорили о написании требований к продукту и пресс-релизов для отдельных функций вашей дорожной карты. Мы говорили о том, что PRD должен быть документом, отражающим проблему, цель и решение в одном месте. Мы также рассказали, как менеджеры по продуктам Amazon пишут пресс-релизы для основных функций. И цель пресс-релиза — выразить проблему клиента и основную выгоду, которую вы предоставляете клиенту, используя язык, ориентированный на клиента. Итак, теперь, когда мы рассмотрели миссию, видение и стратегию, дорожные карты, PRD и пресс-релизы, что похоже на множество мельчайших материалов,