Как справиться с любой внезапностью
Не только «Бей, беги, замри»

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

Собраться и начать эффективно распределять свои ресурсы в ответ на изменения могут помочь 4 шага гибкой устойчивости.

Шаг 1: Нормализация.

— Оцените степень кошмарности ситуации по шкале от 1 до 10.
— Абстрагируйтесь и посмотрите на произошедшее с другой точки зрения.
— Попробуйте понять скрытые мотивы поступков других участников.
— Исследуйте ситуацию: кому что выгодно, какие стремления и потребности у вас.

Шаг 2: Поиск опор.

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

Шаг 3: Исследование.

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

Шаг 4: Нахождение решений.

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

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

По мотивам мастер-класса «Как справляться с любой внезапностью? 4 шага гибкой устойчивости» Марии Поповой на конференции ProductSense’24

А ProductSense’25 пройдёт в Москве и онлайн уже 11–12 сентября — следите за обновлениями на сайте или в телеграм-канале @productsense

Фасилитация: как научиться организовывать групповую работу и добиваться целей

В предыдущем посте мы рассказывали что такое фасилитация и для чего она нужна командам. Чтобы вам было проще разобраться и внедрить полезные практики в жизнь, подготовили для вас подборку книг, которые помогут погрузиться в тему:

📚 «Секреты фасилитации. SMART-руководство по работе с группами», Майкл Вилкинсон
Практическое руководство, охватывающее ключевые технологии работы с группами. Книга поможет научиться формулировать цели, задавать правильные вопросы и эффективно визуализировать идеи.

📚 «Руководство фасилитатора. Как привести группу к принятию совместного решения», Сэм Кейнер
Настольная книга для фасилитаторов, выдержавшая более 20 переизданий. Предлагает пошаговые методы и навыки для успешного проведения фасилитационных сессий.

📚 «45 инструментов фасилитатора», Кристина Тишина
Сборник авторских инструментов для практикующих фасилитаторов и тренеров, стремящихся разнообразить свои техники и создать wow-эффект на сессиях.

📚 «Фасилитация для консультантов», Ингрид Бенс
Книга предлагает инструменты для вовлечения клиентов, улучшения обсуждений и построения совместной командной работы.

📚 «Как спасти или погубить компанию за один день: Технологии глубинной фасилитации для бизнеса», Марк Розин
Книга не про помощь команде в обсуждении конкретных тем, а про фасилитацию, призванную запустить организационные изменения. Особенно ценно, что содержание построено на реальных примерах из российской практики.

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

@productmindset

Найдем точки роста для бизнеса на ProductSense’25 🔥

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

Мы уже утвердили 5 треков, по которым будем распределять все доклады и мастер-классы:

1. Стратегия и монетизация

Разберём практики создания и реализации стратегии, инструменты работы с целями, денежными метриками и бизнес-стейкхолдерами. Найдём точки роста бизнеса и продукта.

2. Данные и продуктовые сигналы

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

3. UX & Research & Marketing

Обсудим, как отстроиться от конкурентов на основе потребностей пользователей: позиционирование продукта на основе маркетинговых и UX-исследований, связку UX&UI, опыт пользователей в продукте и каналы продвижения.

4. Саморазвитие

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

5. Команда и процессы

Разберём неочевидные приемы работы с командой, стейкхолдерами, смежниками. Поговорим о пост-agile, проджект-менеджменте, операционной эффективности и отношениях с коллегами.

Подробнее о треках и их кураторах — на нашем сайте. Cкоро опубликуем первых подтверждённых спикеров.

⚠️ 18 июня стоимость участия станет выше, пока билеты по самой привлекательной цене.

Посмотреть билеты →

Фин.модель без иллюзий: как учесть все риски при запуске продукта

При запуске продукта существует большое количество неопределенности: как определить себестоимость, что брать за ключевые показатели и метрики, какую поставить точку безубыточности и так далее. И казалось бы, можно просто взять фин.модель и получить данные. Но не все так просто.

В основе любой финансовой модели лежат некоторые предположения. Создать модель, которая бы не включала искажения, практически невозможно.

Какие могут быть особенности:

