Новое место работы: пошаговая инструкция для Product Manager

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

Узнать у СЕО и иже с ним, какие цели у продукта на ближайший год, далее разделить на 6 и 3 месяца (для подведения итогов). Это необходимо как минимум для того, чтобы избежать давления сроков.

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

Познакомьтесь с каждым членом команды, желательно обойти все углы офиса и задать самый важный вопрос: «Что я могу сделать, чтобы облегчить тебе жизнь?» Это покажет, что ты пришёл не только давать поручения, но и проявляешь реальную заботу о всём коллективе, главное, делать это искренне, фальшь сразу заметят, и «стая вскоре изгонит вожака». Необходимо следить не только за тем, что говорят, а ещё за тем, как говорят. После разговора можете быть шокированы тем, чего могут ожидать от РМ. Цель таких встреч — снять «груз» с каждого члена команды, всем важно быть услышанными. К примеру, разработчику важно, чтобы вы понимали баги проекта, и то, что они могут внезапно возникать не по его вине, а его это беспокоит, ведь иногда срываются сроки. Главное — помнить, что никогда не надо смешивать личное с рабочим.

Да, каждому РМ, необходимо знать техническую часть продукта, не обязательно знать досконально, но понимать процесс очень важно! В этом вопросе вам поможет TeamLead или CTO продукта. Не стесняйтесь задавать ему вопросы и углубляться в суть. Узнайте, на каком стеке реализован продукт, как устроены DEV и Prod версии, с какими трудностями встречается команда разработки. Эта встреча, как инвестиция в будущее, вы будете лучше понимать команду, а значит экономить время разработчиков, а как следствие, деньги всего проекта! На этом же этапе лучше изучить всю документацию продукта, если что-то устарело, постараться актуализировать.

Каждый человек, придя в новый проект, хочет внести свою лепту в развитие, и Рroduct обязан это делать, но нельзя «пороть горячку», не разобравшись в продукте. Иногда по такому принципу можно узнать уровень компетентности менеджера; junior product, чаще остальных, захочет что-то изменить, он полон энергии и решительности и ещё не сливал большие бюджеты, а также на него давит груз: «Если я ничего не придумаю, то меня могут уволить, как бесполезную единицу». Коллеги, на любой стадии развития (Junior, Middle, Senior, Owner) избавляйтесь от этого давления.

Лучше это сделать самостоятельно, проработать Lean Canvas, но это важно делать после того, как вы уже разобрались в продукте, узнали УТП, персоны и сегменты пользователей продукта. Можете попросить маркетолога, BDM или руководство подключиться к этому процессу. Пусть каждый заполнит канву вместе с вами, затем уже вы сделаете последний вариант и утвердите его с CPO проекта.

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

Экономика одного юнита (пользователя), тесно связана с ключевыми метриками продукта, уделите этому должное внимание. Между нами, на эту тему надо писать большую подробную статью, чтобы подробно раскрыть важные показатели. Если будет интересна тема, напишите в комментариях, разберём её, а пока просто включите себе в чек-лист.

Сегодня все борются за новых пользователей, и этот процесс становится всё дороже и будет только дорожать, поэтому ВАЖНО понимать своего пользователя, давать ему то, что он ждёт от продукта, а чтобы это сделать, необходимо собирать, ненавязчиво, обратную связь. Многие не уделяют этому должного внимания, а зря! Важный показатель в любом продукте – это Retention rate, и каждая компания должна стремиться к тому, чтобы превратить пользователя в адвоката собственного продукта. Для этого необходимо быть честными с вашими клиентами на всех этапах их пользования, если где-то совершили ошибку, не беда, честно скажите об этом, пользователь поймёт, что вы работаете над качеством, а значит это не повторится.

Для начала я советую сформировать EPICи на их основе выдвинуть гипотезы в формате User story, но сейчас большинство склоняется к формату JTBD, лучше провести и тот, и другой вариант, затем обязательно проверить валидацию всех гипотез, самый популярный способ — это «прогнать» гипотезы по пиратской воронке AAARRR, но есть и другие способы (если интересно, подробнее напишите в комментариях, сделаю разбор). Зачем это делать? Надо понимать, что 9 из 10 гипотез убыточны, а на их проверку уходит примерно 1-2 месяца работы команды, а это очень дорого, поэтому одна из основных задач PM – суметь отсечь всё ненужное!

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

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

После того, как интегрировали фичу, перепроверьте CJM и по необходимости внесите корректировки в User flow.

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

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

Подведём итог. Работа продактом очень классная и интересная, главное — подойти к процессу творчески, но с соблюдением всех технических правил, воспринимайте работу в компании как личное дело. Любой PM — это предприниматель: от принятых решений будет зависеть благополучие не только ваше, но и всей команды. Вы не только ответственны за рост ключевых показателей, но и микроклимат коллектива на ваших плечах!

На каждый пункт, начиная с 4го, можно написать отдельную статью. Чтобы раскрыть тему более серьёзно и сделать углубленный разбор, в комментарии укажите, какой пункт более важен для вас, я постараюсь написать подробный разбор. А сейчас можете подписаться на мой телеграмм-канал (ссылка под текстом), в котором я часто публикую все новинки из мира маркетинга и IT (с продуктовым подходом). Как и везде, важна благодарность за всё, благодарите свою команду всегда, даже за неудачу, а сейчас лучшей благодарностью от вас будет поставленный лайк. До новых встреч!

https://t. me/ProductMarkett — мой телеграмм канал.