Как договариваться о приоритетах с продактом: советы для джуниора

Ты - джуниор-продакт. Ты только что получил новый запрос от руководства: «Сделайте фичу Х, она критична для выручки». Ты киваешь, говоришь «понял», и идешь к разработчикам. А они в ответ: «Это не влезет в спринт, у нас еще три критичных бага и технический долг, который уже ломает фичи». Что делать? Как договориться, когда ты не старший, не имеешь полномочий, и тебя слушают с подозрением?

Не назначай дедлайны до того, как поговоришь с командой

Самая частая ошибка джуниора - обещать сроки, не посоветовавшись с разработчиками. Ты думаешь: «Если я скажу, что сделаем за две недели, руководство будет довольным». Но на практике это выглядит так: ты обещаешь, команда молчит, потом через неделю выясняется, что фича не влезает, и ты выглядишь как человек, который не понимает, как работает продукт.

Вместо этого сделай так: когда тебе дают задачу, скажи: «Дай мне день, чтобы проверить с командой, реально ли это влезает». Потом собери разработчиков, спроси: «Какие риски? Что еще всплывет, если мы начнем это?» Если они говорят «нет» - не сдавайся. Спроси: «А что, если мы сделаем только половину? Или отложим что-то другое?»

Когда ты приходишь к продакту с готовым анализом - не с «они сказали, что не смогут», а с «вот что мы можем сделать, и что придется отложить» - ты перестаешь быть просителем. Ты становишься партнером.

Технический долг - это не проблема разработчиков, это проблема продукта

Ты слышишь: «Мы не можем делать новые фичи, потому что код - каша». Ты думаешь: «Это их проблема». Но нет. Технический долг - это когда продукт медленно ломается. Когда пользователь ждет 5 секунд, пока загрузится страница. Когда новая фича ломает старую. Когда баги появляются не из-за пользователей, а из-за того, что в 2022 году кто-то поспешил.

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

Вот как это работает на практике: каждый спринт выделяй 20% времени команды на улучшение кода. Не как «когда будет время», а как «обязательная часть плана». Это не отнимает фичи - это делает их стабильнее. Когда ты приходишь к продакту и говоришь: «В этом спринте мы сделаем фичу А и уберем 30% багов в модуле Б», - ты не просишь прощения. Ты показываешь, что понимаешь, как продукт растет.

Еще лучше - используй «Правило мальчика-скаута»: каждый раз, когда ты трогаешь код - улучшай его немного. Не жди, пока он совсем сломается. Это не требует отдельного спринта. Просто делай чище, чем было. И ты не только улучшаешь код - ты учишь команду, что качество - это норма, а не бонус.

Говори на языке данных, а не на языке эмоций

Ты не можешь сказать: «Мне кажется, это важнее». Продакт не слушает «мне кажется». Он слушает: «За последние три спринта мы потеряли 12% скорости из-за багов в платежной системе». Или: «Пользователи, которые используют эту фичу, возвращаются на 40% чаще».

Собери метрики. Не гадай. Посмотри: сколько багов приходится на каждую фичу? Как быстро команда двигается? Какие фичи реально используются? Если ты можешь показать цифры - ты не просишь. Ты решаешь.

Пример: продакт говорит - «Давайте сделаем фичу Х, она повысит конверсию». Ты смотришь в аналитику и говоришь: «Фича Х - это 1% всех пользователей. А фича Y, которую мы отложили, используется 17% и у них 2,3x больше вовлеченности». Это не спор. Это решение на основе данных. И продакт это поймет.

Покажи, а не расскажи

Когда ты говоришь: «Мы должны сделать это», - люди слышат: «Я хочу». Когда ты показываешь прототип, скриншот, или даже просто набросок на бумажке - они слышат: «Вот что мы делаем для пользователя».

Не жди презентации. Не жди встречи. Покажи в Slack. Поставь на доску. Сделай короткий лайф-демо. Даже если это просто скрин с текстом: «Пользователь ждет 8 секунд. Мы можем сократить до 2. Это повысит удержание на 15%».

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

Вовлекай команду до того, как идти к продакту

Ты не один. У тебя есть разработчики, дизайнеры, тестировщики. Они не просто исполнители. Они - твой союзник. Если ты приходишь к продакту и говоришь: «Мы не можем», - это звучит как жалоба. Если ты говоришь: «Мы с командой обсудили, и вот что мы предложили», - это звучит как решение.

Найди в команде тех, кто думает стратегически. Кто не просто пишет код, а спрашивает: «А зачем?». Пригласи их на короткий чат. Скажи: «У меня есть идея. Что ты думаешь?». Они не просто поддержат тебя. Они станут твоими адвокатами. Когда ты пойдешь к продакту, один из них может сказать: «Я тоже за это. Мы уже начали тестировать».

Ты не управляешь командой. Ты ее объединяешь. И когда команда говорит единогласно - продакт слушает.

Уважай время. И свое, и чужое

Никогда не перебивай разработчика, чтобы спросить: «А как там с фичей?». Это как ворваться в кабинет, где кто-то пишет диплом. Ты не просто отвлекаешь - ты ломаешь поток. И поток - это самое ценное, что у разработчика есть.

Вместо этого: поставь встречу. Скажи: «У меня есть 15 минут завтра в 11. Можно обсудить приоритеты?». Или используй асинхронно: напиши в Slack, задай вопрос, дай время на ответ. Разработчики не против работать. Они против хаоса.

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

Ты не просишь внимания. Ты уважаешь его.

Ты - голос клиента

Продакт не знает, что чувствуют пользователи. Разработчики тоже. Ты - единственный, кто общается с ними. Кто читает отзывы. Кто смотрит, где люди застревают. Кто слышит: «Это не работает, как я думал».

Не говори: «Нам нужно сделать фичу». Говори: «Пользователь, который купил у нас подписку, сказал, что не может найти настройку. Он ушел. И 3 человека из 10, с кем я говорил, сказали то же самое».

Это не просто информация. Это история. И истории двигают продукты. Когда ты говоришь не о задачах, а о людях - ты не джуниор. Ты продакт. И продакт, который знает, кто его клиенты, всегда имеет вес.

Приоритеты - это не выбор между «да» и «нет»

Ты не должен выбирать: фича или технический долг. Ты должен выбирать: что принесет больше пользы сейчас. И иногда это - не новая кнопка, а улучшение скорости. Иногда это - не 10 новых фич, а одна, которая работает без багов.

Приоритеты - это не список. Это баланс. И ты - тот, кто его держит. Не потому что ты главный. А потому что ты понимаешь, что важно.

Ты не должен быть старшим, чтобы быть авторитетным. Ты должен быть точным. Ты должен быть последовательным. Ты должен быть честным.

И тогда продакт начнет спрашивать тебя: «А ты что думаешь?» - и слушать ответ.