1. В фин.модели должны учитываться взаимосвязи и инерционность. Доход стараемся брать по минимуму, расходы по максимуму.

2. В модели необходимо наличие не более 5 вводных параметров. Например:
— зависимость выручки от среднего чека
— зависимость выручки от количества юнитов
— зависимость себестоимости от зарплаты сотрудников
— зависимость себестоимости от стоимости юнита (для банка, например, юнитом является клиент. При этом, у одного юнита может быть несколько продуктов: карты, вклады, ипотеки и т.д.). Честно считаем стоимость привлечения юнита. Забываем про "так исторически сложилось".
— зависимость от срока кредита.

3. Для корректного расчета необходимо честно составить бизнес-процесс, учесть все риски и ограничения.

4. В процессе расчета мы не занимаемся подгонкой результатов расчетов под нужные значения.

5. Необходимо предусмотреть различные сценарии развития и провести анализ чувствительности модели к изменению ключевых вводных (проект считается жизнеспособным, если модель выдерживает колебания на уровне 15-20%). А также обязательно включать статью "прочие расходы" в размере 3-5% от валовой прибыли как резерв на непредвиденные расходы.

6. Всегда задаем вопрос "А что если?" и прорабатываем альтернативные сценарии развития продукта.

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

Так в итоге как считать фин.модель на этапе запуска? И можно ли надеяться на удачу?

Лучше считать модель с учетом всех рисков и факторов. При этом если мы понимаем, что все идет не так, то остаемся в той реальности, которая есть на самом деле и принимаем решения исходя из реальных вводных, а не ожиданий, что "когда-нибудь точно сложится". Это поможет делать верные выборы и сохранять ресурсы компании, а если продукт уже запущен, то замечать "поломки" и вовремя пересобирать продукт.

По мотивам доклада Игоря Бичеля "Надеяться на удачу или считать? Инструменты оценки жизнеспособности продукта" на конференции ProductSense'23

Быстрый фан чек-лист грейда для менеджеров продуктов
Синьор помидор или еще зеленое яблочко?

🍏 Junior PM

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

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

Гибкие навыки: ответственность, умение коммуницировать, обучаемость, продуктовое мышление.

Как перейти на следующий грейд: важно быстро набирать опыт, пополнять портфолио кейсами.

🍋 Middle PM

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

Профессиональные навыки: Lean Canvas, JTBD, A/B-тесты, CJM, юнит-экономика, MVP, базовая аналитика, конкурентный анализ.

Гибкие навыки: гибкое системное мышление, уверенность в принятии решений, умение адаптировать фреймворки.

Как перейти на следующий грейд: начать продумывать собственный продукт.

🍅 Senior PM

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

Профессиональные навыки: NSM, P&L, OKR/KPI, Porter/Five Forces, PEST, глубокое понимание статистики и финансов, переговоры и сценарное планирование.

Гибкие навыки: стратегическое мышление, умение выходить за шаблоны, наставничество, публичность, делегирование.

Как перейти на следующий грейд: узнайте в статье «Три грейда в профессии менеджера продуктов» и результатах ежегодного исследования ProductSense «Менеджмент продуктов 2024: карьера, профессиональное развитие, зарплаты, компании и рекомендации сообщества».

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

@productmindset

Аналитика не дает ясности, а гипотезы — результата?
Разберем работающие подходы на ProductSense’25

Если быть честным — как часто вы правда понимаете, что сработало, а что нет?
Метрики есть, дашборды строятся, гипотезы формулируются — вроде бы всё по канону. Но иногда аналитика работает как фон: не мешает, но и не помогает. Фича не взлетает, показатели не растут. В итоге работа кажется бесполезной.

На ProductSense’25 разберем, как принимать решения, которые ведут к росту, а не просто «по процессу».

📍 11–12 сентября, Москва и онлайн.

Вот темы докладов и мастер-классов, которые уже в программе:
🔹 Бросать нельзя продолжать: стратегия второго цикла исследования гипотезы
🔹 Где прячется потенциал? Методы поиска точек роста вашего продукта
🔹 Хорошего продукта уже недостаточно: как создать позиционирование, которое побеждает
🔹 Go-to-Market без фичизма: как синхронизировать продукт, маркетинг и продажи, чтобы продукт продавался
🔹 Трекинг продуктового портфеля: что развивать, что закрывать

