Предыдущие статьи:

• Глава 1: Кто такой продуктовый менеджер?

• Глава 2: Как попасть в профессию

• Глава 3: Мышление и философия продакта

• Глава 4: Пользователь как центр внимания

Лидерство

Как влиять без прямого подчинения?

1. Управление через влияние

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

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

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

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

2. Построение доверия

Доверие — это валюта. Она очень сложно зарабатывается делом и невероятно быстро тратится.

Будь надёжен: выполняй обещания, держи слово, признавай ошибки.

Защищай команду: бери на себя ответственность, «разруливай» блокеры и конфликты, не перекладывай вину.

Проявляй эмпатию: слушай, интересуйся задачами и болями коллег.

3. Развитие soft skills

Самые важные навыки для продакта:

• Коммуникация: умение доносить мысль ясно, кратко, по делу. Важно уметь говорить с разными ролями на их языке.

• Активное слушание: не просто «слышать», а понимать мотивы, потребности, опасения.

• Эмоциональный интеллект: считывать настроение, реагировать адекватно, управлять своими эмоциями в стрессовых ситуациях.

Как развивать лидерство?

Ключевые навыки

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

• Стратегическое мышление — видеть продукт в контексте бизнеса. Навык не только видеть цель, но и умение формировать её и влиять на неё.

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

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

• Инициативность — поднимать сложные темы, предлагать решения, быть “впереди”. Умей решать сложные вопросы. Не бросай коллег один на один с проблемами. В идеале — часть проблем решать задолго до того, как задача пойдёт в работу.

Полезные привычки

• Вести рефлексию после каждого спринта/запуска: что сработало, что — нет. Ошибки — это нормально. Их не нужно прятать, потому что иначе они повторятся вновь.

• Читать и пересказывать сложные идеи в простом виде. Сложные конструкции сложно понять. Хочешь, чтобы твои идеи лучше доходили до других? Научись рассказывать их в 1–2 предложения.

• Искать фидбек: от команды, от пользователей, от менторов. Ты необъективен, и сам себя или свою команду оценить не сможешь. А взгляд со стороны может помочь увидеть зоны роста.

• Помогать другим — учить, менторить, делиться знаниями. Не чахни над златом. Знаешь — поделись.

Для любителей читать

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

1. «Пять пороков команды» — Патрик Ленсиони. Роман о построении процессов будучи руководителем. В художественной форме рассказывается о важных принципах управления;

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

3. «Бирюзовое управление на практике» — Валера Разгуляев. Что делает компании «бирюзовыми»? Рекомендую послушать в аудиоформате — читать довольно тяжело;

4. «Радикальная прямота» — Ким Скотт. О подходе «кнут и пряник» в управлении. Перевод кривой, поэтому лучше прочесть в оригинале. Но там много терминов. Основная идея будет понятна и в переводе;

5. «Лидеры едят последними» — Симон Синек. В несколько топорной форме рассказываются интересные вещи. Не все рекомендации, на мой взгляд, хорошие, но прочесть стоит;

6. «45 татуировок менеджера» — Максим Батырев. Вообще, это книга про управление в продажах, и там много соответствующего контекста. Часть «татуировок» повторяется или противоречит друг другу, но общий посыл книги верен. Несмотря на то, что я считаю эту книгу плохой, я всё равно советую вам её прочесть, чтобы вы понимали, как надо и как не надо. Будьте с книгой осторожны — там есть в том числе и вредные советы.

Применение на практике

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

Модерируй встречи и воркшопы — учись направлять дискуссию, а не управлять ею.

Заводи менторские отношения — как ученик и как ментор. Учись и учи. Так ты не будешь стоять на месте и будешь постоянно находить и закрывать белые пятна в своих знаниях.

Что такое микроменеджмент и как его избежать?

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

Как выглядит микроменеджмент

• Постоянные проверки, отчёты, «где это?»;

• Комментарии на каждую мелочь в дизайне, копирайтинге, коде;

• Желание всё делать самому, «потому что быстрее».

Почему это вредно

