Библия продуктового менеджера ”Inspired. Вдохновленные”

Елена Тупикова (Котина), Телеграм канал “Games of Projects and Products” — https://t.me/projectsproducts

Заметки из книги Марти Кагана

Помни, что просто не будет:) ⬇

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

Две неприятные правды о продукте:

1. Половина идей не сработают. (Лучшие команды исходят из предположения, что минимум три четверти идей не сработают так, как им хотелось бы.)

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

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

Три принципа:

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

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

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

Про продуктовую команду:

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

Типичная продуктовая команда состоит из продакт-менеджера, продуктового дизайнера и от двух до 10–12 инженеров-программистов.

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

…

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

Обязанности менеджера продукта:

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

- Умение работать с данными, с аналитикой. Большинство менеджеров продукта в начале дня уделяют полчаса попыткам с помощью разных аналитических инструментов разобраться в том, что происходило в отрасли за прошедшие сутки. Они просматривают аналитические данные о продажах и использовании своего продукта и анализируют результаты A/B-тестов.

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

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

Вопросы, которые себе стоит задать при разработке продукта:

- Как потребители узнают о продукте?

- Как мы будем знакомить нового пользователя с продуктом и (возможно, постепенно) раскрывать ему его новые функциональные характеристики?

- Как пользователи могут взаимодействовать с нами и продуктом в разное время суток?

- Что еще конкурирует за внимание пользователя?

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

- Как мы будем мотивировать пользователя еще активнее использовать наш продукт?

- Как мы будем радовать пользователя?

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

- Как потребители будут получать офлайн-услуги?

- Как продукт реагирует на действия пользователя?

Видение продукта и стратегия его развития:

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

Про то, что должны знать все:

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

-Бизнес-цели. Конкретные бизнес-цели с учетом их приоритетности для каждой продуктовой команды.

Про дорожные карты:

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

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

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

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

А одним из измеримых ключевых результатов будет, скажем: «Среднее время адаптации нового клиента не должно превышать трех часов».

На что коммитимся?

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

Про OKR

Концепция OKR проста и основывается на двух принципах:
Первый легко подытожить знаменитыми словами генерала Джорджа Паттона: «Никогда не говори людям, как надо делать. Скажи им, что делать, и они удивят тебя своей изобретательностью».

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

Если вы внедряете систему OKR в своей продуктовой компании, непременно ставьте цели и ключевые результаты на уровне продуктовой команды. Иными словами, вы не должны позволять целям и ключевым результатам отдельных сотрудников или функциональной команды запутывать ситуацию. Сосредоточьте людей на их целях в рамках продуктовых команд. Если разные функциональные подразделения (дизайнерское, инженерно-техническое или по контролю качества) ставят перед собой более широкие цели — скажем, разработка адаптивного дизайна, управление техническим долгом и автоматизация тестирования, — руководство должно их обсудить и определить приоритеты наряду с другими бизнес-целями, а затем интегрировать в соответствующие цели продуктовой команды.

МЕТОДИКИ ДЛЯ ФОРМУЛИРОВАНИЯ ЗАДАЧ

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

На этапе исследования продукта вам придется ответить на четыре ключевых вопроса:

- Какой бизнес-цели вы хотите достичь, проделав эту работу? (Цель.)

- Как вы будете определять, добились ли успеха? (Ключевые результаты.)

- Какая проблема потребителей будет решена в итоге? (Проблема клиента.)

- На потребителе какого типа вы сосредоточены? (Целевой рынок.)

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

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

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

Story mapping — методика планирования:

«Карты истории» представляют собой двумерные карты, на которых по горизонтали слева направо в порядке выполнения отображены ключевые пользовательские действия (или, как их еще называют, активность пользователя). Так что, если основных видов пользовательских действий, скажем, десять, они будут перечислены сверху вниз слева направо, как правило, в том порядке, в каком вы будете ими заниматься — или хотя бы в том, в каком бы вы их перечислили, если бы кому-нибудь описывали эту систему.По вертикали отображается рост уровня детализации. По мере того как мы разбираем каждую основную активность, превращая ее в наборы пользовательских задач, для каждой из них мы добавляем истории. Важные, основные задачи отображаются на карте выше, дополнительные и необязательные — ниже. Наглядно представив таким образом систему, вы можете с одного взгляда увидеть комплексную, общую картину и определить, где провести черту, отделяющую друг от друга разные релизы и связанные с ними цели. И тогда у каждой истории появляется контекст и вся команда может видеть, как каждая история сочетается с остальными. И это не просто что-то вроде мгновенного снимка, ведь команда видит и то, как, согласно ожиданиям, эта система будет расти со временем.

МЕТОДИКИ ДЛЯ ПОИСКА ИДЕЙ

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

ИНТЕРВЬЮ С ПОЛЬЗОВАТЕЛЕМ

Минимальная частота проведения интервью — два-три часа каждую неделю.

Мой любимый вариант — привлечь к интервью трех человек: продакт-менеджера, дизайнера продукта и одного из инженеров-программистов продуктовой команды (мы обычно по очереди посылаем тех, кто изъявляет желание присутствовать на встрече). Обычно дизайнер ведет беседу (потому что этих специалистов обучают этому), менеджер продукта ведет записи, а разработчик наблюдает.

КОНСЬЕРЖ-ТЕСТ

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

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

ХАКАТОН

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

Про работу с программистами:

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

Про работу со стейкхолдерами:

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