Будет много кейсов, личного опыта, проверенных инструментов и отработки навыков на практике. А еще — насыщенный нетворкинг, вечеринка и другие активности.

🎟 Успевайте взять билеты по самой выгодной цене. С 18 июня будут дороже.

Читайте между строк: что должен уметь распознавать каждый менеджер продуктов

Пользователи всегда приходят с желаниями. И почти никогда — с потребностями. Почему так происходит? Потому что желания проще сформулировать.

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

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

Разницу между желанием и потребностью легко увидеть на примерах:

Желание: «Сделайте экспорт в Excel».
Потребность: «Мне нужен прозрачный и удобный способ подготовить все данные к инвест.комитету».

Желание: «Добавьте фильтр по статусу на доске».
Потребность: «Я теряюсь в потоке задач и не понимаю, на чем мне фокусироваться».

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

Как научиться выявлять потребности?

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

1. Слушайте не только слова — наблюдайте за поведением
Где пользователь тормозит, раздражается, бросает? Это основные сигналы, за которыми скрыта его потребность.

2. Говорите не о фичах, а о контексте
Что человек делает до, во время и после использования продукта? Почему для него это важно?

3. Уточняйте мотивацию запроса
Какую проблему он решает? Как справлялся раньше? Почему прежнее решение не подошло?

4. Не принимайте все в лоб. Уточняйте. Переформулируйте
«Что вы хотите сделать?» → «Зачем вам это?» → «А если сделать по-другому?»
Задавайте открытые вопросы. Не подталкивайте к нужному вам ответу. И главное — будьте открыты к «неудобным» инсайтам. Даже если вы считаете свой продукт безупречным, именно такие моменты дают шанс улучшить сценарии или найти новые.

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

Поэтому слушать нужно не то, что сказано. А то, что сказано между строк. Там начинается настоящая продуктовая работа.

@productmindset

Упали продажи, клиенты исчезли: кейс «Газпром нефти» о росте в сжавшемся рынке

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

Где найти новые источники роста ключевых показателей, новых клиентов и как вернуть ту динамику, которую всегда хотелось иметь?

🚕 Кейс «Газпром нефти»: такси с точки зрения поставщика топлива.

Как было: решение о выборе поставщика топлива принимал владелец автопарка, юрлицо — все таксисты заправлялись по контрактам автопарков с АЗС. Продажи топлива шли стабильно.

Что изменилось: пришли новые тренды в работе такси, юрлица передали полномочия о договорах с АЗС водителям такси — количество контрактов с АЗС «Газпром нефти» начало резко уменьшаться, даже в крупных городах упали продажи самого популярного бензина.

Выводы: запрос не изменился — водителям все так же нужно топливо, но сами потребители стали другими: водителям подходит любая АЗС, когда контракт не обязывает их ехать к «Газпром нефти».

Какие решения принимали самостоятельно:
1) Тестировали точки принятия решения.
— Вели переговоры с владельцами автопарков, чтобы те давали водителям директиву заправляться в «Газпром нефти».
— Пробовали сформировать лояльность водителей к «Газпром нефти»: физлиц, самозанятых, ИП.
2) Пытались сделать универсальный офер для только что сформировавшейся новой ниши.
3) Пробовали подготовиться к авансированию клиентов — то есть выдаче кредитного лимита на топливо. С юрлицами трек понятный, но как сформулировать ценность для «водителей на один день» — уже задача со звездочкой.

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

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

Пример: водители оплачивали заправку через приложение банка. «Газпром нефть» обратилась к этому банку с предложением партнерства.

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

💼 Подход к работе с нишами на рынке через коллаборации

1) Выбор сегмента клиентов.
2) Выбор релевантных продуктов и сервисов.
3) Определение топа партнеров, которые предоставляют продукты в эти ниши.