• Убивает инициативу: команда ждёт инструкций, а не предлагает решения;

• Замедляет работу: каждый шаг требует подтверждения;

• Вызывает выгорание у PM и недоверие у команды.

Как не скатиться в микроменеджмент

Доверяй профессионализму команды. Дизайнер знает, как построить UX. Разработчик — как реализовать. Твоя задача — задать цели, а не указывать путь.

Фокус на outcome, а не output. Обсуждай цели, метрики, пользовательскую ценность — а не количество тасок.

Делегируй и отпускай. Да, не всё будет идеально. Но если не давать людям пробовать и ошибаться — рост невозможен.

Уточняй зоны ответственности. Кто за что отвечает. Кто принимает финальные решения. Это создаёт ясность и снижает «вмешательство».

Из личного опыта

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

Командная динамика и роли

Как выстраивать рабочий процесс?

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

1. Один бэклог — одна команда

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

2. Регулярные синки и демо — не для галочки

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

3. Пиши и визуализируй

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

4. Создавай культуру ответственности, а не контроля

Люди не обязаны выполнять твои задачи — они обязаны достигать целей продукта. Делегируй ответственность, а не задачи. Это отличает зрелую команду от команды фрилансеров на зарплате. Хочешь, чтобы вокруг тебя были профессионалы? Относись к окружающим как к профессионалам.

Как распределяются роли и зоны ответственности в продуктовой команде?

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

PM (продакт-менеджер)

• Отвечает за: ценность, приоритеты, пользовательские и бизнес-результаты.

• Не делает: UI-дизайн, код, сложные SQL-запросы (если только ты не в стартапе из трёх человек) и дашборды.

Совет: будь тем, кто принимает решения, а не единственным источником правды (пиши документацию).

Дизайнер

• Отвечает за: пользовательский опыт, визуальные решения, исследование поведения.

• Зона риска: дизайнер без данных — это художник. Всегда дай доступ к метрикам. Если дизайнер не знает и не интересуется показателями продукта, стоит задуматься.

Совет: вовлекай дизайнера в обсуждение фичей с самого начала. Не кидай ему таск после синка. Приходи с идеями, а не решениями.

Разработчики

Отвечают за: техническую реализацию, архитектуру, качество кода.

Совет: обсуждай с ними не «что сделать», а «зачем мы это делаем». Тогда решения будут лучше.

Аналитик (если есть)

Отвечает за: метрики, валидацию гипотез, сегментацию, причинно-следственные связи.

Совет: подключай его на этапе формулировки проблемы, а не постфактум. Аналитик — не просто исполнитель твоих желаний, он соратник.

Тестировщик (QA)

Отвечает за: качество, стабильность, автоматизацию тестирования.

Совет: QA — самый важный член команды. Именно от качества его работы зависит то, как пользователи будут воспринимать продукт.

Чем вреден водопадный подход в гибких командах?

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

Слишком часто я видел, как даже «гибкие» команды на деле работают по водопаду: сначала дизайнер рисует без обсуждения с разработкой, потом разраб делает, потом тестировщик без контекста тестит, а в конце — продакт всё презентует. В таком подходе нет итеративности.

Почему водопад не работает:

• Поздняя обратная связь. Если гипотеза не сработала, мы узнаем это через месяц;

• Теряется контекст. Чем больше этапов между идеей и реализацией, тем хуже результат;

• Изолирование ролей. Люди перестают понимать бизнес-контекст и общие цели.

Как быть:

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

«Бутылочное горлышко» и «фактор автобуса»: что это и как их избегать?

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

Бутылочное горлышко (bottleneck)

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

Примеры:

• Только один аналитик умеет выгружать метрики.

• Только один разработчик понимает, как работает платёжная система.

• В команде 8 разработчиков и 1 тестировщик.

Как решать:

• Внедряй практику менторства и шеринга знаний.

• Делай парное программирование и совместную аналитику.

• Документируй процессы и знания — Confluence и Notion в помощь.

• С ростом команды следи за балансом ресурсов.

