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

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

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

1. Замечайте проблемы качества: сюда относятся такие вещи, как элементы UI со сдвигом пикселей, неудобный дизайн, процессы, за которыми пользователю сложно уследить, функции, перестающие работать при пограничных условиях. Если вы плохо распознаёте проблемы качества, объедините свои усилия с кем-то, кто умеет делать это хорошо, например с дизайнером или исследователем потребностей пользователя.

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

Вот примерный вариант того, что вы можете сказать:

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

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

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

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

Подробнее о расстановке приоритетов читайте в главе 17 «Roadmap и расстановка приоритетов» (с. 219).

РАСШИРЯЙТЕ КРУГОЗОР: РАССМАТРИВАЙТЕ БОЛЕЕ РАДИКАЛЬНЫЕ РЕШЕНИЯ

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

Обдумайте следующие вопросы:

• Какие решения стали бы возможными, если бы численность вашей команды увеличилась?

• Что, если бы вы могли перенести сроки?

• Что, если бы вы могли стать партнерами с другой компанией или купить готовое решение?

• Можно ли решить проблему, не затрагивая продукт, например через службу поддержки клиентов или отдел продаж?

• Что, если бы вы могли изменить бизнес-модель?

• Если бы вы могли взмахнуть волшебной палочкой и создать все, что захотите, что бы это было?

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

ВАРФРЕЙМЫ, ПРОТОТИПЫ И ПОТОКИ

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

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

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

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

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

Для отрисовки варфреймов и прототипов обычно используют такие инструменты, как Balsamiq, Framer, Sketch, InVision или Figma. В каждом из них есть библиотеки или наборы стандартных элементов, поэтому вам не придется рисовать их самостоятельно. Инструменты для прототипирования постоянно развиваются, поэтому советуем изучить, какие из них являются самыми эффективными на сегодняшний день.

ДЕРЕВО ВОЗМОЖНОСТЕЙ

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

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

Хорошую модель этого процесса предложила Тереза Торрес (Teresa Torres); она назвала ее «дерево возможностей»[48]48
  Подробнее о дереве возможностей Торрес можно узнать здесь: https://www.producttalk.org/opportunity-solution-tree/.


[Закрыть]. С помощью этой модели вы можете расширить свое видение и представить возможные решения, которые помогут достичь вашей цели.

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

РАЗБОР ПРОДУКТА

Разбор продукта может принести ряд преимуществ, в том числе расширить знания предметной области, принципов дизайна и креативности. Он заключается в том, что вместе с коллегами вы берете чужой продукт и подробно его разбираете. Дженс-Фабиан Гоцманн (Jens-Fabian Goetzmann) описывает этот процесс так[49]49
  Подробнее об идее Дженса-Фабиана Гоцманна читайте здесь: https://www.jefago.com/product-management/product-teardowns-at-yammer/.


[Закрыть]:

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

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

В зависимости от целей подходить к разбору продукта можно по-разному.

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

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

• Креативность: пытаясь развивать свой творческий потенциал, изучите сразу много разных продуктов и проведите мозговой штурм на тему применения чужих шаблонов в своих продуктах. Может быть, они как-то хитро подходят к онбордингу[50]50
  Процесс знакомства пользователя с продуктом. Цель онбординга – объяснить клиенту все непонятные моменты (с помощью всплывающих подсказок, чата, приветственных писем и т. д.) и построить с ним долгосрочные отношения. – Примеч. ред.


[Закрыть] или используют машинное обучение? Каким мог бы стать ваш продукт, если бы вы попытались его пересобрать, как это сделали Spotify, Slack и Waze?

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

МОЗГОВОЙ ШТУРМ

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

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

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

Чтобы получить много разнообразных идей, в начале встречи дайте людям время самостоятельно описать или зарисовать свои мысли, а уже после переходите к групповому обсуждению. Если можно, до начала встречи дайте контекст и опорную фразу: «Как бы мы могли…» – чтобы люди при желании могли заранее обдумать свои идеи. Помните, что участие в мозговом штурме по принуждению любят не все!

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

Приглашайте участников из разных команд и с разными ролями

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

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

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

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

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

Структурируйте каждый мозговой штурм

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

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

• Мозговое письмо: сначала каждый пишет/рисует идею на отдельном листе бумаги, а затем передает его соседу справа. В следующем раунде вы строите свои идеи с учетом того, что написал/изобразил ваш сосед.

• Разные «шляпы»[51]51
  Психолог и философ Эдвард де Боно предложил метод шести шляп мышления. «Шляпы» – это разные типы мышления, примеряя которые можно посмотреть на задачу с разных точек зрения. – Примеч. ред.


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

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

Кейт Беннет (Kate Bennet), директор по продукту в Lab Zero, использует шаблоны ретроспективы спринта, среди которых есть несколько подходящих для проведения мозгового штурма:

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

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

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

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

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

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

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

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

Глава 8
Технические навыки

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

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

ПРИНИМАЙТЕ РЕШЕНИЯ О ПРОДУКТЕ ВМЕСТЕ С ИНЖЕНЕРАМИ

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

Лайка Каяни (Laika Kayani), старший директор по управлению продуктами платформы искусственного интеллекта (ИИ) в Lumiata, рассказала, как она работает с инженерами, чтобы создавать отличные продукты:

«Как PM, я очень четко понимаю, какой результат мне нужен, чтобы удовлетворить клиентов. Когда мы создаем новую модель машинного обучения, мы всегда договариваемся, оптимизируем ли мы скорость, стоимость или производительность, и обсуждаем варианты. Однажды я работала с клиентом, у которого возникли проблемы с производительностью их моделей МО. Как один из вариантов мы предложили упростить все функции МО разом. Я обсудила цели клиентов с инженерами, и мы вместе пришли к более эффективному решению – хостинг для инфраструктуры будет предоставлять наша компания, а не клиент, чьей внутренней IT-команде пришлось бы выискивать для этого дополнительные ресурсы».

Решения, которые принимаются сообща, зачастую лучше, чем те, которые мы принимаем самостоятельно.

ИЗУЧАЙТЕ ТО, КАК ТЕХНИЧЕСКАЯ ИНФРАСТРУКТУРА ВЛИЯЕТ НА ПРОДУКТ

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

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

У вас появятся свои суждения о том, какие продукты можно создать и сколько времени приблизительно на это уйдет. Если вас застанут врасплох или скажут: «Мы не можем это сделать, слишком сложно», попросите дать разъяснения, чтобы вы могли разобраться в деталях.

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

ЕСЛИ ВЫ УМЕЕТЕ ПИСАТЬ КОД, НЕ ОТКАЗЫВАЙТЕ В ПОМОЩИ

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

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

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