Роль PM в команде
PM — сокращение от Product Manager (в контексте обсуждения).
Какую ценность приносит продуктовый менеджер?
Задача менеджера продукта — искать баланс между интересами бизнеса, потребностями пользователей и техническими возможностями, а также связывать различные решения участников команды в одну картину. Часто весь этот процесс заворачивают в ёмкий и одновременно абстрактный термин — «видение продукта» (или «продуктовое видение»). То есть ценность продакт-менеджера — в синхронизации и понимании, а не в контроле и управлении. Менеджер продукта — не руководитель, и это стоит уяснить. Нет, иметь навыки управления и построения процессов тоже нужно, но они не являются определяющими.
Менеджер продукта, как бы пафосно это ни прозвучало, — источник истины для всех остальных специалистов: разработчиков и тестировщиков, аналитиков, дизайнеров, а также юристов и SMM-щиков. Ходячая энциклопедия по мотивации пользователей, бизнес-логике и бизнес-целям.
Но это не значит, что без продакта нельзя обойтись. Очень даже можно! Если работу над продуктом представить как лодку, то продакт на ней будет далеко не рулевым, а скорее штурманом. Наличие штурмана никак не влияет на характеристики лодки и её способность плыть, но сильно влияет на то, куда лодка поплывёт. Вот именно за знание «куда» менеджер продукта и отвечает — и именно за это ценен.
Чем product-менеджер отличается от project-менеджера, тимлида или бизнес-аналитика?
Без аналогий про лодки правильнее будет сказать, что продакт-менеджер отвечает на вопрос «что»: что продукт из себя представляет, что нужно реализовать, что закладывается в функциональность. Проджект-менеджер, в свою очередь, отвечает на вариации вопроса «как»: как мы будем реализовывать продукт, какими инструментами, кто будет делать продукт и в какие сроки. Бизнес-аналитик, скорее, отвечает на вопросы «зачем» и «почему».
Но, забегая вперёд, скажу: product manager должен уметь отвечать на все эти вопросы. Специфика работы в России такова, что максимум, кто у вас будет в команде, — это тимлид, и роль проджекта придётся взять на себя продакт-менеджеру. К слову, именно тимлид является в команде руководителем для разработчиков. Тимлид отвечает за состав команды разработки и нередко имеет право нанимать и увольнять сотрудников в рамках своей команды. При этом для PM тимлид не является руководителем. Вот такая сложная схема, которая, впрочем, сильно развязывает руки обоим.
В каких ситуациях PM должен взять на себя инициативу, а когда — отойти в сторону?
Продакт придумывает «фичи» (функциональные особенности), и, отбрасывая мотивацию и причины их появления, инициатива по внедрению всегда на стороне менеджера. Именно он в конечном итоге решает, нужна ли функциональность продукту или нет. А нередко и результат фичи в рамках команды нужен только PM’у — грустная реальность. За менеджера продукта никто не придумает, в какую сторону развивать продукт, и в этой плоскости инициатива лежит полностью на нём.
То же касается оценки приоритета (или важности) задач. Приоритеты определяет менеджер продукта, и инициатива также полностью на нём.
При этом не нужно лезть в процесс декомпозиции (разделения) задач. Дизайнеры и разработчики сами разберутся, на какие части разбить задачу и с какой стороны начать реализацию. И как именно реализовать — тоже сами решат. Продакту в это лезть не нужно. Профессионалы своего дела самостоятельно найдут решения. Это не зона ответственности PM, и инициатива от него там не требуется.
Грубо говоря, инициатива продакт-менеджера заканчивается на целеполагании. Если ожидаемый результат задачи описан и объяснён команде, то о задаче стоит забыть до появления этого самого результата. При этом ответственность за результат всё равно остаётся на product-менеджере.
Как PM взаимодействует с дизайнерами, разработчиками и бизнесом?
Как говорилось выше, менеджер продукта не является руководителем для членов команды. Он такой же участник, как и все остальные, без каких-либо дополнительных рычагов и привилегий — отдельный и самостоятельный специалист в своей области. Как тогда взаимодействовать друг с другом? Кто кого слушает, за кем последнее слово и почему?
При работе над продуктом команда придерживается процессов. Процессы — это договорённости участников команды о взаимодействии друг с другом. Своеобразный свод правил и набор соглашений. Существуют даже манифесты для таких правил. Самый популярный — Agile. Команда может использовать какой-то фреймворк для организации процессов, например Scrum, но в деталях у каждой команды будут свои процессы и привычки, даже в рамках одной компании.
PM для команды является заказчиком (или стейкхолдером). Он ставит задачи и принимает результат. Исходя из этого строится взаимодействие. Например, при работе с дизайнерами продакт ставит задачу, в которой описан ожидаемый результат. В задаче не указывается, какие использовать цвета, где должны быть объекты и какого они должны быть размера — это решит дизайнер самостоятельно. Максимум — допустимо перечислить список желаемых элементов, но некоторых специалистов даже это может раздражать. Дизайнер берёт задачу в работу и разрабатывает решение, ориентируясь на ожидаемый результат. Он имеет полное право реализовать на макетах любое решение, соответствующее задаче. Дизайнер — это профессионал, и он лучше понимает, как нужно строить интерфейсы, чем продакт.
После того как макеты готовы, дизайнер и продакт вместе обсуждают решение. Это важный этап, к которому нужно серьёзно отнестись. Необходимо внимательно изучить результат, оценить, насколько хорошо он решает задачу пользователя, и задать дизайнеру уточняющие вопросы. На этом этапе не нужно искать компромиссы между ожиданиями продуктового менеджера и предложением дизайнера. Нужно либо принять решение, либо, если оно не решает проблему пользователя, искать другое. Несмотря на то, что автором решения является дизайнер, ответственность за его принятие (и за выполнение задачи) лежит на PM. Он даёт зелёный свет.
Примерно так же строится работа и с разработчиками. Единственное отличие в том, что соответствие техническим и бизнес-требованиям будет проверять не продакт, а QA (инженер по качеству или тестировщик). Проверка результата работы разработчика — настолько специфичный процесс, что менеджер продукта просто не сможет выполнить его самостоятельно, как минимум из-за нехватки технических компетенций.
С представителями бизнеса процессы строятся наоборот. Теперь уже PM выступает исполнителем, а «бизнес» (топ-менеджеры, CPO, инвесторы и т. д.) — заказчиком. И в компаниях со здоровыми процессами бизнес тоже описывает ожидаемый результат — например, в виде ключевых результатов или KPI по метрикам (показателям), — а product-менеджер самостоятельно ищет решение.
Что будет с командой, если нет хорошего PM?
Что такое «хороший PM» — поговорим позже. А сейчас давай разберёмся, что будет, если в команде совсем нет продакта. Короткий ответ: ничего не будет.
Вспоминаем аналогию с лодкой. Команда сможет продолжать работать: дизайнеры будут делать макеты, разработчики — писать код, тестировщики — проверять задачи. Но на продукте это отразится очень сильно. Если никто не возьмёт на себя ответственность за целостную картину, продукт получится несвязным, сделанным тяп-ляп. Со временем он накопит проблемы, станет неудобным, а значит — бесполезным для пользователей.
А единственная причина, по которой продукт вообще существует — это быть полезным. Только в этом случае он может приносить доход бизнесу.
Типы продуктовых менеджеров
Какие бывают роли и специализации у продуктовых менеджеров?
Продуктовый менеджер — это не одна профессия, а скорее зонтик, под которым скрывается множество специализаций. Вот основные из них:
Технический PM (Technical Product Manager, TPM)
Technical Product Manager отвечает за техническую сторону продукта: API, архитектуру, инфраструктуру, а также взаимодействие с командами разработки. Чаще всего TPM работает с backend-продуктами, платформами или SDK. В последние годы появилось много вакансий на такие позиции — рынок остро нуждается в специалистах с техническим бэкграундом: бывших разработчиках, DevOps-инженерах или QA.
Роль TPM довольно специфична. Она находится где-то между тимлидом и архитектором. И нередко заменяет собой обе эти роли. В командах, где есть Technical Product Manager, часто нет отдельного архитектора — эту функцию берёт на себя TPM. Хотя из этого есть исключения. В крупных компаниях может быть главный архитектор всей инфраструктуры, который утверждает архитектурные решения TPM’ов по их продуктам или частям продукта.
Фокус на рост продукта: увеличение конверсий, удержания, виральности. Growth-продакты тесно работают с аналитикой, A/B-тестированием, воронками. Их цель — быстро проверять гипотезы и масштабировать успешные решения.
Такие продуктовые менеджеры занимаются ростом того, что уже есть в продукте. Они занимаются оптимизацией сценариев и улучшением пользовательского опыта. Growth-менеджеры не запускают новые продукты, не продумывают новые ниши продукта и сценарии пользователя.
Core Product Manager (или Feature PM)
Работает над основной ценностью продукта — ключевыми функциями, которые решают проблемы пользователей. Это самый классический и распространённый тип PM. Он же — самый универсальный. Такой продакт может работать и над API, и над оптимизацией воронок, и заниматься стратегией продукта. И зачастую это приходится делать одновременно.
Из-за постоянной смены фокуса и широкой компетенции Core-продакт-менеджер не так хорош, как продакты более узких специализаций. Но универсальность позволяет сэкономить на ресурсах малому и среднему бизнесу и закрыть максимум задач по продукту одним специалистом. При росте бизнеса и продукта растёт и количество продуктовых менеджеров — там и появляется специализация. Продакты-универсалы в больших компаниях и развитых продуктах нужны всё реже.
Но, тем не менее, универсальность до сих пор остаётся большим плюсом для продакта и позволяет в дальнейшем быстрее перейти почти в любую специализацию продуктового менеджмента.
Стратегический PM (Strategy/Business PM)
Фокусируется на рынке, позиционировании, конкуренции, долгосрочной продуктовой стратегии. Много работает с руководством, маркетингом, финансами. Самая редкая птица среди продактов. В России почти не встречается. Зачастую, когда менеджер продукта дорастает до работы над стратегией, ему в руки дают управление ещё и бюджетами — и называют CPO.
Начать карьеру со Strategy PM невозможно совсем без опыта в сфере. Нужно либо быть очень опытным Senior Product Manager (то есть специалистом высокого уровня), либо быть сеньором в экономике или бизнес-аналитике.
Работает с продуктами на основе данных: аналитические платформы, рекомендательные системы, ML/AI-продукты. Должен разбираться в data science и уметь говорить на языке аналитиков и инженеров данных.
Отличается от технического продакта тем, что здесь не так важны технические навыки, сколько важно умение работать с данными и математикой. Такой тип продуктовых менеджеров управляет аналитиками — и из их числа чаще всего вырастает.
Platform/Infrastructure PM
Фокус на внутренних продуктах для других команд: системы авторизации, биллинг, DevOps-инструменты. Их «клиенты» — внутренние разработчики и технические команды.
Платформенный продакт не работает с деньгами, а пользователи у него крайне специфические — работники этой же компании. Самый простой способ попасть в профессию, так как задачи и ответственность очень близки к Core PM, но при этом сами продукты зачастую проще, и нет работы над экономикой продукта.
Как выбрать направление, если только начинаешь карьеру?
Важно сначала оглянуться «назад» — на свой прошлый опыт. Если до этого работал разработчиком или хотя бы прошёл курсы на разработчика, то можно рассмотреть варианты технического продакта. Если работал аналитиком или дата-инженером, то путь открыт в продакты роста (Growth) или Data PM.
Если опыта совсем нет, то лучше искать вакансии Core PM (их больше всего) в небольшую компанию. Ну или искать вакансию Platform PM. Таких вакансий не так много, но, как я говорил выше, из-за отсутствия работы над экономикой роль упрощается, и можно сконцентрироваться на других навыках продуктового менеджера. Но на позиции платформенного менеджера лучше долго не засиживаться — потом будет очень тяжело перейти в другую лигу.
Может ли один человек совмещать сразу несколько продуктовых ролей?
Да, особенно в стартапах и небольших компаниях. Пример:
В стартапе PM может одновременно быть и growth-специалистом, и заниматься технической платформой, и думать о стратегии.
В корпорации роли чаще разделены, но на пересечениях возможна коллаборация.
Core Product Manager — это как раз про это: несколько разных ролей в одной позиции.
Но нужно помнить, что мы ограничены:
Временем — невозможно глубоко копать во всех направлениях, даже если ты очень осознанный и организованный.
Сфокусированностью — при попытке делать всё сразу страдает качество решений. Ты распыляешься и не углубляешься в детали.
Компетенциями — сложно быть одновременно топом в стратегии, инженерии и маркетинге. Обычно люди развиваются по принципу T-shape: специалист с глубокими знаниями в одной области и поверхностными — в смежных.
Совмещать можно, но нужно осознанно ограничивать себя. Следует следить не только за приоритетами задач для разработки, но и за приоритетами своих задач над продуктом. Стоит поставить себе цели на определённый период и придерживаться курса. Если в этом квартале растим метрики — значит, занимаемся только метриками и не лезем в технику или стратегию.
Это в идеале, конечно. На самом деле продакт работает тоже в формате T-shape: есть фокус работы, основная задача, и много всего мелкого, чему тоже нужно уделить внимание, но не такое пристальное.
Мифы о профессии
Почему существует мнение, что PM ничего не делает?
Продакт не пишет код и не делает интерфейсы. Далеко не все задачи менеджера продукта имеют какой-то понятный и видимый артефакт. Из-за этого может казаться, что менеджер «пропал» и ничего не делает, а потом внезапно появился, насоздавал задач — и снова исчез.
Основная польза продакта — в принятии решений, планировании и стратегии, анализе поведения и мотиваций пользователей, а также согласовании действий команды. Вся эта работа остаётся «за кадром», из-за чего может возникать ощущение, что задачи берутся из ниоткуда.
Если команда не понимает задач продакта, у неё может сложиться впечатление, что он занимается ерундой и не приносит пользы. Это лечится коммуникацией: важно объяснять не только что ты делаешь, но и зачем, и какого результата хочешь достичь.
Хорошая практика — регулярно рассказывать команде о квартальных планах, промежуточных результатах и демонстрировать плоды своей работы. Увидел интересное в метриках — поделись открытиями с командой. Это помогает формировать общее понимание продукта и лучше раскрывает роль продакта.
Ну и не стоит забывать: плохие PM’ы тоже бывают. Те, кто не вовлекается в работу, слабо ориентируется в продукте, не понимает пользователей и их цели. Такие продакты не владеют продуктом и портят репутацию всей профессии.
Какие распространённые заблуждения мешают новичкам?
Нет, не должен. Важно помнить: ты работаешь с профессионалами.
Дизайнер должен лучше продакта разбираться в интерфейсах, разработчик — в коде, аналитик — в метриках.
Продакт — это не тот, кто делает работу за всех, а тот, кто держит весь контекст и глубоко понимает пользователей.
Да, у продуктового менеджера действительно должен быть широкий набор навыков. Умение написать скрипт, поправить макет или сделать SQL-запрос — это плюс. Как минимум, такие навыки помогут задавать правильные вопросы команде. Но задача продакта — в другом.
Не стоит переживать, что ты чего-то не знаешь — ты не обязан быть экспертом во всём.
Уже несколько раз про это говорилось выше, и ещё раз повторить будет не лишним, потому что это действительно сильное заблуждение. Нет, продакт не управляет людьми. Продакт управляет продуктом. Менеджер продукта не даёт приказы и указания разработчикам и дизайнерам. Он приносит задачи и обосновывает результат, который хочет получить. Любой участник команды может не согласиться с решением продакта и привести контраргументы, почему так делать не нужно. Когда задача порождает дискуссию, это нормально и даже хорошо.
Продакт — участник команды, а не её руководитель. Это стоит запомнить и всегда держать в голове. А ещё стоит помнить, что ответственность за принятые решения и результаты на плечах продакта. Это значит, что нужно быть убедительным и уверенным в своих решениях.
PM обязан быть технарём или MBA
Некоторые типы продуктовых менеджеров тесно связаны с технологиями и действительно должны быть технарями или иметь опыт коммерческой разработки. Но далеко не во всех продуктах и сферах будут полезны product-менеджеры с техническими навыками. Иногда это может даже мешать, так как менеджер может начать приходить с конкретными решениями по коду, что будет сильно фреймить (загонять в рамки) разработчиков. Всё-таки профессия больше про бизнес, чем про код. Для продакта понимание принципов монетизации важнее, чем знание языка программирования.
Иметь степень MBA, то есть быть профессиональным управленцем, тоже не обязательно. Это будет плюсом, но не так важно, как может показаться. Как минимум потому, что профессия менеджера продукта не про управление, помнишь?
Можно стать продактом без глубоких технических знаний и не будучи дипломированным управленцем. Это не просто возможно, но и является нормой на сегодняшний день. Таких продактов большинство. Но стоит понимать, что, несмотря на то, что ни технические навыки, ни навыки управления не являются обязательными для старта, они точно пригодятся при росте тебя как профессионала.
Критическое мышление;
Навык работы с неопределённостью;
Эмпатия и понимание пользователей;
Навык коммуникации на разных «языках» (дизайн, разработка, бизнес);
Способность систематизировать и принимать решения.
Чем на самом деле занимается PM в течение рабочего дня?
Рабочий день каждого продуктового менеджера индивидуален. Со временем у каждого формируются свои рабочие ритуалы, которых они придерживаются. Например, я начинаю свой день с проверки рабочей почты и чатов, потом иду смотреть набор встреч на текущий рабочий день, после чего обязательно прохожусь по дашбордам и ключевым метрикам продукта — проверяю, нет ли явных аномалий. Это мой ритуал начала дня, он занимает около получаса.
Дальше я могу пойти на рабочие встречи, пройтись по основным сценариям продукта, чтобы быть уверенным, что нет критических багов, и посмотреть, какие задачи были закрыты командой за предыдущий рабочий день. Ну и, конечно, берусь за выполнение задач «мэйлстоунов» (ключевых задач) этого квартала. Обычно они большие, и это что-то, что растягивается на несколько дней или недель. Такие задачи занимают остаток дня между звонками. Ключевые задачи обычно завязаны на поиск точек роста, продумывание новых механик, оптимизацию сценариев продукта и различные исследования. Так или иначе, такие задачи связаны с продуктом и пользователями.
Портрет сильного PM
Хороший продакт это в первую очередь не про навыки, их можно получить в процессе. Это про мышление, поведение и ценности. То есть у продуктовых менеджеров упор на софт скиллы, а не на хард.
Какими качествами должен обладать хороший PM?
Умение видеть не хаос задач, а взаимосвязи. Раскладывать сложное на простое, структурировать процессы, фокусироваться на сути.
Понимание пользователя, команды и стейкхолдеров. Слушать, замечать, сопереживать, вникать в контекст — это ключ к созданию нужных решений.
Способность быть «крайним» за продукт. Не перекладывать вину, не прятаться, а брать на себя результат и последствия.
В целом правильной стратегией будет — если результат успешный, то это заслуга команды, а если нет, то это вина продакта. Это про отношение в первую очередь. Посыпать голову пеплом и винить себя во всех неудачах не нужно. А вот поблагодарить всех причастных в случае успеха крайне важно и полезно для атмосферы в команде.
Ты — проводник между командами. Умение слушать, доносить мысли ясно, договариваться в работе продакта важнее, чем SQL, Figma и знание языка программирования.
Хороший PM постоянно спрашивает «почему?», хочет разобраться глубже и не боится копать до сути. Фактически, это и есть работа продуктового менеджера.
PM работает в условиях неопределённости. Умение адаптироваться и менять план без истерики — must-have. Не нужно жалеть потраченного на задачу времени. Если в процессе стало понятно, что это какая-то ерунда — смело бросай и делай что-то другое. Даже если приходится бросить то, над чем работаешь уже второй месяц. Ты не спасёшь провальную идею и только потратишь больше времени.
Можно ли развить эмпатию, системность и продуктовое мышление?
Продуктовое мышление — это насмотренность. Смотри, что делают конкуренты в похожих продуктах. Старайся понять, почему приложение конкурента работает именно так, а не иначе. Разбирай фичи продуктов, которыми ты часто пользуешься. И много экспериментируй. Так ты наработаешь продуктовое мышление. Но не забывай про нетворкинг и профильные книги. Читай книги и общайся с другими менеджерами продукта. Использовать чужой опыт для развития — это хорошо.
С эмпатией и системностью сложнее. Это софт-скиллы, которым очень трудно научиться. Но возможно!
Эмпатия — это про сочувствие. Чтобы начать сочувствовать «болям» пользователя, нужно лучше его понять. Если есть возможность, общайся с пользователями (интервью, опросы, посиди на техподдержке). Читай отзывы о продукте и пытайся понять их, читай между строк.
Системность — это про структуру. Самое сложное в системности — начать. Начни писать документацию по продукту. Можно сначала описать только основные вещи, без углубления. И старайся делать это регулярно. Структурируй задачи и планы. Если идёт сложно и много печатать не хочется, то нужно искать способы визуализации задач. Это обманет твоё восприятие, позволит создать структуру и будет ощущаться не так сложно, как написание документации.
Что делает PM, когда не знает ответа?
Продуктовый менеджер почти никогда не знает ответа на обнаруженную проблему. Такая специфика работы. К незнанию стоит относиться спокойно — со временем это вообще станет привычным состоянием. Неопределённость — часть профессии, и она всегда будет шагать рядом.
Неопределённость нужно рассеивать с помощью интервью с пользователями, анализа конкурентов, метрик продукта (аналитики) и экспериментов — главных инструментов PM’а.
А ещё нельзя забывать, что продакт работает среди специалистов, и можно спросить экспертного мнения у своей команды. Вполне может оказаться, что кто-то из них сам сталкивался с похожей проблемой или решал подобное раньше.
Если задача необъятная и сложная, а ответов найти не удалось, правильным решением будет двигаться шаг за шагом. Разбей задачу на понятные части и через эксперименты, анализируя данные, ищи правильный путь. Это долго и дорого, но лучше, чем вариться в догадках и сидеть без ответа.
Как отличить сильного PM от просто активного?
Если дело не заходит дальше разговоров и нет результата по продукту (метрики не растут, пользователи жалуются на одно и то же), перед вами просто активный продакт. Красный флаг — менеджер продукта не может объяснить, зачем нужно делать задачу. Это не всегда означает, что PM слабый, но точно говорит, что над этой задачей долго не думали, и понимание поверхностное. Сильный продакт всегда знает «зачем», потому что задачи рождаются именно исходя из ответа на этот вопрос.
Какие ошибки чаще всего совершают начинающие PM и как их избежать?
Боятся задавать «глупые» вопросы
Банальный совет: глупых вопросов не бывает. Если есть сомнения, лучше сразу уточнить, чем потом всё переделывать. При работе над продуктом время буквально стоит денег. И ладно, если только работа продакта потом пойдёт под нож. Куда хуже, если проблемная задача уже оказалась на проде (доступна пользователям). Куча денег выброшена на ветер. И всё потому, что было задано на один вопрос меньше, чем нужно.
Помни про системность. Порядок касается всей деятельности продуктового менеджера. Ставь себе приоритеты и придерживайся их. Не всё важно, и успеть всё невозможно. Результаты важнее процесса.
Не взаимодействуют с пользователями
Продукт делается не для менеджера или команды (хотя и так бывает), продукт для пользователя. А как можно сделать хороший продукт, если не общаться с теми, для кого он предназначен? И чем чаще, тем лучше. Но хотя бы раз в месяц нужно контактировать с пользователями: проводить интервью, поработать в техподдержке.
Хотят «идеальное» решение сразу
Работай итерациями. MVP, гипотезы, эксперименты. Не бойся делать «черновики». Может оказаться, что «идеальное» решение на самом деле никому не нужно. Лучше понять это на ранних этапах.
Записывай всё, что только можешь. В идеале с датами, участниками и кратким описанием того, к чему пришли. Это особенно важно на старте, потому что голова будет кипеть от новых знаний и ситуаций. Ну и ты не робот, и всё в голову уложить не сможешь. Ведение ежедневника упрощает жизнь и позволяет всегда держать обещания.
Итог первой главы
PM — не универсальный солдат и не «шеф» над командой. Это связующее звено, аналитик, фасилитатор, коммуникатор и стратег в одном лице.
Существуют разные специализации: от технического продуктового менеджера до ориентированного только на рост, и выбор зависит от твоих интересов, навыков и контекста компании.
Нет одного верного пути: важно пробовать, осмысленно рефлексировать и постепенно находить свой фокус.
PM часто невидим со стороны, и это создаёт мифы о «ничего не делании». На самом деле, это роль, полная неопределённости и внутренних решений.
Продакт — это человек, который берёт ответственность за конечный результат, несмотря на то, что не управляет напрямую людьми и бюджетом.
Важнее всего — умение видеть суть, не теряться в задачах и не бояться признать, что ты чего-то не знаешь.
Лучшие качества — эмпатия, системность, продуктовое мышление, честность, фокус.
Сильный PM — это не тот, кто громко говорит, а тот, кто создаёт ценность, умеет слушать, учится на ошибках и не забывает, ради кого делается продукт.
Ошибки — часть пути. Главное — извлекать из них уроки и расти.
Тоже самое в формате тг-канала: https://t.me/pm_faq. Сначала будет выходить там отдельным постами по чуть-чуть, потом здесь большой статьей.