Фактор автобуса (bus factor)

Сколько человек должно уехать в отпуск или «быть сбитыми автобусом», чтобы проект встал? Если ответ — один, у тебя проблемы. Если ответ — “я”, у тебя огромные проблемы.

Как решать:

• Дублируй ключевые компетенции. Не замыкай ключевые процессы на одном человеке.

• Поощряй ротацию внутри команды. Не допускай появления специализации в команде, особенно среди разработчиков.

• Делай «шадоуинг»: когда кто-то временно выполняет работу коллеги под его контролем, чтобы понять суть.

Создание доверия

Почему доверие — основа хорошей команды?

Доверие — это не про хорошее отношение между людьми. Это конкретная основа, на которой строится способность команды быстро принимать решения, брать ответственность и не бояться ошибок. Без неё любая попытка масштабировать продукт, улучшить time-to-market (время доведения задачи до релиза) или внедрить культуру экспериментов становится похожей на попытку строить небоскрёб на зыбучих песках.

Доверие снижает издержки

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

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

Доверие позволяет открыто обсуждать проблемы и конфликты

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

Доверие даёт командный иммунитет

Сильные команды не разваливаются от первой неудачи или внешнего давления. Они могут пережить провал спринта, токсичного клиента, смену фокуса. Потому что знают: мы — не просто набор специалистов, а мы — команда. Хоть эта фраза и абсолютно клишированная, но как ещё донести мысль, что мы тут не просто задачки собрались позакрывать, я не знаю.

Как строить доверие?

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

Будь предсказуемым

Доверие начинается с ощущения стабильности. Если ты сегодня поддерживаешь одно решение, а завтра полностью меняешь курс без объяснений — команда перестаёт тебе верить. Предсказуемость не означает «никогда не менять мнение», но означает, что у твоих решений должна быть логика, которую ты доносишь. Ключевое — доносишь.

• Проговаривай причины своих решений и изменений.

• Публично признавай ошибки — это не слабость, а сила.

• Выполняй обещания.

Рассказывай о целях и контексте

Когда ты вовлекаешь команду в цели продукта и даёшь широкий контекст, ты не просто информируешь — ты приглашаешь к соучастию. Люди начинают понимать, зачем они делают задачу, как она влияет на пользователя и какое решение будет «правильным».

• Рассказывай команде о квартальных и годовых планах.

• Начинай описание задач не с «надо сделать», а с проблем, которые мы решаем и почему мы их решаем.

• Рассказывай команде о метриках продукта и о том, как они меняются со временем.

Демонстрируй эмпатию и уважение к разным ролям

Кросс-функциональная команда состоит из дизайнера, разработчиков, аналитика, тестировщика и т. д. У каждого свои боли, приоритеты, язык. Умение понимать и признавать это создаёт ощущение того, что «нас слышат».

• Задавай открытые вопросы: «Как ты видишь эту фичу с точки зрения UX?», «Что тебя смущает в этом решении как разработчика?», «Думаю о таком решении. Как оно тебе?».

• Благодари не только за результат, но и за усилия, особенно если они не всегда заметны. «Спасибо» — это бесплатно.

• Слушай. По-настоящему.

Создавай ритуалы открытости и взаимодействия

Командная ретроспектива, демо, встречи 1:1 — это не просто календарные события, а точки роста доверия. Главное — не превращать их в формальность.

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

• Делай демо не ради «отчётности», а как площадку для гордости и обратной связи. На демо стоит подсвечивать только плюсы и сообщать об успехах конкретных людей.

• Вводи практику «вопрос недели» в Slack — пусть команда делится не только о работе, но и о себе. Разговоры только по работе никак не улучшают атмосферу в коллективе.

Защищай команду, но не скрывай от реальности

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

• Аргументируй приоритизацию с опорой на данные, а не «потому что сказал инвестор». Помни про важность контекста.

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

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

Прозрачность и синхронизация

Что такое синхронные и асинхронные процессы?

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

