16 навыков управления продуктами, которые вам понадобятся

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

Звучит просто, но на деле это работа на стыке: с разработчиками, с продажами, с поддержкой, с деньгами и с самими клиентами. У менеджера продукта почти никогда нет права приказывать. Есть только умение договориться и объяснить, почему делаем именно это, а не что-то другое.

Работа с людьми

1. Слушать, а не ждать своей очереди говорить

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

Навык в том, чтобы за просьбой увидеть настоящую задачу. Простой приём: на любое пожелание задать вопрос «а что вы пытались сделать?» — и не перебивать ответ.

2. Объяснять решение так, чтобы с ним согласились

Хорошее решение, которое никто не понял, не будет сделано. Менеджер продукта постоянно объясняет одно и то же разным людям: разработчику — зачем, продавцу — что говорить клиенту, руководителю — сколько это стоит.

Каждому нужен свой язык и свои аргументы. Одна и та же презентация для всех подряд не работает.

3. Говорить «нет» и не портить отношения

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

Работает не «нет, некогда», а «нет, потому что сейчас мы делаем вот это, и вот почему оно сейчас важнее». Отказ с объяснённой причиной не воспринимается как пренебрежение.

4. Разбирать конфликты между отделами

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

Задача менеджера продукта — не выбрать сторону, а вытащить наружу настоящий предмет спора. Обычно он не в том, о чём спорят вслух.

Работа с данными

5. Задавать вопрос, на который данные могут ответить

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

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

6. Отличать совпадение от причины

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

Проверка простая: а что ещё изменилось в это же время? Если ответа нет — значит, никто и не искал по-настоящему.

7. Ставить эксперименты и не обманывать себя

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

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

8. Слышать то, чего в цифрах нет

Метрики показывают, что произошло. Они почти никогда не объясняют, почему. На вопрос «почему» отвечают только разговоры с живыми людьми.

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

Работа с продуктом

9. Расставлять приоритеты и держать их

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

Проверка простая: если в план всё время добавляются задачи, а из плана ничего не выпадает, значит настоящих приоритетов нет.

10. Резать объём, а не сроки

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

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

11. Формулировать задачу так, чтобы её поняли одинаково

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

Хорошая формулировка описывает результат для пользователя, а не работу, которую предстоит сделать разработчику.

12. Разбираться в том, как всё устроено внутри

Менеджеру продукта не нужно самому писать код. Нужно понимать, почему одна доработка занимает день, а похожая на вид — месяц.

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

Работа с бизнесом

13. Считать, сколько это стоит и что принесёт

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

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

14. Понимать, на чём зарабатывает компания

Продукт может нравиться людям и при этом разорять компанию. Или наоборот: нелюбимая всеми функция кормит остальные.

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

15. Смотреть на конкурентов без слепого копирования

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

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

16. Признавать, что ошибся, и сворачивать вовремя

Часть решений окажется неверной — это совершенно нормально. Ненормально — тянуть их дальше только потому, что уже вложились и жалко.

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

Что из этого важнее

Все шестнадцать сразу не нужны одновременно. На разных этапах жизни продукта вытягивают разные навыки из четырёх групп.

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

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

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

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

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