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

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

• Стимулы: влияет ли успех какого-то компонента продукта на поведение пользователей при работе с другими его частями?

• Элементы UI: будут ли изменения, примененные к какому-то компоненту в одном месте, работать и в других местах его использования?

• Платформы: работает ли обновление одинаково на мобильных устройствах, стационарных компьютерах и через API разработчика?

• Гибкость: какие изменения легче или сложнее внедрять в будущем? Не привязываете ли вы себя к определенным решениям?

• Требования к ресурсам: приведет ли это изменение к проблемам масштабируемости на стороне сервера или в системах клиентского обслуживания?

• Жизненный цикл пользователя: какие последствия в долгосрочной перспективе будет иметь изменение (например, предоставление неограниченного пространства новым пользователям)?

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

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

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

БУДЬТЕ ЛЮБОПЫТНЫ: ПРОГНОЗИРУЙТЕ И ИССЛЕДУЙТЕ

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

Начните с прогнозирования ваших ожиданий:

• Если вы собираетесь ознакомиться с результатами эксперимента, сделайте быструю прикидку того, какими могут оказаться цифры.

• Если вы планируете посетить собрание, попробуйте угадать, что скажет каждый из участников.

• Если вам предстоит тренинг, предположите, чему вы на нем научитесь.

Это поможет вам замечать что-то действительно интересное или неожиданное.

Без прогнозов ваш мозг может вас обмануть, и вы решите, что полученная вами информация соответствует вашим ожиданиям. Постфактум очень легко ошибочно принять мысль «Это имеет смысл» за «Я этого и ждал».

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

НЕДОСТАТОЧНО ПРОСТО УКАЗАТЬ НА ПРОБЛЕМУ

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

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

Вместо того чтобы указывать на обнаруженные вами проблемы, подчеркните хорошие результаты, которых вам удалось достичь. «Вот причины, по которым это сделать невозможно», – так сказать легко, но не слишком полезно. Лучше сказать: «Я знаю, как это сделать». Это сложнее, но и намного более значимо.

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

ОЗВУЧИВАЙТЕ СВОИ ФРЕЙМВОРКИ

Фреймворк – это секретное оружие PM. Возможно, вы уже создали и используете фреймворки – по сути, это просто схемы принятия решений, – но забыли сформулировать их для коллег.

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

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

Это дает массу преимуществ:

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

• Снижение напряжения внутри команды: ваши коллеги будут менее негативно реагировать на новые данные, влияющие на решение. Если им известен только сам факт смены решения, они могут предположить, что предыдущий вариант не был тщательно продуман. Но если коллеги видят последовательно выстроенный фреймворк, они могут самостоятельно прогнозировать возможные изменения и лучше понимают, почему от первоначального решения пришлось отказаться.

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

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

• Более эффективное принятие решений: ваши фреймворки будут становиться лучше, если вы их озвучите. Допустим, вы считаете, что для начала вашей новой команде следует взять простой проект. Вы объясняете коллегам, что полезно провести пробную совместную работу (с участием PM, инженеров, дизайнеров) без серьезного вмешательства руководства, и таким образом лучше узнать друг друга и изучить новую кодовую базу. Эти детали помогут сузить поиск и совместно найти тот «простой» проект, который подойдет лучше всего. Если бы вы не представили свой фреймворк команде, возможно, этот проект даже не пришел бы вам в голову.

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

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

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

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

РАСШИРЯЙТЕ ГРАНИЦЫ ОПТИМИЗАЦИИ И УЧИТЫВАЙТЕ ДОЛГОСРОЧНУЮ ПЕРСПЕКТИВУ

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

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

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

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

ВИЗУАЛИЗИРУЙТЕ

Однажды я наткнулась на странный баг: уведомления пользователя попадали в архив сразу же после получения. Дежурный инженер стал разбираться и был немало озадачен – уведомления не были помечены как архивированные. Я вспомнила, что система уведомлений была построена таким образом, что архивировать уведомления можно было двумя способами – по отдельности или при помощи кнопки «Архивировать все». Я предположила, что дата последней архивации пользователя была настроена в нашей базе данных на какую-то дату в будущем. Мы проверили, и оказалось, что так и есть! Мы исправили дату – и проблема была устранена.

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

Ознакомьтесь с записями, относящимися к основным объектам в базе данных. Какая информация четко прописана, какие сведения нужно искать отдельно, а каких данных нет вообще? Непосредственно доступная информация проста в использовании, в то время как применение других сведений может идти сложнее или медленнее. Возможно, вам удастся найти все полезные данные, которые будут предварительно рассчитаны и готовы к использованию (например, сведения об активности или местонахождении пользователя).

Изучайте компоненты в контексте фреймворка. Это могут быть UI-компоненты (например, настройки цвета или кнопки) и инфраструктура (например, Elastic Search от Amazon). Для каждого элемента выполнение задач может быть легким, требовать более дорогостоящей кастомизации или быть совершенно невозможным. Если вы визуализируете, какие компоненты использовать при создании обновления, вы сможете предсказать все связанные с ними преимущества и ограничения.