Асинхронные процессы — это работа, где каждый взаимодействует в своём темпе. Это задачи в таск-трекере, документация, записи встреч, апдейты в Slack, комментарии в Figma и Notion. Они не требуют немедленного ответа.

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

Какие регулярные ритуалы приносят пользу?

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

Ежедневные митинги (стендапы)

Не для отчёта, а для фокуса и взаимопомощи. Про них подробнее — ниже.

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

Груминг

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

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

Планинг (раз в неделю / раз в спринт)

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

Ретроспектива (раз в 2 недели / месяц)

Пространство, где можно говорить честно. Что пошло хорошо? Что тормозило? Что пробуем улучшить? Главное — внедрять реальные изменения по итогам, а не ограничиваться только разговорами. У команды обязана быть встреча, где они могут высказаться. Хвалите, ругайте и ищите решения совместно.

Демо (раз в спринт / по готовности)

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

Async апдейты по ключевым метрикам / инициативам

Например, раз в неделю продакт пишет в Slack/Mattermost или Confluence/Notion: что сделано, какие инсайты обнаружены, на чём фокус. Это помогает держать контекст и устраняет «непрозрачность» работы продакта.

Как организовать эффективные стендапы?

Эта активность имеет несколько имён: стендап, митинг, дейлик. Вне зависимости от названия, это всё одно и то же.

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

Как сделать дейлик идеальным:

• Ограничь по времени. 15 минут — потолок. Время истекло, а ещё не всё обсудили? Увы, надо расходиться. Такая строгость приучит соблюдать тайминг.

• Фокус на ценности, а не на активности. Движемся от задач, а не от людей. Вот есть задача А. Что по ней сделано? Когда будет результат? Какие есть сложности? И так по каждой задаче из списка запланированных. Кроме уже готовых, естественно.

• Нет статусам ради статуса. Учитесь говорить «по этой задаче пока ничего». Но нужно разобраться, почему задача застряла и когда она статус изменит

• Формат — по ситуации. В офисе — у доски. Удалёнка — в Zoom или async в Slack (текст, видео, аудио). Но лучше всего работает голосовой формат дейлика. Созвонитесь и быстренько обсудите задачи.

• Подключай дизайн, аналитику, тестировщиков. Стендап — не только для разработчиков. Это ваша общая миссия. Каждый причастный должен быть в курсе, что происходит в команде и с какими трудностями мы сталкиваемся. Но тут нужно быть аккуратным. Если, условно, аналитику точно будет не полезно на дейлике, то звать его не нужно. Только полезные встречи.

• Смело говорите о блокерах. Если кто-то говорит «всё нормально», но буксует третий день с одной и той же задачей — это сигнал, что доверия и безопасности не хватает. Говорить о проблемах важно и нужно. Иногда достаточно людям напомнить, что они могут высказаться, чтобы они начали это делать.

Как давать и принимать обратную связь?

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

Как давать обратную связь:

Обсуждай факты, а не людей

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

Регулярно

Не жди ретро, чтобы высказаться. Чем быстрее даёшь фидбек после события — тем выше шанс, что он будет услышан и принят.

Пытайся помочь

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

«Плюс — дельта» вместо «сэндвича»

Старый трюк «похвала — критика — похвала» часто звучит фальшиво. Многие об этом подходе знают и замечают его применение. Лучше: "что получилось хорошо" и "что можно улучшить и как". То есть — похвали, обозначь проблему и предложи решение.

Формат — под человека

Будь гибким в общении. Не нужно решать за людей, как им удобнее вести диалог. Кому-то комфортно в личке, кому-то — голосом один на один. Спроси, как им удобнее. Вроде и мелочь, а это сильно добавляет к комфорту в общении.

Как принимать обратную связь:

Не обороняйся

Даже если что-то звучит резко — попробуй услышать суть. Фраза «спасибо, подумаю об этом» — отличный старт к рефлексии. Только реально подумай.

Уточняй

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

Отделяй мнение от факта

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

Проси сам. Регулярно

Один из сильнейших вопросов, который ты можешь задать: «Что мне стоит начать, прекратить или продолжить делать, чтобы тебе было проще со мной работать?»

