Инструменты продакт-менеджера: чем продакты пользуются каждый день

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

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

Чтобы понять кто такой продакт-менеджер (ПМ), лучше всего начать с описания того, кем он НЕ является:

ПМ — это не проджект-менеджер.

Звучит похоже, но есть фундаментальная разница между проджект- и продакт-менеджером.

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

Таким образом, за качество идеи отвечает продакт, а за ее реализацию — проджект.

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

Что касается проджект-менеджера, то есть мнение (в том числе авторитетного института PMI), что работу проджект-менеджеров в ближайшем будущем можно будет полностью автоматизировать, а вместо этого проджекты станут кем-то вроде тим-билдеров: умения проявить и распознать soft skills будут наивысшей ценностью в данной работе — важнее, чем знание методологий ведения проектов.

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

Эти искаженные ожидания количественно перевесили правильные ожидания от ПМ, а именно:- умение смотреть рынок, - анализировать и принимать решения о развитии продукта,- работать с ожиданиями.

ПМ обязан знать, ЧТО нужно делать (иногда на несколько месяцев вперед), но он не обязан знать, КАК это делать — для этого есть инженеры и дизайнеры.

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

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

Это эффективное решение задач пользователей.

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

Hypothesis — Выдвижение гипотез

Гипотеза должна быть всегда. Даже в нулевой день продукта, когда он еще на стадии идеи, все равно есть какая-то гипотеза, например, “Чем наш будущий продукт будет кому-то полезен?”.

Если же продукт уже существует и используется потребителями, то гипотезы могут быть уровня конкретного функционала: “Нужна ли будет определенная функция и поможет ли она эффективно решать задачу пользователя?”.

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

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

Из инструментов:

Action — Действие

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

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

ПМ, чаще всего, обязан контролировать реализацию самостоятельно на каждом этапе. Имплементация гипотезы в IT-продукте, как правило, начинается с дизайна: ПМ совместно с дизайнером и инженерами ищет способ, как реализовать гипотезу. На данном этапе стоимость ошибки чуть меньше, чем стоимость ошибки при неверной гипотезе, но все еще достаточно высока. Поэтому так важно работать с профессиональным UI/UX дизайнером, а не поручать эту задачу продакту (выше в разделе “кем ПМ не является” описаны причины).

Тем не менее, ПМ может донести свою идею визуальным способом через прототипирование в простых и понятных инструментах, таких как - Figma, - Omni Graffle, - Sketch, - Miro или других.

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

Эти артефакты хранятся и передаются команде, как правило, через инструменты управления проектами, часто в сочетании с внутренней WiKi (например, Confluence). Самые популярные инструменты для менеджмента проектов:

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

Data — сбор данных

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

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

Существует большое количество как публичных, так и self-hosted баз данных и инструментов для сбора метрик. Вот основные публичные:

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

Insight — выводы

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

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

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

“Примерить” на себя профессию продакт-менеджера можно в бесплатном симуляторе "Один день из жизни продакта".

В симуляторе вы «пообщаетесь» с пользователями, соберете прототип мобильного приложения, займетесь приоритезацией для команды разработки и познакомитесь с Jira 🤘

А если вы уже точно определились, что профессия продакта - это ваше и вы готовы обучаться, ждем вас на курсе “Профессия: продакт-менеджер”.

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

Поэтому основной фокус у нас на погружении студентов в продуктовую среду сразу со старта.

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