Автор: Lulu Cheng, nov. 2015
Переводчик: Фёдор Александров, авг. 2022
Предисловие переводчика
Я только начинаю свой путь в управлении продуктами, и моя нынешняя отрасль косвенно относится к желаемой. Отсюда, мне было интересно узнать описанные базисы и я решил перевести статью на русский язык для таких же начинающих, как и я. Ссылку на данную статью я нашел в книге Мэтта Лемэя от O'Reilly "Product Management in Practice". Опытным специалистам вещи, написанные ниже могут либо быть хорошо известными, либо критически не понравиться. Все вопросы - к Лулу Ченг. :) Приятного прочтения!
«Как ты можешь быть продакт-менеджером поисковой системы, если ты не технарь?»
Такой вопрос ставится с глупой серьезностью – той, какую вы ожидаете от социального взаимодействия в Долине [Кремниевой]. И он, в защиту спрашивающего, справедлив, хотя вряд ли я бы задала его в первые пять минут знакомства.
Принято считать (и основная часть вакансий гласит), что кандидаты на позицию продакт-менеджера должны иметь BA/BS в Computer Science или близкой технической области, либо релевантный практический опыт. Это обычно значит, что у вас должен быть проект, на который вы можете сослаться, сказав: «Это сделал я». Есть много заметных исключений из такого подхода, но «быть техническим» (прим. ред. Be technical) – это все еще скорее обязательно, чем «будет плюсом».
Недавно, компании стали реформировать это требование как «быть технически подкованным». Заметьте, как они об этом пишут (забавно попробовать угадать компанию):
- Вы достаточно технически подкованы, чтобы общаться с разработчиками об архитектуре и продуктовых решениях
- Отличный уровень коммуникации, включая возможность дискутировать на «техническом уровне»
- Глубокие аналитические навыки. Степень в CS (или опыт программирования) идеален, или любовь к данным, сложным частным случаям и задачам.
Хотя я немного предвзята, я думаю, этот сдвиг в основном неплох, и я только добавлю ему значимости для повышения по должности. [Перечисленные вакансии – это CTO и Technical Director]. Управление продуктом – столь же искусство, сколько наука; столько же психология, сколько статистика; столько же широко и абстрактно, сколько детально. Ежедневные задачи и их технический пул широко разнятся в зависимости от рынка и размера компании, от того продукта, над которым вы работаете.
В то же время, качества, которые делают вас «универсально уважаемым» продакт-менеджером, редко связаны с технической экспертизой. «Трата времени для хорошего инженера» - говорили они. [Болтовня. Soft Skills]. Но вопрос остается – что это значит «быть технически подкованным»? Как к этому прийти? Как в промежутках получать авторитет перед своей командой?
Когда я переходила из маркетинга в PM три месяца назад, я осознала, что интернет неожиданно пуст на знания в этой области. Я хочу поделиться опытом поиска ответа на эти вопросы в начале моего пути. Надеюсь, это будет полезно другим продакт-менеджерам, приходящим в эту сферу без технического бэкграунда.
Остаток этой статьи поделен на две части, отражая мой основной подход:
- Установить "технический минимум" и вкладывать свое время в его изучение
- Построить доверие и авторитет на понимании того, как оказать "немедленное влияние" [полезное].
Установление технического минимума и инвестирование своего времени
Мнений на эту тему много, но я говорю об этом, как о возможности делать следующее (в порядке увеличения сложности):
- Отслеживать запросы пользователя (или набор запросов), сопоставляя с создающей их проблемой
- Понимать длительность разработки варианта А или варианта Б [бэклог, спринты, фичи, миноры]
- Предвидеть проблемы и реализацию конкретных решений
- Устраивать «мозговой штурм» потенциальных решений технических проблем
- Видеть возможности внедрения новых технологий
Относительная важность этих критериев будет изменяться в зависимости от вашего продукта – например, для клиентского приложения новые технологии могут быть важнее, когда B2B-компаниям следует быть внимательнее к скоупу проекта для соответствия датам релиза – от продакт-менеджера ожидается умение взвешивать все эти варианты.
С детальным пониманием, куда двигаться, встает следующий вопрос: «как двигаться?». Вот некоторые шаги, которые были для меня полезны (тоже отсортированы по важности):
Начните с любопытства
Это единственный обязательный пункт в списке. Искреннее любопытство касательно технических проблем увлечет вас надолго; без этого будет значительно хуже. Конечно, в определенной степени можно искусственно взрастить любопытство, но я бы задумалась об этом еще на собеседовании. У Эллен Чизы есть замечательная статья на эту тему, если вы хотите узнать об этом больше.
Цените креативность, присущую разработчикам
Этот пункт вытекает из прошлого. Вам не нужно рыть глубоко для осознания этого. В своей сущности, разработка – это процесс создания ценности из ничего (something from nothing), и, как и в любом творческом процессе, она всегда непосредственно связана с беспорядком. За каждой попыткой разработки новой «фичи» стоит инженер, совершающий дюжины предположений, взвешивающий компромиссы и продумывающий детали и частные случаи. Не понимать эту динамику – значит лишать инженеров автономности и права творчества, так необходимых им для лучшей работы.
Заранее выделите время, чтобы поговорить с инженерами
Прочитайте все, что можете найти в первые несколько дней, набросайте список вопросов, возьмите флипчарт и попросите любого разработчика пробежаться с вами по этим вопросам. Получить достаточный фундамент, задав правильные вопросы. Не думайте, что получите много информации, пялясь в экран – инвестируйте первое время на работе в общение с командой разработки – это сыграет свою роль в будущем.
Сведите всю полученную информацию к доступному формату
В этом месте вы, вероятно, плаваете среди аббревиатур и небрежных диаграмм. Сведите всю новую информацию в один документ, делитесь им с новыми сотрудниками как «базой знаний». А лучше, найдите возможность презентовать эту информацию другой команде. Это отличный вариант, чтобы узнать, правильно ли вы всё поняли, а также понять, где у вас пробелы и куда углубиться.
Используйте обратную связь и баг-репорты чтобы сопоставить шаблоны и проблемы
Возвращаясь к нашей формулировке «технической подкованности», первым критерием является установление соответствия между запросами пользователей и стоящей за ними проблемой. Один из вариантов реализации – сопоставить обратную связь и баг-репорты.
Как продукт-менеджер, вам досталась честь быть первым ответчиком на обратную связь о продукте. В любой момент вы будете получать множество отзывов о вещах, которые построены сомнительно или криво. Коллега пишет вам в Slack: «Нет соответствий в поиске с апострофами». Потом пишет мама: «Пыталась поискать ‘%Название компании%’. Ничего не нашлось :(». Если вы организовали отслеживание проблем, две вещи будут происходить постоянно:
- Вы сталкиваетесь с лексикой, которую разработчики используют для обсуждения багов.
- Вы начинаете связывать разные запросы по симптоматике одной и той же проблемы.
Таким образом, фидбэк вашего коллеги и вашей мамы должны сойтись в одну корневую проблему: «Логика нормализации автозаполнения не включает в себя пунктуацию». Получая такой опыт, вы также будете развивать чувство значимости и приоритета различных проблем.
Отчасти ознакомьте себя с базисами программирования
Здесь не нужно фанатизма – цель в том, чтобы иметь возможность ответить на простые вопросы, по типу «где и как мы неправильно определили переменную» без необходимости отвлекать разработчиков.
Сфокусируйтесь на ключевых идеях
В каждой области есть концепции, которые будут возникать снова и снова. Изучите эту специфику для computer science в целом, и для вашего продукта в частности.
Станьте «толстокожим»
Закон Каннингема гласит: «Лучший способ получить ответ в интернете – это не задать вопрос, а разместить ложный ответ». [Это эквивалент французской поговорки «prêcher le faux pour savoir le vrai» - лгать, чтобы узнать правду]. Во многом, это хорошая метафора о продакт-менеджере: ваша работа – приходить с идеей или макетом, который все остальные будут потом разбирать. Суть не в том, что вы предложите тупую идею (хотя множество черновых вариантов – именно такие), а в том, что вы начнете диалог.
Выстраивайте авторитет на понимании того, как получить немедленную ценность
Изучение новых навыков отнимает ваше время; когда это происходит на работе, у вас нет прелести студентов очного отделения. Вам придется выделить области, где вы сможете оказывать моментальное влияние и сразу начать вкладываться [своими навыками в продукт], пока вы только растете. Надеюсь, это не так сложно, ведь во многом нас и нанимают из-за набора дополнительных навыков, которые мы предлагаем.
Стоит еще обдумать следующие варианты:
Углубитесь в данные
Это идея о том, что у всех есть «суперсила» - некое качество, которое при его включении заставляет людей работать с вами. В общении с дизайнерами это может проявляться в возможности быстро генерировать диапазон высококачественных исследований. Для разработчиков это может быть возможностью быстро склепать прототип, помня, когда и как переключаться на написание чистого и расширяемого кода. [По мнению автора, это крайне сильно граничит с Lean-подходом.]
Для продукт-менеджеров, я думаю, ближайший эквивалент состоит в свободном знании данных. Необходимо «разбираться в данных». Когда кто-то спрашивает: «Мы знаем, сколько людей используют АБВ-фичу?», и вы отвечаете: «Да, грубо говоря, 100 человек» - вы растите авторитет. Возможно, это причина, по которой продуктовые аналитики стали одними из важнейших людей в управлении продуктами.
На практике, «разбираться в данных» значит знать:
- Какие внешние и внутренние события идут в логи – и как
- Где хранятся данные
- Как делать запросы к данным
- Как анализировать результаты экспериментов
- Лучшие методики и "архитектуры" экспериментов
Делайте фундаментальную, но результативную (движущую) работу
Собирайте эффективные встречи! Это значит:
- Цель встречи ясна всем приглашенным
- Присутствуют все ЛПР (лица, принимающие решения)
- В начале встречи вы установили правильный контекст
- В конце встречи есть четкие задачи и ответственные за их выполнение лица
- Вы записываете важные майлстоуны (вехи [встречи]) и быстро их распространяете
При этом, грешим на овер-коммуникацию и овер-документацию. Знайте, когда электронная почта - лучший канал коммуникации, а когда нет. Запоминайте основную линию вопросов и жалоб от других команд и централизуйте ответы на удобном ресурсе.
Спросите разработчиков: «Какую лишнюю работу вам приходится выполнять?». Постарайтесь снять с них ненужные заботы – файлинг багов, регулировку требований по логгингу, ответы на вопросы другим командам и т. п.
Углубитесь в ваш опыт и сильные стороны
Ранее, я пыталась избежать особого внимания к своему маркетинговому бэкграунду лишь потому, что я не хочу напоминать людям, что я – не технарь. Рефлексируя, – это было достаточно глупо, ведь мои предшествующие навыки были одной из причин, почему меня наняли: будь то проведение полевых исследований, пользовательские интервью, отправка корреспонденции по почте… Впрочем, наращивайте ваш импульс маленькими шагами.
Обеспечьте доступную среду для принятия решений
Помните метафору про «суперсилу»? Этот пункт тоже близок к разделу «разбирайтесь в данных». Хороший продакт-менеджер вносит ясность в каждый разговор, в котором участвует – у него есть умение отвечать на острые вопросы. Он может ответить какую проблему мы решаем и почему, как мы «измеряем успех», в каком порядке мы действуем «от и до». Что важнее, каждый в команде должен знать эту структуру.
Выделите время на просвещение своей команды в контекст
В качестве продакт-менеджера, вам часто приходится быть единственным представителем команды на встрече (а часто - быть в списке тех, кому придет копия электронного письма). Держите всех в курсе ваших взаимодействий с другой частью компании. Не обязательно делать этого моментально (в этом нет принципиальной разницы), но накопление информационного контекста упрощает обсуждение спорных решений в рабочем процессе. Спустя время, команда сама будет активно приходить к вам с вопросами и беспокойствами.
Мне бы было приятно услышать, если вы выполнили эти шаги – особенно те ребята, кто поменял отрасль на продакт-менеджмент из не-технарей. Как я отметила в начале, ресурсов на эту тему не так много и бывает сложным получать лучшую теоретическую подготовку за неимением личного опыта. Давайте изменим это!
Статью перевёл Фёдор Александров, август 2022.