МАТРИЦА 2×2

Матрица 2×2 – очень популярная схема. Она невероятно проста, но очень хорошо подходит для оценки вариантов и организации информации в целом.

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

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

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

Эти критерии и варианты можно оформить в виде модели 2×2 и упростить решение проблемы.

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

КРАСНО-ЖЕЛТО-ЗЕЛЕНЫЕ ТАБЛИЦЫ

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

МЫ ОПТИМИЗИРУЕМ, ЧТОБЫ…

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

ДЕРЕВО РЕШЕНИЙ

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

Для текстового варианта дерева можно использовать маркированный список с отступом:

• Если результат A/B-теста…

◊ Положительный

« Если есть жалобы от клиентов…

+ Опросить клиентов и повторить.

« Если нет жалоб от клиентов…

+ Запустить продукт

◊ Отрицательный

« Не запускать продукт

◊ Нейтральный

« Если есть довольные клиенты…

+ Если нет жалоб от клиентов…

○ Запустить продукт

« В остальных случаях…

+ Не запускать продукт

ЭЙГЕН-ВОПРОСЫ

Когда Шишир Мехротра (Shishir Mehrotra), соучредитель и CEO Coda, работал продакт-менеджером в YouTube, в компании шли бурные и безрезультатные споры. Инженеры предлагали сделать ссылки, которые бы вели на сторонние сайты с ТВ-шоу, недоступными на YouTube. Представители бизнеса не соглашались. Что же было делать?

Пытаясь решить эту проблему, Мехротра подумал, что стоит направить дискуссию в другое русло. За несколько недель до этого он участвовал в качестве наблюдателя в обзоре продукта Google Product Search и увидел, что руководители рассматривали свой выбор с точки зрения стабильности в противовес полноте продукта. Мехротра понял, что такая концепция отлично подойдет и для него.

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

Удивительно, но этот подход разрешил не только первоначальную проблему, но и несколько других противоречий, которые ранее казались не относящимися к делу. В итоге было решено не выдавать в результатах поиска внешние ссылки. Также создатели контента потеряли возможность отключать доступ к контенту с разных устройств, а все сторонние встроенные проигрыватели были удалены. Было даже принято решение отозвать у Apple права на приложение YouTube для iOS.

Мехротра назвал такой тип корневой проблемы «эйген-вопрос» (eigenquestion)[36]36
  Термин придуман по аналогии с понятием линейной алгебры «собственный вектор» (eigenvector) и означает «ключевой, главный вопрос». – Примеч. ред.


[Закрыть]. Ответ на него, как правило, подходит и для последующих, вытекающих из первого, вопросов[37]37
  Подробнее об эйген-вопросах читайте на странице https://coda.io/d/Eigenquestions-The-Art-of-Framing-Problems_dQnxKKTYZ4r.


[Закрыть].

Чтобы использовать такие вопросы на практике, необходимо выполнить следующие действия:

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

2. Для каждого выбранного вопроса задайте дополнительный: «Если мы примем это решение, на какие еще вопросы мы параллельно ответим?» Определите, ответ на какой вопрос решит большее количество задач. Он и будет вашим эйген-вопросом.

3. Вместе со своей командой перечислите варианты ответов на эйген-вопрос и определите плюсы и минусы каждого из них.

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

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

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

ПЯТЬ ПОЧЕМУ

Фреймворк «Пять почему» полезен для ретроспективного анализа проблем. Если вы будете активно его применять, вы не только отточите свой навык принятия решений, но и, помимо выявления поверхностных факторов, научитесь докапываться до первопричины[38]38
  Подробнее о методе «Пять почему» читайте на странице https://wavelength.asana.com/workstyle-ask-5-whys-to-get-to-the-root-of-any-problem/.


[Закрыть].

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

Чтобы применить фреймворк «Пять почему», сделайте следующее:

1. Составьте график работы с людьми, вовлеченными в проблему.

2. Объясните, что цель в том, чтобы выявить более глубокие системные проблемы, а не найти виновных.

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

4. Сформулируйте проблему и спросите, почему она возникла. Запишите все ответы первого уровня.

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

6. Продолжайте копать, пока не почувствуете, что нашли первопричину. Часто это технологический сбой.

7. Сделайте выводы и зафиксируйте полученные знания, примите соответствующие меры, чтобы избежать повторения подобных проблем в будущем.

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

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

• Подавайте информацию наглядно: таблицы и диаграммы невероятно полезны для анализа проблем. Если вы зашли в тупик, попробуйте представить все «за» и «против» в нескольких форматах, пока не отыщется тот, который сработает.

• Следите за всей системой в целом: самые интересные проблемы имеют комплексные последствия, а их решение требует системного подхода. Убедитесь, что вы полностью видите контекст. Не упрощайте проблему до точечного решения. Лучше составьте список возможных последствий и сопоставьте с ними свои решения.

• Озвучивайте свои фреймворки: не предлагайте только решение, поделитесь своими мыслями и умозаключениями, которые привели к его принятию. Так люди будут доверять вашему выбору и принимать согласованные решения в будущем.