5 главных ошибок джуниоров в мире продуктовой разработки: Как их распознать и исправить

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

Вместе с наставником курса «Продакт-менеджер» Яндекс Практикума Иваном Будариным рассматриваем самые распространенные проблемы джунов и узнаем, как их преодолевать.

Проблема №1: врать себе

Так бывает, когда человек во что-то сильно верит и хочет это реализовать. Например, джун придумывает фичу, приклеивает к ней ярлык «гениально» и уговаривает начальство и команду ее реализовать. По пути встречаются аргументы, что делать фичу все-таки не надо, но работа продолжается. И вот, спустя пару месяцев, несколько тысяч долларов и множество кружек кофе — готово! Но все метрики по продукту красные. Это происходит потому, что джун не признался себе, что настаивает на новой фиче для воспевания собственного эго, а не для клиента. И не провел исследований из-за своего же ярлыка «гениально».

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

Проблема №2: бояться быть проактивным

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

Объясню на примере, почему это существенно. Допустим, руководитель ставит задачу: нужно добавить опцию X, чтобы пользователи могли делать Y. Есть ли такой запрос у клиента и оптимально ли порученное решение — неизвестно. И если на этом этапе продакт просто кинется выполнять задачу, это будет ошибкой. Важно сделать шаг назад и вернуться на уровень изучения проблемы и предполагаемого решения. Даже если вы считаете, что у вашего начальника гораздо больше опыта.

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

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

Проблема №3: не расширять область знаний

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

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

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

Проблема №4: всегда оставаться в зоне комфорта

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

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

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

Проблема №5: неграмотно презентовать результаты

Мало что-либо сделать, нужно грамотно это презентовать. Иначе можно отлично решить задачу, но неверно расставить акценты, рассказывая об этом — и начальство или инвесторы вас «съедят». Обидно, особенно если была проделана действительно важная и стоящая работа.

Допустим, презентуя новую фичу, вы заведомо обречены на провальное выступление, если скажете что-то в духе: «Мы сделали, фича классная, долго работали, очень старались, потратили много денег». Важно объяснить, какую задачу клиента решали, насколько она для него важна, почему выбранный способ — оптимальный, как улучшились метрики. Умение доходчиво донести до коллег и руководства свой прогресс сработает на доверие к вам и восприятие вас как первоклассного специалиста.