+7 383 380-81-89
20 августа 2026
Менеджер продукта отвечает за то, чтобы компания делала нужную вещь. Не «быстро сделала» и не «красиво сделала», а именно нужную — ту, за которую люди готовы заплатить и к которой вернутся снова.
Звучит просто, но на деле это работа на стыке: с разработчиками, с продажами, с поддержкой, с деньгами и с самими клиентами. У менеджера продукта почти никогда нет права приказывать. Есть только умение договориться и объяснить, почему делаем именно это, а не что-то другое.
Коротко
- 16 навыков разложены по четырём группам: работа с людьми, с данными, с продуктом и с бизнесом.
- Ни один из них не про инструменты. Ни доска задач, ни аналитика, ни искусственный интеллект не решают за менеджера главный вопрос — что делать не будем.
- В маленькой компании важнее всего первая группа — слушать и договариваться, потому что данных пока мало.
- В растущей компании вперёд выходят вторая и третья группа — считать, проверять и резать лишнее, потому что ошибка затрагивает больше людей.
- Приоритеты — это не длинный список важного, а решение, чего компания точно не будет делать.
В этой статье
Работа с людьми
1. Слушать, а не ждать своей очереди говорить
Клиент почти никогда не говорит прямо, что ему нужно. Он говорит, что ему мешает. «Сделайте кнопку побольше» на самом деле значит «я не понимаю, что делать на этом экране».
Навык в том, чтобы за просьбой увидеть настоящую задачу. Простой приём: на любое пожелание задать вопрос «а что вы пытались сделать?» — и не перебивать ответ.
2. Объяснять решение так, чтобы с ним согласились
Хорошее решение, которое никто не понял, не будет сделано. Менеджер продукта постоянно объясняет одно и то же разным людям: разработчику — зачем, продавцу — что говорить клиенту, руководителю — сколько это стоит.
Каждому нужен свой язык и свои аргументы. Одна и та же презентация для всех подряд не работает.
3. Говорить «нет» и не портить отношения
Просьб всегда больше, чем свободных рук. Отказывать приходится каждый день, и чаще всего — людям, с которыми предстоит работать дальше.
Работает не «нет, некогда», а «нет, потому что сейчас мы делаем вот это, и вот почему оно сейчас важнее». Отказ с объяснённой причиной не воспринимается как пренебрежение.
4. Разбирать конфликты между отделами
Продажи хотят функцию под конкретного клиента. Разработка говорит, что это сломает архитектуру. Поддержка просит сначала починить старое, а не делать новое. Все правы со своей стороны.
Задача менеджера продукта — не выбрать сторону, а вытащить наружу настоящий предмет спора. Обычно он не в том, о чём спорят вслух.
Практика. Если конфликт повторяется из месяца в месяц с теми же словами — скорее всего, дело не в конкретной задаче, а в том, что у отделов разные критерии успеха, и это стоит проговорить один раз прямо, а не тушить каждый спор по отдельности.
Работа с данными
5. Задавать вопрос, на который данные могут ответить
«Как у нас дела с продуктом» — плохой вопрос, на него нет и не может быть точного ответа. «Сколько людей из тех, кто зарегистрировался в январе, пользуются продуктом в марте» — хороший, потому что на него можно посчитать точное число.
Большая часть бесполезной аналитики в компаниях появляется именно потому, что вопрос был сформулирован плохо ещё до того, как открыли таблицы.
6. Отличать совпадение от причины
Показатель вырос после релиза — не значит, что вырос именно из-за релиза. Может быть, начался сезон, пришла реклама, или у конкурента что-то сломалось в это же время.
Проверка простая: а что ещё изменилось в это же время? Если ответа нет — значит, никто и не искал по-настоящему.
7. Ставить эксперименты и не обманывать себя
Сравнение двух вариантов работает только тогда, когда заранее решено, что считается успехом и сколько времени ждём результат. Иначе всегда найдётся показатель, который случайно вырос, и именно на нём остановятся.
Правило одно: критерий успеха и срок эксперимента записываются до его запуска, а не подбираются постфактум.
8. Слышать то, чего в цифрах нет
Метрики показывают, что произошло. Они почти никогда не объясняют, почему. На вопрос «почему» отвечают только разговоры с живыми людьми.
Сильный менеджер продукта смотрит и туда, и туда. Один разговор с недовольным клиентом объясняет странность в цифрах быстрее, чем неделя копания в отчётах. Кстати, предсказание чисел по накопленным данным и разговор с клиентом — это две принципиально разные опоры для решения, и разница между ними разобрана в статье про предиктивный и генеративный ИИ.
| Плохой вопрос | Хороший вопрос |
|---|---|
| Как дела с продуктом? | Сколько зарегистрировавшихся в январе пользуются продуктом в марте? |
| Почему выросли продажи? | Что ещё изменилось в этот же период, кроме релиза? |
| Хороший ли это результат теста? | Совпал ли результат с критерием, который записали до запуска теста? |
Работа с продуктом
9. Расставлять приоритеты и держать их
Приоритеты — это не список, отсортированный по важности. Это решение о том, чего компания точно не будет делать в ближайшее время. Список, в котором всё важно, приоритетами не является вовсе.
Проверка простая: если в план всё время добавляются задачи, а из плана ничего не выпадает, значит настоящих приоритетов нет.
10. Резать объём, а не сроки
Когда команда не успевает, есть два пути: сдвинуть срок или сделать меньше. Первый путь почти всегда хуже, потому что он повторяется раз за разом.
Навык в том, чтобы найти в задаче то ядро, которое даёт пользу без всего остального. Обычно оно есть, просто его никто не искал заранее.
11. Формулировать задачу так, чтобы её поняли одинаково
«Сделать удобный поиск» — это не задача, а пожелание. «Человек находит нужный товар не более чем за три действия, даже если написал название с ошибкой» — уже задача.
Хорошая формулировка описывает результат для пользователя, а не работу, которую предстоит сделать разработчику.
12. Разбираться в том, как всё устроено внутри
Менеджеру продукта не нужно самому писать код. Нужно понимать, почему одна доработка занимает день, а похожая на вид — месяц.
Без этого понимания разговор с разработкой превращается в торг вслепую, а оценки сроков берутся буквально с потолка.
Список без приоритетов
- Всё важно и всё нужно вчера
- В план добавляют, но не убирают
- Сроки двигают вместо объёма задачи
Настоящие приоритеты
- Прямо названо, что не будем делать сейчас
- Новая задача — повод пересмотреть план, а не просто добавить
- Объём режется до нужного ядра, срок держится
Работа с бизнесом
13. Считать, сколько это стоит и что принесёт
Любая доработка стоит времени команды. Если нельзя объяснить, за счёт чего она окупится, — скорее всего, она не так уж и нужна прямо сейчас.
Считать не обязательно строго в рублях. Часы работы, которые перестанут тратиться на рутину, — тоже вполне понятная и честная единица измерения.
14. Понимать, на чём зарабатывает компания
Продукт может нравиться людям и при этом разорять компанию. Или наоборот: нелюбимая всеми функция кормит остальные.
Пока непонятно, откуда реально берутся деньги, любые «улучшения» — это угадывание с закрытыми глазами.
15. Смотреть на конкурентов без слепого копирования
Изучать чужие продукты полезно. Повторять за ними буквально — почти всегда вредно: вы не знаете, работает ли у них эта функция на самом деле и зачем её сделали именно так.
Правильный вопрос не «что у них есть, чего нет у нас», а «какую задачу их клиента это решает, и есть ли такая же задача у наших клиентов».
16. Признавать, что ошибся, и сворачивать вовремя
Часть решений окажется неверной — это совершенно нормально. Ненормально — тянуть их дальше только потому, что уже вложились и жалко.
Потраченное время не вернуть, а вот следующий месяц ещё можно потратить с толком. Умение закрыть свою же инициативу ценится выше, чем умение её защищать до последнего.
Осторожно. Особенно опасно тянуть провальное решение именно из-за громких вложений — чем больше уже потрачено, тем сильнее хочется довести до конца «раз столько вложили». Это известная ловушка мышления, и от неё не защищает ни опыт, ни должность.
Что из этого важнее
Все шестнадцать сразу не нужны одновременно. На разных этапах жизни продукта вытягивают разные навыки из четырёх групп.
В маленькой компании, где продукт ещё ищет своих клиентов, больше всего весят навыки из первой группы — слушать и договариваться. Данных пока мало, и решения принимаются в основном по разговорам с людьми, а не по отчётам.
В компании, где продукт уже работает и растёт, вперёд выходят вторая и третья группа: считать, проверять гипотезы и резать лишнее. Ошибка здесь стоит заметно дороже, потому что затрагивает уже много людей сразу, а не горстку первых клиентов.
| Этап продукта | Какая группа навыков важнее |
|---|---|
| Только ищет своих клиентов, данных мало | Работа с людьми — слушать и договариваться |
| Уже работает и растёт | Работа с данными и с продуктом — считать и резать лишнее |
| Любой этап | Работа с бизнесом — понимать, на чём зарабатывает компания |
Это в равной мере касается и продуктов на искусственном интеллекте внутри компании: прежде чем строить помощника, придётся так же честно ответить, какую задачу клиента он решает и как понять, что решение сработало. Разбирали, что такое такой помощник и как он устроен, в статье про ИИ-агента простыми словами.
Общее у всех шестнадцати навыков одно: ни один из них не про инструменты. Ни доска задач, ни система аналитики, ни искусственный интеллект не сделают за менеджера продукта главную работу — решить, что делать не будем.
Частые вопросы
Нужно ли менеджеру продукта уметь программировать?
Нет, писать код не нужно. Но полезно понимать, почему одна доработка занимает день, а похожая на вид — месяц: без этого разговор с разработкой превращается в торг вслепую, а оценки сроков берутся с потолка.
Какой из 16 навыков самый важный?
Единого ответа нет — это зависит от этапа продукта. В маленькой компании важнее слушать клиентов и договариваться с командой, в растущей — считать, проверять гипотезы и вовремя резать лишнее.
Чем приоритеты отличаются от простого списка задач по важности?
Список, где всё названо важным, приоритетами не является. Настоящие приоритеты — это прямое решение о том, чего компания точно не будет делать в ближайшее время, а не просто порядок в списке.
Как понять, что результат сравнения двух вариантов реальный, а не случайность?
Критерий успеха и срок ожидания результата нужно записать до запуска сравнения, а не подбирать задним числом под тот показатель, который случайно выглядит лучше. Без этого правила легко обмануть самого себя.
Можно ли просто скопировать успешную функцию у конкурента?
Технически да, но это рискованно: неизвестно, работает ли эта функция у конкурента на самом деле и зачем она была сделана именно так. Правильнее понять, какую задачу клиента она решает, и проверить, есть ли такая задача у ваших собственных клиентов.
Назад к блогу