Быстрый чек-лист, как выбирать:
✅ Схожая ценность для клиента.
✅ Сопоставимый уровень зрелости IT-решения.
✅ Готовность к коллаборации.

4) Выбор партнера для создания совместного продукта.

❗️ На что обратить внимание при коллаборации:

— CJM на 2 компании.
Важно ничего не забыть и не запутать клиента, для клиента путь должен быть полностью бесшовным.
— Качественные каналы дистрибуции продукта через партнера.
Это важнее, чем количество. Выбирать стоит наиболее результативные каналы.
— Встройка в коммуникацию партнера.
Клиент привык к языку партнера, важно подстраивать свои коммуникации в тон.
— Ценность партнерства для клиента и обоих партнеров.
Офер для клиента не должен звучать инородно в предложении партнера.

По мотивам доклада «В поисках новых клиентов: как далеко можно зайти и как вернуться с результатом?» Ксении Яковлевой на конференции ProductSense’24

☕️ Кейс: «Очереди в кофейне по утрам»
В одном из постов мы рассказывали о теории ограничений систем и ее пользе, сегодня разберем небольшой кейс.

Контекст:
Маленькая кофейня возле метро. В будние дни с 8:00 до 9:00 — наплыв клиентов. Очередь растет, многие разворачиваются и уходят. Владелец хочет увеличить выручку в утренний час, но команда уже работает «на максимум».

Наблюдение:
— Один бариста полностью обслуживает клиента: принимает заказ, печатает чек, идет готовить кофе.
— Клиенты стоят в очереди в кассу, а потом только переходят к выдаче.
— Оплата занимает по 1–1.5 минуты — особенно с безналом, бонусами, «у меня мелочь где-то завалялась...»
— Часто один клиент платит за нескольких коллег — очередь стопорится.

Ограничение:
Точка оплаты — узкое место. Она ограничивает весь поток. Всё остальное — рабочее.

Решение по ТОС:
1. Максимально использовать узкое место.
→ Вводят предоплаченные карточки с бонусом (например, «заплати за 9 кофе, получи 10-й в подарок по абонементу»), чтобы ускорить оплату. Сотруднику не нужно рассчитывать бонусы, клиенту не нужно дополнительно искать скидочную карту. Транзакция проводится сразу и экономит время.
2. Подчинить всё остальное ограничению.
→ Один бариста принимает заказ + чек, второй делает кофе — разделение ролей, чтобы оплата не мешала приготовлению.
3. Устранить ограничение
→ Устанавливают QR-меню и оплату через Telegram-бота, где можно заранее заказать и просто забрать кофе.

Как результат:
— Очередь движется быстрее.
— Доход в утренний час вырос на 30%.
— Ушедших клиентов стало меньше — большинство теперь заказывает через бота.

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

ограничение → фокус → изменение всей системы вокруг → устранение → новое ограничение

@productmindset

JTBD: книги, статьи, подкасты

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

JTBD — это инструмент, который помогает анализировать потребности клиентов и развивать продукт под их нужды.

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

📕 Книга «Метод Jobs to Be Done. Проектирование клиентоориентированного продукта» →

📋 Статья «Jobs to Be Done: почему важно знать, какую именно задачу хотят решить ваши пользователи» от GoPractice →

🎓 Статья «Как использовать метод Jobs To Be Done: разбираем на примере» от Яндекс Практикума →

📖 Первая глава книги «Главное про Jobs To Be Done» Вани Замесина →

📂 Подборка подкастов make sense и статей из блога ProductSense о работе с JTBD →

А на ProductSense’25 прозвучат доклады, которые покажут другие полезные инструменты для работы с потребностями клиентов: «От разведки до релиза: как измерить эффективность дискавери и сделать так, чтобы она росла» и «Хорошего продукта уже недостаточно: как создать позиционирование, которое побеждает»

Посмотреть эти и другие известные темы можно на сайте productsense.io →

Как научить команду самостоятельно находить и устранять ограничения

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

1️⃣ Введите язык системы: ограничения, поток, узкие места
Люди не ищут то, о чем не умеют говорить.
Объясните ключевые термины ТОС простыми словами:
- Ограничение — то, что сдерживает систему.
- Пропускная способность — ценность, проходящая через систему.
- Воронка — последовательность, где всегда есть точка максимального трения.

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