Люди охотнее дают обратную связь анонимно. Создай форму с тремя вопросами: какие положительные стороны, что можно улучшить, комментарий в свободной форме. Закинь форму команде и запроси фидбек. Ты можешь быть удивлён. И не всегда приятно.

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

Делай выводы видимыми

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

Конфликты и решения

Как реагировать на напряжение и превращать его в продуктивный результат?

В конфликтах в команде, а они будут происходить как ни крути, не ищи виноватого. Кто виноват — не важно. Важно, как не допустить повторения ситуации, которая привела к конфликту. Направь все силы именно на поиск ответа: «как нам тут больше не оказаться».

1. Прими напряжение как сигнал, а не угрозу

Первый шаг — не пугаться напряжения. Чаще всего за ним скрываются не "плохие люди", а несовпавшие ожидания, непроговорённые роли или реальные риски, которые кому-то видны раньше остальных.

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

2. Замени обвинение на любопытство

Вместо "Почему ты не сделал задачу в срок?" используй: "Что повлияло на тайминг? Есть ли системная причина?". Вместо "Ты не слушаешь команду" лучше сказать: "Как ты воспринимаешь обратную связь от команды? Что тебе помогает/мешает её учитывать?"

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

3. Превращай конфликты в точки роста

Любой серьёзный конфликт — повод сделать ретроспективу, переосмыслить процессы и укрепить культуру. Конфликты подсвечивают точки роста для команды и тебя самого.

Конфликт — это не сбой, это возможность обновить систему координат. Но только если ты осознанно его отрефлексируешь. Старайся сделать из любого конфликта выводы.

Как говорить «нет» конструктивно?

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

1. «Нет» через причину, а не авторитет

Просто сказать: «Мы этого делать не будем» — это путь к вражде. А вот сказать: «Сейчас у нас цель — улучшить retention. Эта идея может мешать фокусу. Давай поставим её в backlog и вернёмся после релиза» — путь к сотрудничеству.

Люди готовы принять «нет», если ты объясняешь его через интересы продукта, а не через свою власть. Просто «нет» звучит грубо, а вот «нет» с аргументацией — уже нет. Тебе ничего не стоит объяснить свою мотивацию и дать контекст тому человеку, которому ты вынужден отказать.

2. Замени «нет» на «да, если»

Иногда конструктивное «нет» — это «да», но с условием.

Людям важно быть услышанными. Даже если ты говоришь «нет», оставь мостик для обсуждения в будущем.

3. Убери личное из отказа

Твоя задача — сделать так, чтобы «нет» не звучало для собеседника как «ты плохой». Ведь отказываешь ты не человеку, а тому решению, что он принёс.

Не «Ты опять предлагаешь что-то невпопад», а «На данном этапе фокус — другой. Давай сверим приоритеты».

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

Итог пятой главы

• «Продавай» идеи команде — объясняй, зачем фича важна, а не просто что и когда делать. Объясняй проблемы и рассказывай о целях.

• Вовлекай команду в решения — это повышает ответственность и мотивацию.

• Доверие — основа работы — держи слово, признавай ошибки, защищай команду.

• Строй процессы, а не туши пожары — системность важнее хаотичной многозадачности.

• Проявляй инициативу — поднимай сложные темы до того, как они станут проблемами.

• Микроменеджмент вреден — он убивает инициативу и снижает доверие.

• Фокус на результат, а не на таски — оценивайте ценность, а не активность.

• Создавай культуру ответственности — делегируй цели, а не задачи.

• Документируй и визуализируй — письменный контекст снижает недопонимание.

• Избегай "бутылочных горлышек" — распространяй знания и дублируй критичные роли.

• Доверие снижает издержки — меньше контроля — больше скорости.

• Поясняй решения и изменения — предсказуемость рождает доверие.

• Встречи не для галочки — синки, ретро, демо — это точки роста, а не формальности.

• Умей говорить «нет» правильно — аргументируй через цели продукта, а не авторитет.

---

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

---