Во время, когда всё стало политикой. Во время, когда ты не можешь выразить своё мнение, пока хотя бы один твой родственник находится в РФ. Во время, когда за правду сажают на 15 лет. В это время мои любимые, по совпадению, украинскиe каналы Lankarra (ранее – "В шлеме") и Alex007 продолжают работать, хотя им явно тяжелее, чем мне. И я делаю вывод, что и мне не нужно останавливаться. Актуальны ли по-прежнему темы, про которые я пишу: управление изменениями, digital, Linux? Думаю, да, поэтому погнали.

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

• я работал продактом полгода
• я полностью перешёл в тот самый digital 25 января 2022 года
• работаю я руководителем проектов, и здесь не так много отличий с руководителем проектов в не-digital
• регулярно общаюсь с нескольким продактами, они являются моими заказчиками

Думаю, после этого у вас сформируются правильные ожидания: я кое-что знаю о digital и о продакт-менеджменте, но это не отменяет того, что где-то могу быть сильно не прав, поэтому нужно проверять в других источниках. Тем не менее, Андрей Маленков, который менторил меня и который обладает намного более обширным опытом продакта, проверил тот список источников знаний о продакт-менеджменте, по которому я пойду. Список этот хранится на GitHub, но там много всего, и материалы расположены не в порядке изучения, а по областям знаний. Здесь же я расскажу, с чего начинать, и какой список знаний и навыков достаточен для того, чтобы уже начинать работать по профессии.

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

• Видение продукта
• Рынок и клиент
• Дизайн
• Разработка

Видение продукта

Видение детализируется в таких инструментах, как Business Model Canvas, Value Canvas, но может иметь такие приземлённые формы, как презентации (см. статью про общие навыки) и финансовую модель. Но это всё прикладные вещи, первичным же является понимание процессов, которые связаны с продуктом, и здесь есть две базовых книжки:

• Inspired by Marty Cagan
• Escaping the Build Trap by Melissa Perri

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

• Информация собрана и систематизирована, не надо искать и сопоставлять (противоречащие) статьи
• Это действительно классика профессии
• Книжки переписаны профессиональными журналистами, поэтому читаются увлекательно

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

• Выбираешь то, что можешь объяснить и продать
• Берёшь то, что подходит под специфику конкретного случая: у кого-то болит количественный рост, а у кого-то прибыльность клиента
• Комбинируешь, чтобы была и экономика, и натуральные показатели

Дальше есть механика построения dashboard на основе показателей – лично мне повезло, у меня был SEO-специалист, который всё сделал, я лишь уточнил вид некоторых графиков. По поводу вида графиков всё таинственное знание про отображение информации содержится в курсах по презентациям, тут ничего нового нет. Набор данных и цели вполне себе однозначно (и уже лет 40 минимум) определяют, какие графики использовать.

Рынок и клиент

Быть постоянно в контакте с клиентом и жить его потребностями – это хлеб продакта, поэтому ежедневная рутина, помимо отслеживания метрик, это:

• Исследования рынка
• Беседы с клиентами
• Проведение экспериментов

Насчёт исследований рынка – это либо использование существующих данных (что всегда быстрее и дешевле), либо заказ исследований, тогда надо написать техническое задание. Честно, даже не знаю, что тут можно объяснить: с одной стороны, методов много, с другой, на выходе одно и тоже; как это выглядит, можно посмотреть, если вбить в поиск "исследования рынка" или "market research".

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

Ну а проведение экспериментов – это про репрезентативную выборку и про метрики и критерии успеха (конкретные значения этих метрик).

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

Дизайн

С дизайнерами надо говорить на их языке, и для этого лучше всего подходят курсы по дизайну. Лично я выбрал по стоимости и отзывам на Udemy, и вроде этого хватило. Сейчас все рисуют дизайн в Figma, и я видел, как многие продакты это делают. Но если есть выделенные дизайнеры, то они явно сделают это лучше, поэтому это либо первоначальный набросок, либо на дизайнерах сэкономили. Причём у нас была дискуссия, где проходит граница между дизайнером и продактом, насколько детально продакт должен делать техническое задание на дизайн: мне кажется, надо давать возможность людям раскрыть свой потенциал, и ставить задачу на верхнем уровне, какие проблемы / вопросы клиента должны быть решены в итоге. Потом обсуждать предложенные дизайнерами варианты.

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

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

Разработка

С точки зрения разработки есть несколько живых подходов:

• Waterfall
• Scrum
• Kanban

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

Ответ на часто задаваемый вопрос: нужно ли продакту знать python и SQL? У меня ответ такой:

• Знать SQL очень полезно, чтобы не обращаться за каждой мелочью по сопоставлению данных к разработчикам; но это нужно только для больших объёмов данных, поскольку небольшие объёмы продакты (о ужас) обрабатывают в электронных таблицах и не краснеют при этом.
• Знать python не нужно. Изучать python полезно для развития мозгов, но если у тебя продукт на Scala (как это было у меня), знание python тебе никак не поможет. А если продукт на python, тоже не поможет, кроме как случаев, когда нужно понять разработанные до тебя алгоритмы. Хотя алгоритм расчёта представляет собой обычно небольшой участок кода, а управляющие структуры на всех языках похожи.

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

Ну и есть ещё приоритизация разработки, тут куча фреймворков. Лично мне в совершенно разных ситуациях (и даже для приоритизации проектов) очень помогал RICE, и я не вижу причин его не использовать, иногда с дополнениями. Хотя в отдельных специфичных случаях другие фреймворки могут быть более полезны.

Заключение

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