2️⃣ Регулярно проводите мини-аудиты ограничений
Раз в спринт/неделю задавайте команде 3 вопроса:
— Где мы чаще всего «застреваем»?
— Что мы начинаем, но не заканчиваем?
— Где один человек или этап блокирует всю команду?

Полученные ответы визуализируйте на доске или в Notion в формате «ограничение недели» с возможными решениями и статусом.

3️⃣ Используйте роли: назначьте «охранника потока»
Введение ролевой механики позволит людям держать фокус на конкретной функции: один человек следит за потоком задач — где они скапливаются, где стопорятся. Это может быть разработчик, дизайнер, аналитик — не важно. Роль можно менять каждые 2 недели, чтобы каждый попробовал, что это такое.

Подход работает аналогично agile-системам с «хозяином процесса», но с фокусом на ограничения.

4️⃣ Покажите эффект обхода vs устранения
Пример: задача висит из-за PM → команда обходит ее, делает другое.
Результат: иллюзия занятости, но фича не выходит.
Объясните: обход — не решение, а маскировка проблемы.

Вместо этого стоит обсудить, что мешает сейчас, — и предложить простые варианты устранения (делегировать, автоматизировать, упростить входные условия и т. д.). Важно: варианты должны быть простыми и выполнимыми, ведь наша цель — устранить ограничение, а не сделать еще сложнее.

5️⃣ Отметьте устранение узкого места
Пример: раньше тестирование занимало 3 дня — теперь 1 день, благодаря автотесту. Отмечайте это как достижение на командной встрече: не как «просто улучшение», а как устранение системного ограничения. Это формирует привычку думать в категориях ТОС.

6️⃣ Научите фреймворку «5 шагов ТОС» как шаблону для решений
Пусть команда запомнит шаги:
1. Найти ограничение.
2. Максимально его использовать.
3. Подчинить ему все остальное.
4. Устранить.
5. Искать новое ограничение.

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

7️⃣ Создайте среду, в которой будет безопасно рассказать об ограничениях
Многие не указывают на узкие места, потому что боятся быть обвиненными. ТОС требует культуры: «Мы ищем не виновных, а узкие места».

Закрепите это как командный принцип. Проще это сделать через проговаривание. Например, ретроспективы называются «Что нас тормозило», а не «Кто и где ошибся».

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

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

А о том, как работать с системным мышлением, поговорим на ProductSense’25 на докладах:
– Системное мышление: от микроменеджмента к системному подходу
– Где прячется потенциал? Методы поиска точек роста вашего продукта

Подробнее о билетах, спикерах и программе – на сайте.

9 карт компетенций для проверки навыков менеджеров продуктов

Недавно в канале ProductSense мы рассказывали о том, как создавать карты компетенций и проводить перформанс-ревью в своей компании, чтобы помогать себе и коллегам расти профессионально. Если у вас нет возможности тратить ресурсы на разработку собственного фреймворка "с нуля", мы подготовили подборку готовых шаблонов карт компетенций для менеджеров продуктов — просто изучайте, скачивайте и адаптируйте под свою команду!

📚 На русском языке

— Таблица от Product Mindset
В табличке есть автоматический подсчет оценки домена знаний.
— Таблица от Product Star
В отличие от первого варианта, шкала баллов больше.
— Статья по развитию компетенций от GoPractice
Внутри статьи есть полезная матрица от Авито
— Карта навыков менеджера продукта от Сергея Тихомирова
Карта с удобной визуальной разбивкой.
— Карта навыков менеджера продукта от Product Architecture Framework
Есть разбивка по доменным областям и грейдам.

📚 На английском языке

— Product Competency Toolkit
12 продуктовых компетенций для развития себя и команды.
— Product Skills Assessment
Удобный инструмент для экспресс-оценки своих навыков.
— Product Management Career Development Framework
Фреймворк с подробной разбивкой по скиллам и ожиданиям для каждого из уровней.
— Product management skills matrix template
Инструмент для оценки команды сотрудников.

@productmindset