14594
О менеджменте продуктов как науке от Сергея Тихомирова (ST) и Никиты Ефимова (NE). Ceterum censeo Carthaginem esse delendam.
Команда ProductSense проводит ежегодное исследование
Уже в седьмой раз мы собираем картину российского продуктового сообщества — и в этом году особенно сосредоточены на будущем профессии: как меняется роль продуктового менеджера, какие навыки станут ключевыми, и куда движется рынок.
Примите участие в исследовании «Менеджмент продуктов 2025: трансформации профессии и рынка, актуальные навыки».
Что вы получите от участия:
🔴Рефлексию
Сопоставите свои приоритеты в развитии команды и личной экспертности с тем, что считают важным коллеги по рынку.
🔴Ориентиры
Поймете, какие компетенции и практики сейчас в фокусе у сильных продуктовых команд.
🔴Продуктовую культуру
Данные исследования помогут точнее выстроить процессы найма, развития и оценки в вашей компании.
🔴Тренды
Соберем прогноз на горизонте 2 лет — от трансформации роли продуктового менеджера до востребованности ИИ-продуктов.
372-й выпуск подкаста make sense: о моделях мышления, поиске точек роста и драйверах роста ценности продуктов
«Получение нового объекта в своей модели мышления — это сложное физиологическое действие, у вас, грубо говоря, должен мозг перепрошиться. Он не любит перепрошиваться, он, наоборот, любит сокращать когнитивные ресурсы»
«Чтобы найти способ сформировать новые модели роста или, в принципе, выйти из какого-то кризиса, вы должны расширить вашу систему мышления, то есть научиться думать некоторыми новыми объектами, отличными от тех, которыми вы думали раньше»
«На то, чтобы человек принял какую-то новую концепцию, не только её понял, ещё раз — принял, и начал изменять своё поведение, исходя из этой новой концепции, требуется год-полтора»
Ведущий:
Юра Агеев, основатель ProductSense
Гость:
Сергей Тихомиров, NEST Consulting, Управляющий партнёр
Конференция ProductSense пройдёт 11-12 сентября в г.Москва
Сайт конференции: https://productsense.io
Подписывайтесь на канал анонсов подкаста: /channel/mspodcast
О чём говорим:
00:00 — Введение
01:31 — Обстановка на кризисном рынке: почему бизнесы становятся нерентабельными?
06:58 — Причины и последствия накопленной усталости продактов
13:27 — Чем полезна минимальная эффективность процесса исследования?
15:17 — Эффективность модели роста продукта
18:40 — «Проблема компании не в продукте, а в бизнес-модели!»
23:40 — Что делать, если этап роста позади?
28:15 — Смещение фокуса на внутреннее состояние и саморазвитие
30:13 — Точки роста команды находятся в зоне их некомпетентности
35:55 — Система мышления и уровни абстракций
39:55 — Драйверы роста ценности продукта
42:49 — Менеджеры продолжают мыслить фичами
45:55 — Что делать, если нет мотивации двигаться дальше?
50:07 — Изменение модели мышления через действия
54:10 — Теорема о противоречивости и полноте
58:33 — Сколько времени требуется на внедрение новых концепций мышления?
В подкасте упоминаются:
— Джеймс Клир “Атомные привычки”
— Дорф Боб, Бланк Стив ”Стартап. Настольная книга основателям”
Слушать:
— Telegram
— Mave
— Apple
— Яндекс
— YouTube
Мир поломался. Очередной раз. Кажется, что это стало очевидно всем за последний год.
Экономика планомерно скатывается в жопу, всё сильнее сужая коридор рентабельности. Бизнес закрывается, сокращает людей, инвестиций нет, регуляторика каждую неделю что-то регулирует или запрещает.
На рынке хрен пойми что. С одной стороны дефицит вакансий. С другой стороны толпы джуниоров после курсов не могут найти работу, бродя как зомби. С третьей стороны выжженая земля с руководителями и лидами. Даже с middle уровнем. Менеджеры продуктов все чаще думают заняться столярным делом и мастерить табуретки.
Технологии ИИ развиваются с такой скоростью, что не успеваешь читать новости. За пару лет мы прошли путь, который раньше требовал десятилетие. Половина IT рвёт на себе волосы, потому что ИИ выдает качество на уровне джуниора и ставит под угрозу их позицию. Я сам лично охреневаю от появившихся возможностей. AGI не за горами, предвещая сингулярность цивилизации.
В продуктовых компаниях низковисящие фрукты все съедены, а серебряные пули расстреляны. В стратегиях не видят смысла, потому что вся энергия уходит только на адаптацию и выживание. Менеджеры продуктов, еще недавно трансформировавшиеся из "проектного подхода", снова начали превращаться в менеджеров проектов, потому что задачи компаний все больше стали из разряда "импортозаместить", "починить", "сделать просто, чтобы работало".
На всём этом фоне люди перестали учиться. Вовлеченность низкая, мотивация слабая, в глазах усталость, домашки никто не делает. Большая часть людей, даже если ходят, не понимают целей, зачем им учиться в таких условиях. Я это вижу по студентам в ДВФУ, Сколково и любым другим корпоративным обучениям, которые проводил за последние полгода. У коллег то же самое. Профиль и поведение студента сильно изменилось.
Будущее стало не просто туманным - оно стало "несущественным". Ощущение, что ты стоишь на краю мира и смотришь в Бездну. А, как известно, если долго вглядываться в Бездну...
PRD и документация по продукту
Менеджеры продуктов не любят бюрократию. Настолько сильно, что следованию правилам и созданию документов предпочитают личные взаимоотношения и бесчисленные встречи. К сожалению, именно по этой причине в отрасли сложилось мнение, что софт скиллы важнее хард скиллов, но мое личное убеждение, что это фиксация следствий, а не причин.
Причины же заключается в том, что большей части людей сложно долго удерживать фокус на чём-то и формулировать свои мысли ясно. Люди думают образами, отношениями и поэтому при каждой попытке написать нормальные требования или объяснить команде, какую ценность мы принесем этой фичей потребителям, от менеджера продукта можно услышать поток сознания, схожего с больным синдромом Туррета, но не четкие конструкции.
Да, у менеджеров есть небольшое оправдание - когда среда слишком быстро меняется, то любой написанный документ уже может стать неактуальным к концу его написания. Другой аргумент - что многие не хотят делать "документы ради документов", ведь это излишняя бюрократия. Но оба забывают ключевые причины, почему важно следовать процессам и фиксировать свои мысли с помощью документов.
Во-первых, любой хороший документ нужен для того, чтобы вы структурировали свой поток своего сознания, пока вы его составляете. Это тот случай, когда процесс важнее результата, ведь формируя документ на основе какой-то методологии, вы задаёте вопросы, а именно вопросы заставляют ваш мозжечок пыхтеть, а не ответы на них.
Во-вторых, любой документ тем хорош, что начинает существовать в отрыве от вас, тем самым делая процесс масштабируемым. Вам не нужно проводить три встречи, чтобы объяснять голосом - вам нужно скинуть один документ. На самом деле именно это является способом синхронизации, а не когда вы проводите стендап.
📆 В ближайший четверг, 17 июля, в 19:00 Мск мы проведём первую открытую сессию-разбор... «Полётов»... Нет, «ухода на второй круг»... Ну или ваших текущих продуктовых болей и «затыков».
Мы станем для вас такими внешними «диспетчерами» и с разных сторон «покрутим» вашу текущую ситуацию, чтобы найти новое, свежее решение и по-другому взглянуть на контекст.
👮🏻♂️Саму сессию проведём в формате «Плохой и хороший полицейский» (нас же двое). Почему так? В стандартных сессиях часто получают либо мягкий коучинг, либо жёсткий «вы всё делаете не так». Мы решили это объединить:
- Один из нас будет раскручивать ситуацию «вглубь»: задавать неудобные вопросы, ставить под сомнение очевидные решения, искать настоящую причину, а не симптом.
- Второй будет предлагать сценарии: как можно выйти из ситуации, что ещё можно сделать, как это делали другие команды.
Условия участия:
→ Сессия публичная – будьте готовы кратко описать продукт, стадию и задачу
→ Цифры не обязательны, важна чёткая формулировка запроса
→ Сфокусируйтесь на одной ключевой проблеме
Записи не будет! Ссылка на встречу появится накануне.
Есть кейс? Готовы участвовать? Пишите в комментариях. Подробности и детали выясним в переписке.
P.S. Фоточка настоящая, вчерашняя.
Как формализовать модель продукта, чтобы можно было сравнивать будущее и настоящее?
В прошлом посте мы говорили о том, что для работы со стратегией необходимо и анализировать текущее состояние продукта, и моделировать его будущее состояние. Удобнее всего делать это, если у вас имеется единый фреймворк: тогда можно задавать одни и те же вопросы, чтобы увидеть вектор развития и иметь возможность сравнивать полученные результаты. В этом может помочь модель описания продукта MPCM (адаптация модели Brian Balfour). Изначально модель делалась для стартапов, но модификация может быть использована для любого продукта.
Согласно этой модели, мы управляем не просто совокупностью фич, продукт — это многофакторная система, которая учитывает как внутренние взаимосвязи, так и внешние воздействия. Какие, например?
1. Рынок:
— потребители и их поведение,
— конкурентные решения,
— структура рынка и цепочка поставки ценности,
— регуляторика рынка.
2. Продукт:
— совокупность решений для удовлетворения потребностей рынка,
— ценностные предложения,
— позиционирование,
— УТП,
— дифференцирующие факторы.
3. Каналы:
— каналы привлечения потребителей,
— способы донесения ценности,
— дистрибуция ценности.
4. Модель:
— модель монетизации,
— структура расходов,
— цепочка создания ценности продукта.
Связь блоков между собой предполагает проверку ценности, которую создает ваш продукт. Например, связь между рынком и продуктом позволяет вам определить, есть ли у продукта Product-Market Fit (подробнее о Market в Market/Product Fit и других «фитах»— в выпуске подкаста make sense c Вячеславом Аскалеповым).
Почему стоит попробовать использовать модель MPCM?
Данный фреймворк удобен для комплексного анализа продукта с его внутренними и внешними факторами. С точки зрения визуализации эта модель наглядно показывает, что продукт — это сложная система. И меняя что-то одно, в других частях вашей системы также необходимо проводить анализ изменений.
Модель описания продукта MPCM позволяет:
— делать анализ целой картинки;
— выявлять причинно-следственные связи;
— видеть динамические процессы изменений во времени;
— наблюдать изменения связей частей системы и вовремя реагировать на них.
По мотивам доклада «Один раз не... или Как работать со стратегией продукта на постоянной основе» Никиты Ефимова на конференции ProductSense’24
– Ну что, делаем стратегическую сессию?
– Ага. Как в прошлом году? С флипчартами, мотивацией и кофе с вкусняшками?
– Спасибо, один раз хватило. В этот раз давайте серьёзно. Хотим прям стратегию.
– Так может, мы просто плохо фасилитировали?
– Нет, вы просто начали слишком поздно.
– А если мы всё-таки хотим провести хорошую сессию?
– Начните до неё.
Чуть дальше в исследовании есть картинка про зоны ответственности. По ней виден старый добрый принцип "чем правее, тем краснее". То бишь с изменением позиции у вас не меняются функции - их просто становится больше. Что в корне является неверным подходом, потому что с изменениям позиции должен меняться ваш объект управления, поэтому красного не должно быть больше - он должен смещаться в другие области. Конечно, здесь может быть проблема с самой типизацией зон ответственности или вопросами, которые были заданы, но хочется подсветить этот нюанс в принципе, а не применительно к этому исследованию. Потому что часто в компаниях так и получается, что потом приводит к проблемам вида "CPO так закопался в операционке, что не остается время на стратегию".
Здесь я снова хочу понудеть про объекты управления и деятельность. Особенно в контексте структуры команды и джуниоров. Когда вы Lead или Head of Product (и уж тем более CPO) вашей задачей в первую очередь является не работа с функционалом продукта и даже не тестирование гипотез, а создание модели роста вашего продукта или бизнес-юнита. Создание такой модели требует оперирования не фичами и перебором гипотез, а драйверами роста и свойствами продукта и бизнес-модели.
Эффективное разделение полномочий команды с лидом / хедом и джуниорами - это когда опытные занимаются построениями таких моделей роста (построению такой модели, например, учат в симуляторе роста GoPractice - если интересно, то вот ссылка на 10% скидку), а потом реализацию части модели при помощи конкретных гипотез и фич делегируется Джуниору. Правда это работает тогда и только тогда, когда у джуниора перед глазами есть конкретная методология работы как с отдельной гипотезой, так и с отдельной фичей, которая состоит из нескольких гипотез.
В итоге за счет разделения объектов управления мы решаем проблему конфликта и микро-менеджмента между лидом команды и джуниорами. Последние показывают свою эффективность только в условиях четких целей и алгоритмов действия, которые и определяются лидами. Тем самым происходит создание условий для масштабируемости бизнеса в целом: команды снижают риски за счет экспертизы лидов в модели роста (где больше неопределенности и меньше времени), и имплементации через ресурсы джуниоров (где меньше неопределенности и больше времени). И это хорошо работает на этапе scale, но никак не pre-seed и seed стадиях.
В общем, если вы CPO, Head of Product или Product Lead и хотите научиться тому, как правильно выстроить команды, чтобы решить проблемы масштабируемости вашего бизнеса, то напишите "что делать-то?" в комментариях к этому посту. Для вас будет интересное предложение.
А если вам некогда учиться, но очень хочется оптимизировать текущую работу ваших продуктовых команд, то добро пожаловать к нам в Nestx.ru. Мы этим занимаемся.
ST
Вообще, я планировал написать что-то полезное, но до сих пор охреневаю под впечатлением от возможностей ИИ. На этот раз в интерактивных текстовых играх (здравствуйте, 90-ые). Натолкнулся на рекомендацию Байрама Аннакова про мини-игру во "вселенной" отчета AI 2027 /channel/ProductsAndStartups/1265
Решил поиграть за выгоревшего программиста Алекса, которого скоро должны уволить. И тут понеслось... Я не знаю, как команда StoryLeaf это сделала, но это просто огонь. У меня получился действительно живой рассказ, где было и философствование про ИИ, и шпиономания, и любимая тема Звездных Войн с повстанцами.
Сначала я хотел раскрыть основной сюжет получившейся истории, но потом решил выложить её в полном виде. Поэтому читайте или создавайте свою историю при помощи бота - это действительно потрясающий опыт. И демонстрация того, как сильно поменяется взаимодействие игроков с NPC в играх вроде TES. Собственно, они перестанут быть NPC и будут обладать своими собственными историями и действиями, а миры станут действительно живыми.
Закончу пост эпилогом, который получился в ходе продолжения этой мини-игры даже после завершения основной канвы сценария у моего хорошего друга:
Где-то в далёкой галактике молодой агент крадёт секретные данные ИИ, не подозревая, что запускает цепь событий, ведущую к рождению новых богов.
ST
Про другую постановку задачи
Недавно промелькнули две новости про ИИ в продуктовых компаниях, особенно важных на фоне сокращения бюджетов. Во-первых, CEO Shopify изменил политике найма и выделении ресурсов. Теперь при запросе на увеличение ресурсов, команды должны продемонстрировать, почему они не смогут получить желаемое, используя искусственный интеллект (ссылка). Во-вторых, CEO Duolingo написал сотрудникам, что компания делает разворот в сторону перестройки процессов с учетом фактора искусственного интеллекта, начиная от оптимизации бутылочных горлышек и заканчивая постепенным отказом от подрядчиков в пользу ИИ (ссылка).
Как пишет в своем email Луис фон Ан: "AI isn't just a productivity boost". Есть большая разница между оптимизацией процесса и перестройки (рефакторинга) вашей бизнес-машины. В первом случае мы работаем над отдельным процессом, меняем последовательность действий, какие-то шаги, артефакты и даже участников процессов, но процесс по сути остаемся тем же. Рефакторинг же включает избавление от старой логики, замену одних сущностей на другие, отказ от одних процессов, ролей и функций и добавление совершенно новых.
Совершенно очевидно, что нас ждет целая волна перестройки не просто процессов управления продуктами, а вообще принципов управления как таковых. В последние месяцы я очень много времени провожу над ИИ-инструментами в задачах управления продуктами, тестируя разные решения на разных кейсах разных индустрий. Например, есть четкое понимание, что при правильной постановке задачи и выборе модели (не ИИ, а модели решения задач), DeepSeek вполне себе выдает результат уровня junior product manager (которых не должно существовать в принципе), а где-то даже доходит до middle. Или понимание, что на первый план выходит действие "верификации" результата вместо его "генерации", что вносит значительные корректировки в процесс design thinking. Или что правильный формализм и артефакты стали действительно важны, а если вы думаете, что soft skills помогут вам лучше общаться с ИИ, то у меня для вас плохие новости :)
В одном выступлении Денис Пушкин, ex-CPO SkyEng, рассказывал о разнице между задачами вырасти на 50% и в x10 раз. Меня это очень зацепило. Разница заключается не только в амбициозности цели, а в том, что при её решениях используются совершенно разные модели. Первый путь "классический", когда вы работаете теми же самыми способами, что и раньше: гипотезы интерфейса, оптимизация воронки активации и т.д. Но этими способами не достичь цели x10 (отбросим фактор низкой начальной базы) - здесь требуется каких-то кардинальных изменений бизнес-модели, перестройки системы дистрибуции или продуктового рефакторинга. Это совершенно другая постановка задачи.
Так и с применением искусственного интеллекта. Когда вы должны аргументировать перед запросом ресурсов, почему вы не можете получить желаемое, применив ИИ-инструменты, это совершенно другая постановка задачи. Решив правильно эту задачу, вы получите рост эффективности не в 50%, а в x10 раз. Правда, чтобы решать такие задачи, нужно и думать научиться совершенно по-другому.
ST
Во-первых, уже через месяц пройдет конференция PeopleSense 2025. Организует её команда ProductSense, но в отличие от неё PeopleSense посвящена управлению командами, процессами и собой любимым. Поэтому строго обязательна для c-level, руководителей направлений и тимлидов.
Наконец-то есть где поговорить про Product Operations, но делать я это, конечно же, не буду :) Зато оба дня буду резидентом нетворкинг зоны МТС, где любой может записаться на встречу и получить консультацию по проблемам выстраивания эффективных процессов, организационной структуры и работе продуктовых команд. В прошлый раз на ProductSense встречи шли нон стопом и прям чувствовал, что принес пользу коллегам.
На самой конференции будет куча полезных выступлений, но особенно хочу обратить внимание на доклад Славы Аскалепова, Head of Product Звука, о том, как вовлечь команды в стратегическое управление и связать это с операционным продакт менеджментом. Спойлер - это получилось сделать не без помощи теории объектов управления, про которую я время от времени писал (ссылка 1, ссылка 2, ссылка 3, ссылка 4). Обязательно приходите его послушать - у Славы получился крутейший сторителлинг, описывающий путь длиною 1,5 года от момента разработки стратегии до реорганизации команд. С причинами, следствиями и выводами. Всё, как вы любите.
👉 Подробная программа докладов доступна на сайте конференции
Сценарный анализ – это основа того самого стратегического форсайта, про который много говорят, да мало понимают, как его делать. И кажется, что именно эту часть пока будет сложно делегировать ИИ, т.к.:
а) галлюцинации тут будут запредельные, если GPT умудряет врать даже относительно фактического прошлого
б) никто, кроме менеджера продукта внутри компании, не сможет лучше всего прочувствовать как текущий контекст, так и возможное влияние различных сценариев будущего на успех компании.
Да, управление продуктами — это математика, а не творчество. Но пока она всё ещё в руках менеджеров продуктов.
В качестве P.S.
Основой стратегии является не выбор какого-то одного пути, ведущего к победе, а создание таких условий, чтобы все пути вели к ней.
(с) Игра Форов
Сценарный анализ
В предыдущих постах мы размышляли на тему возможного будущего продуктового управления: когда менеджер продукта становится простым оператором ИИ и начинает вместе с GPT галлюцинировать на тему развития продукта и рынка, перекладывать ответственность управленческого решения на бездушный алгоритм и безоговорочно ему верить (ведь не может же врать такой умный и дорогущий алгоритм от Сэма А.). Если бы мы делали какой-то продукт для таких менеджером (как одной из ЦА), наша стратегия должна была учитывать этот сценарий будущего. Неустойчивая стратегия опиралась бы только на него; сильная - учитывала больше.
Только вот будущее является неопределенным и трудно предсказуемым в большинстве случаев. Оно формируется на основе множества значимых и влияющих друг на друга факторов (событий и тенденций). А многие менеджеры продуктов, особенно с доступным ныне GPT, пытаются описать одно конкретное будущее, предугадать его.
Из менеджеров в операторов
На выходных был на выставке про путешествия Hello Camper в Севкабель Порту. На докладе о том, как зарабатывать на блоге про путешествия, спикер предложил алгоритм, от которого я слегка прихерел:
1) создаёте блог на Дзене;
2) открываете ChatGPT, спрашиваете самые актуальные темы про туризм на "месяц + год";
3) говорите ему написать статью по одной из этих тем с припиской "для дзен";
4) добавляете туда свои фотографии (или опять же созданные при помощи ИИ);
5) Профит!
План Картмана, в котором есть середина. Потрясающе! Виртуозно! Обескураживающе! Ещё никогда в истории человечества актуальный контент не создавался так просто. Фактически по мановению волшебной палочки.
А прихерел я немного по-другому. Получается, что блогер в этом деле фактически превращается в "оператора", который просто нажимает кнопки, не создавая контент, а "настраивая" его. Блогера больше нет. Остаётся пелевинский криэйтор.
Прихерел я и от того, что читатель блогера в таком случае не знает, что материал сгенерирован машиной. И все равно будет его читать. А SEO алгоритмы будут его индексировать. А монетизация блога будет приносить деньги. Вся эта история полноценно возвращает нас к тесту Тьюринга, который мы успешно проваливаем.
Ну да черт с ним с блогом про путешествия. Ничего страшного не случится, если будут читать то, что написала про Сулакский каньон или лёд Байкала машина, ведь так?! Но что, если это будет управление продуктами? Давайте представим себе некую гипотетическую ситуацию, что некто запустил канал или сайт с блогом, где все статьи сгенерированы нейросетью. А сотни людей читают это, лайкают и признают глубокую экспертизу автора в этом вопросе.
В MVP-строении один из самых популярных способов тестирования называется "Волшебник страны Оз". Когда клиент пользуется продуктом, но при этом не знает, что на бекенде на самом деле нет никакого продукта: вся автоматизация выполняется вручную. Предложу свою версию, назовем ее "Реверсивный волшебник", когда читателем являемся мы, а в бекофисе вместо ручного труда наоборот автоматизация. Если вы думаете, что таких авторов в этой нашей тусовке нет, то просто присмотритесь внимательнее к тому, что вы читаете. Может оказаться, что ложки действительно не существует...
Или ещё один вариант модели — "Волшебник изумрудного города", когда просто берут чужие статьи, прогоняют через chatgpt и выдают как свои. Так, например, случилось с моей про результаты исследования продуктовых компетенций от ФРИИ. Причем подвох здравомыслящими людьми был понят сразу, но криэйтор продолжал защищаться.
Ну ладно, читать или не читать контент, пусть даже сгенерированный машиной, — личный выбор каждого человека. Обидно, если вы не будете знать, машина это или человек, чтобы сделать осознанный выбор. Но ещё обиднее, когда вместо нейроблогера у нас есть нейроменджер.
Сейчас только ленивый не пишет про применение ИИ в задачах управления продуктами. ChatGPT действительно расширил наши возможности, но в то же мы столкнулись с ловушкой гиперинфляции: "стоимость" когнитивных операций настолько сокращается, что происходит их обесценивание.
Поиск материалов для исследования рынков, который раньше составлял недели, теперь делается за часы. Генерация идей, над которой вы раньше страдали по вечерам, теперь делается за пару запросов. Вычленение смысла из встреч и формирование meeting notes теперь вообще происходит без вашего участия. Триумф человеческого гения! Или начало конца. Так или иначе, ящик Пандоры открыт.
Это не просто рассуждения. И вот почему. Исторически программы автоматизировали человеческую деятельность. То есть сами операции оставались, но время / стоимость их выполнения сокращалось, а эффективность повышалась. В примере выше про поиск информации для исследования: искать все равно придется, но потратим меньше своего времени. Просто пишем запрос и Perplexity даёт нужную информацию.
Чем мы НЕ будем заниматься:
🗙 Продавать курсы "как стать продактом", "провести страт.сессию", "выводить продукт на рынок" и прочие. Мы фокусируемся на дельте для компании, а не для конкретного человека.
🗙 Продавать фреймворки Product Led Growth, OKR, SAFe, Jobs-To-Be-Done и прочие. У нас нет серебряных пуль - мы подбираем инструменты по результатам аудита потребностей.
🗙 Продавать исследования и проводить их за вас. Мы хорошо понимаем роль и ценность исследований, но фокусируемся на том, для чего они предназначены.
🗙 Продавать решение без объяснения, как и почему оно было получено. Мы сокращаем риски, время и деньги компании на формирование результата, но пройти по этому пути компания должна сама. Знания должны оставаться внутри.
Но мы с радостью поможем выстроить процессы и смыслы компании, стремящейся быть не только успешной в изменчивом настоящем, но имеющей амбиции долго оставаться такой в бушующем океане будущего. https://nestx.ru/
Причем эта схема может применяться к каждому из этапов Product Discovery: и работе с потребностями, и анализу рынка, и тестированию спроса, и созданию прототипов, и исследованию причин оттока, и т.д. и т.п. Если так же упрощенно представить операции discovery, то это будет выглядеть вот так:
Читать полностью…
Я люблю фантастику. Одним из авторов, открывших для меня эту дверь, стал Ник Перумов и его книга "Гибель богов". Она про то, как маг-изгнанник вместе со своим учеником и друзьями по колледжу завалили богов. Одной из идей книги было то, что стержнем своей силы другие маги делали какие-либо предметы, чтобы, пользуясь им, сила преумножалась. А главный герой сделал стержнем своей силы самого себя. Поэтому её нельзя было у него отнять. Что бы ни происходило вокруг.
Это я к чему. Стратегию можно построить только на твердой почве. Если внешняя среды плывет и постоянно меняется, нужно искать то, что остается стабильным. Очень часто - это наша внутренняя среда. То есть мы сами или наши команды. В эпоху перемен развитие вперед возможно, только если оно начинается с самого себя. И в первую очередь с собственного мышления.
Я помню, когда на российском рынке стала распространяться концепция Jobs-to-be-Done. Это был 2014 год и многое для этого сделала компания Intercom со своими статьями и книгой. Эта методология предлагает совершенно другой взгляд на то, зачем люди используют продукты, введя концепцию "найма на работу". Это концепция не только позволила объяснить, почему люди покупают продукты, но потом пользуются ими лишь несколько раз, но и дала инструменты для решения этой продуктовой задачи.
Аналогично Agile ввела новые объекты мышления, а методология scrum упаковала их в процессы. А LeSS и SAFe ввели новые объекты, позволив решить задачу масштабирования. Как и OKR. Как и RHYTM от Spotify. Как и юнит-экономика.
Все они позволили расширить "математику" вашей коробочки, чтобы вы смогли либо решать больший круг задач, либо делать это за меньшие ресурсы, либо с большей эффективностью. Да и в целом, если не закапываться, ключевой задачей мозга является распознавание. Распознавать он может только то, что ему известно. Поэтому если ему известны только круги, то с квадратом будет большая проблема.
Это я к тому, что любой туман неопределенности - на самом деле не туман. А облако объектов, которые ваш мозг еще не умеет распознавать. Потому что они ему не знакомы. Поэтому тот налёт фатализма, который был в первой части поста, на самом деле не такой уж и печальный.
В то время, как многие сложили лапки, наоборот необходимо больше вкладываться в себя и учиться, собирая больше объектов мышления в свою коробочку. В то время, как все забивают на стратегию, наоборот необходимо научиться с ней работать, чтобы суметь быстро пересобирать в быстро меняющейся среде.
Вот как раз об этих вещах мы и решили поговорить с Юрой Агеевым в подкасте Make Sense. Надеюсь, вам понравится. Сложная, отчасти неприятная, но важная тема для выходных. Тру стори, рил ток.
Самым главным документом в управлении продуктами является PRD, или Product Requirements Document, или Требования на продукт, который объясняет целесообразность создания новой ценности:
- что послужило причиной его возникновения;
- зачем он необходим, какие цели перед ним стоят;
- на какие потребности он ориентирован и как они будут удовлетворены;
- какие ресурсы необходимы для его создания и запуска;
- и как выглядит план на верхнем уровне.
По сути, с этого документа должна начинаться работа над каждым новым продуктом или значимой его частью. PRD необходим, чтобы выстроить совместную работу над продуктом, создавая согласованность и снижая неопределенность между менеджером продукта, членами кросс-функциональной команды и заинтересованными лицами.
Снижение рисков происходит за счет последовательного прояснения сути продукта или фичи и включает в себя четыре области, которые нужно сделать прозрачными для команды:
Purpose - пространство предназначения;
Customer & value - пространство ценности для потребителя;
Solution - пространство решения;
Execution - пространство запуска.
Распространенным стереотипом считается, что менеджер продукта садится и за раз его пишет, чтобы получить ответы на все вопросы. Однако, это не так. PRD - это динамический документ, чье описание формируется по мере работы команды над продуктом или фичей. Попытки заполнить сразу всю информацию шаблона, как правило, приводят к тому, что практика написания PRD не приживается в компании. Соответственно, компания несет издержки на коммуникацию, которых можно было бы избежать.
Хорошей практикой заполнения PRD является добавление минимальной информации, достаточной для старта дискуссии над продуктом или фичей. Как правило, это пространство предназначения (purpose space). Остальные блоки добавляются по мере развития дискуссии или получения новой информации во время работы команды.
При этом PRD структурно связывается с другими артефактами, которые являются уточнениями тезисов из которых состоит описание продукта. Например, это карточки гипотез, требования в разработку, стратегия запуска продукта и т.д. Отображение такой логики можно посмотреть на картинке к этому посту.
Существует много разных шаблонов PRD, от минимальных в виде one pager до обстоятельных. Недавно GoPractice собрал в одном посте шаблоны разных PRD https://gopractice.ru/hint-prd/
В списке присутствует и мой шаблон, с которым вы можете познакомиться по ссылке https://docs.google.com/document/d/1I61-3IfI6qqsDQM5Cnvw0aFztQNbRU9CCq9St8Z3vCE/edit?usp=sharing
В качестве бонуса ещё добавлю шаблон карточки гипотезы https://docs.google.com/document/d/1C-9NCwm5_AFssK72OEJK2ujQjuuZVvK-8p1tHverp6s/edit?usp=sharing
P.S. Сейчас тестирую один из новых продуктов GoPractice "AI-прототипирование:от идеи до продукта за 1 день". Расскажу о впечатлениях попозже.
Книги, базы знаний или искусственный интеллект
В прошлый четверг мы с Никитой провели первый вебинар по "диспетчеризации" для b2b платформы, которая предоставляет доступ компаниям к библиотеке книг и небольших курсов по подписке.
Разогнав тему с помощью модели роста, хотим поделиться несколькими интересными выводами, которые могут быть полезны в ваших продуктах.
1) Часто, когда продукт дорос до каких-то границ рынка, способом "перешагивания" за эти ограничения является ресегментация, то есть адаптация продукта под разные сегменты потребителей. Например, библиотека для ML специалистов, аналитиков, менеджеров продуктов, продажников и т.д. Это позволяет увеличить конверсию для каждого из сегментов и тем самым общую выручку.
2) Несмотря на то, что конечным пользователем является сотрудник компании, потребителем является HR департамент, который решает либо задачу мотивации, либо задачу развития / обучения сотрудников. То есть сама по себе библиотека не нужна - она является "фундаментом" для другой системы. Системы, в котором образование и компетенции сотрудника - часть производственного процесса, соответственно, чем выше эти компетенции, тем выше эффективность процессов, внутри которых существуют сотрудник (BPMN системы). Да и сами книги в такой логике - не лучший способ удовлетворить эту потребность. Лучше подойдут курсы и микро-модульное обучение, которое есть у EdTech платформ. Кстати, это открывает хорошие возможности для партнерств с ними.
3) Последнюю мысль на вебинаре мы попробовали пролонгировать в будущую эпоху ИИ. Большая часть кейсов использования библиотек связана с профессиональной литературой, которые учат конкретным инструментам, фреймворкам или методологиям и концепциям мышления. Однако, человечество всегда идет в сторону экономии своих когнитивных ресурсов (не путать со способностями), поэтому стали так популярны краткие изложения книг. Сами книги воспринимаются просто как хранилища информации, которую необходимо из них извлечь для решения своих насущных задач. То есть по сути компаниям не нужны книги - компаниям нужны базы знаний, откуда их сотрудники могут подчерпнуть значимую для себя информацию. А еще лучше, если эти базы знаний будут обладать контекстом компании, который хранится в других документах этой компании. ИИ теперь решает такие задачи на раз.
Есть и следущий шаг этого путешествия. По сути, сами базы знаний тоже не нужны - нужны ответы на вопросы, как мне, конкретному сотруднику, выполнить рабочую задачу с максимальной эффективностью при минимальных ресурсах. То есть мне нужны не информация даже, а алгоритм действий с учетом этой информации, что включает контекст задачи + контекст компании + контекст умных книжек. А с алгоритмами действий нам сейчас очень хорошо помогают ИИ ассистенты. То есть по сути конечной точкой развития текущих библиотек и даже ed tech являются не статьи, книги и курсы, а ИИ ассистенты, которые помогают сотрудникам решать их рабочие задачи, показывая как учитель или ментор, как это делать правильно.
Вкратце так. Записи не было. Следите за следующими анонсами и оставляйте ваши заявки в комментариях :)
Начну издалека...
В Сочи достаточно специфичный аэропорт для пилотов: заход на посадку всегда только с моря, резкая смена ветра и его внезапное усиление, уход на второй круг возможен только на определённой высоте (с полосы нельзя). Поэтому тут я постоянно наблюдаю уходы на повторные круги, т.е. попытки сделать тоже самое (приземлиться) ещё раз:
- дождаться благоприятных условий
- немного поменять «параметры» приземления
А вот в случае невозможности осуществить посадку диспетчеры отправляют самолёты на запасной (для Сочи) аэропорт в Мин.Водах.
Это к чему? Продуктовые команды периодически попадают в «ловушку второго круга», т.е. когда в продукте возникает затык, начинают делать то же самое, но просто чуть по-другому:
- Не сработала идея? Запустим похожую
- Не растём? Добавим новый канал
- Теряем долю на рынке? Скопируем у конкурентов, они же растут
Чтобы выйти из этой ловушки нужен «диспетчер», который посмотрит на ситуацию с внешней стороны, оценит возможные варианты и подтолкнёт команды к чему-то другому.
Один раз не... или Как работать со стратегией продукта на постоянной основе
При работе со стратегией команды выбирают разные подходы и иногда попадают в ловушку: либо слепо следуют плану, игнорируя изменения, либо постоянно реагируют на внешние сигналы, теряя из виду образ будущего. В обоих случаях стратегия становится либо фикцией, либо хаосом. Чтобы этого избежать, важно выстроить регулярную работу со стратегией — как с гибким, постоянно настраиваемым инструментом.
Стратегия — это понимание места и роли компании/личности/продукта в будущем потоке событий, позволяющее сформировать интегрированный набор действий, для достижения успеха. А значит, важно держать в фокусе и внешние, и внутренние изменения, при этом превращая их в выводы в действия.
Разберем, как можно двигаться по стратегическому плану.
После каждого шага следует осмотреться, понять, что происходит с нами и что на это повлияло, оценить угрозы и возможности на горизонте, скорректировать образ будущего, скорректировать следующие шаги, сделать конкретные ставки.
Это очень похоже на плавание на байдарке: нужно постоянно взаимодействовать, балансировать, корректировать свои действия, принимать решения.
Как делать это на регулярной основе?
Для этого можно использовать модель стратегического менеджмента и проходить 5 шагов каждый квартал (или за такой промежуток времени, которым планирует ваша компания):
1. Оценка ситуации
— Делать оценку устойчивости продукта.
— Создавать модель оценки состояния продукта 360 и учитывать изменения ключевых показателей.
— Проводить анализ показателей портфеля продуктов.
2. Стратегический контекст
— Смотреть с двух сторон: что уже произошло и что может произойти? Как нам это использовать или учитывать?
— Оценивать через фреймворки по оценке внешних факторов: силы рынка, силы индустрии, силы трендов, силы макроэкономики.
— Вовлекать команду и подходить к анализу с готовыми данными (например, сделать группу в Telegram, куда можно скидывать анонсы. Раз в месяц или квартал группировать сигналы, искать кластеры и выявлять факторы, делать анализ изменений).
3. Актуализация видения
— Избегать ловушки немедленной реакции.
— Учитывать данные из прошлого: стратегические активы, стратегические обязательства, текущее поле интересов, профиль личной силы.
— Учитывать факторы, ожидаемые на рынке в будущем: как должно поменяться место продукта на матрице устойчивости? Что мы корректируем: образ будущего или путь его достижения?
4. Стратегическое поле альтернатив и выбор
— Создать поле альтернатив: думаем, как менять образ продукта.
— Обращать внимание на текущее состояние: какие есть риски, если не прореагируем сейчас? Если вообще ничего не делать, что-то вообще произойдет? Сколько доступных ресурсов у нас есть? Какие у нас краткосрочные цели?
— Разработать карту паттернов изменений.
5. Инициативы
Вместо хаотичного бэклога:
— Понимаем тип изменения и его влияние на всю систему.
— Выстраиваем связь между изменением и конкретными метриками.
— Производим логичный переход к целеполаганию.
— Проводим каскадирование изменений.
Получается, что для регулярной работы со стратегией важно:
✅ Двигаться каденциями (то есть систематически возвращаться к ней через определенные промежутки времени).
✅ Анализировать внутреннее и внешнее состояние продукта и рынка.
✅ Собрать себе модели, которые позволят отслеживать динамику.
✅ Не поддаваться соблазну бросаться исправлять точечные проблемы и наполнять бэклог сотней новых идей.
Что получаем бонусом:
✅ Единый вектор распределения усилий для всех бизнес-функций.
✅ Планы по всем продуктам.
✅ Карту коммуникаций.
По мотивам доклада «Один раз не... или Как работать со стратегией продукта на постоянной основе» Никиты Ефимова на конференции ProductSense’24
Только-только прошла Game of PAF в Москве, как мы с Сергеем Шигалёвым, организатором общества "Продакты СПб" готовим её проведение в Питере 12 июля на площадке Garage Eight.
Эту игру можно считать "обратно юбилейной". Это когда событие значимое, но гордиться нечем :) Во-первых, потому что открытых Game of PAF, куда могли бы прийти все желающие, в Санкт-Петербурге не было уже три года. А во-вторых, потому что я сам из Питера, как никак. Почётный ценитель архитектуры северного модерна, драккаров и Некрасова. Поэтому, я сделал специальную скидку 3000 по промокоду ALMAMATER.
Если вы тоже из Питера и давно хотели посетить Game of PAF, то это ваш шанс (или искали повод, чтобы сюда приехать). А если вы в первый раз слышите об этой стратегической бизнес-игре, то про неё можно почитать вот тут.
Спешите записаться на Game of PAF 12 июля в Санкт-Петербурге https://productframework.ru/gameofpaf
Бедный Junior! - Я знал его, Горацио. Это был человек бесконечного остроумия, неистощимый на выдумки.
Коллеги из Devcrowd и Контура подготовили ежегодное исследование рынка менеджеров продуктов https://devcrowd.ru/pm25/. Нашел одну интересную вещь, которая подтверждается моим субъективным опытом обучения и консалтинга.
В исследовании появилась раскадровка по этапу жизненного цикла продукта:
20,5% менеджеров работают на pre-seed и seed стадии
54,7% на scale
22,5% на support
Плюс коллеги сделали разрез по грейду менеджера и оказалось, что джуниоры в основном сидят в pre-seed и seed стадиях, а мидлы - на скейле и саппорте. Меня это удивило по несколько причинам.
Во-первых, в рамках жизненных циклов существует две самых большие точкм неопределенности в продуктах. Первая - это его запуск до момента нахождения product/market fit и product/channel fit, а вторая - когда вы достигли максимума по своей текущей модели роста и требуется новая стратегия. Это критические точки, которые определяют дальнейшую жизнеспособность продукта или бизнес-юнита целиком. В этом же исследовании 44,7% менеджеров признали, что чаще всего сталкиваются с неопределенностью при планировании стратегии, а 34,1% при поиске product/market fit.
Сложность их прохождения заключается в том, что:
1) слишком много потенциальных сценариев
2) требуется проделать большую последовательную работу по discovery
3) нужно уметь отличать значимое от незначимого, чтобы через полтора года всё не развалилось в процессе работы
Мне хорошо знакома как первая стадия Product Discovery (потому что проводил обучение по этому процессу для пары сотен менеджеров и наблюдал результаты их работы), так и вторая (потому что этим мы занимаемся на курсе Сколково по управлению стратегией). Джуниоры не обладают ни насмотренностью, ни знанием методологии Discovery, ни опытом отличать зерна от плевел. Даже классическая аналитика фейлов стартапов от CB Insights говорит о том, что 35% кейсов - это отсутствие спроса и/или потребности, чья проверка являются ключевым фактором для Product Discovery.
Получается противоречие - на один из самых ответственных этапов компании бросают самые неквалифицированные ресурсы. А потом удивляются, почему продуктовый подход не работает. Junior Product Manager - его еще нужно выращивать. Я вижу две самых эффективных конфигурации для него.
1) Либо в связке с мидлом или сеньором на этапе scale в роли подмастерья для перенятия опыта, когда менеджер может делегировать часть своих задач (правда AI инструменты здесь сильно конкурируют с джуниором). Или же когда понятна модель роста и поэтому джуниору можно делегировать ответственность за какую-то понятную ветку продукта, где необходима операционная работа с продуктом при понятных целях и способах.
2) Либо использовать джуна на этапе саппорта, как низкорисковой деятельности, чтобы он смог войти в контекст как продукта, как и качественной и количественной аналитики по нему, что поможет набить руку.
Всем привет. Есть хорошая новость - в этом году я планирую провести несколько открытых Game of PAF. Ближайшая игра будет проходить 7 июня в Москве. Группа по большей части собрана, но еще есть свободные мест! Поэтому для тех, кто давно хотел посетить мероприятие - добро пожаловать :)
Game of PAF - это стратегическая бизнес-игра, которая представляет собой некоторую симуляцию жизни продуктовой компании на конкурентном рынке. За один день у участников будет возможность:
* посмотреть на жизненный цикл бизнес-юнита,
* на "собственной шкуре" получить представление о рисках и последствиях тех или иных решений,
* понять, на чем стоит концентрироваться на каждом этапе,
* какие существуют стратегии достижения целей
* как взаимосвязаны все компоненты компании, продукта, маркетинга и рынка друг с другом
Мы будем много дискутировать, обсуждать различные кейсы и менять ваше мышление. Game of PAF - отличная возможность для каждого, кто хочет увидеть продукт и его развитие как целостную картину.
Как проходит мероприятие?
Участники разбиты по командам, конкурирующим друг с другом на ограниченном рынке. Цель каждой команды - стать лидером рынка, развивая свой продукт, приносящий прибыль от привлеченных клиентов и созданных фич. Игра разделена на три этапа, отличающихся собственными целями, стратегиями и набором действий. Сложность возрастает с каждым этапом. Командам придется думать не только о краткосрочных выгодах, но и сокращать долгосрочные риски, реагируя на сложившуюся ситуацию и подбирая оптимальные стратегии.
Подробнее https://productframework.ru/gameofpaf
Во-вторых, сам я выступлю спикером на конференции ProductConf, очная часть которой будет в эту пятницу (онлайн идет уже сейчас!). Вот так вот внезапно, да :) Душнить я буду про то, каким образом организационная структура ограничивает развитие бизнеса и продукта. Ладно, на самом деле там будет много мяса в виде кейсов, объяснения причин почему что-то не работает и как это поправить. Спойлер - ключом ко всему снова являются те самые объекты управления.
Выступление затронет несколько тем:
- чем плохи "функциональные колодцы"
- почему происходит замещение стратегии проектами
- размытие зон ответственности в погоне за одной и той же метрикой
- ошибки сквозной схемы приоритизации
- как среда формирует наше мышление
👉 На меня тоже приходите! https://productconf.ru/speakers/
Всем привет, на связи Сергей Тихомиров и у меня две хороших новости.
Читать полностью…
И тут возникает своеобразный стратегический парадокс. Стратегические (и не очень) консультанты учат нас, что в процессе стратегирования сначала необходимо сформулировать видение компании (т.е. представить её в будущем), а затем проработать конкретные шаги в направлении этого видения. Но ведь неопределённость будущего контекста рынка, индустрии и всего, что окружает компанию, делает такое видение весьма условным. Будущее предсказать невозможно, значит и однозначно представить образ компании в будущем тоже, кхе-кхе, довольно сложно. Тут и появляется парадокс: при «угадывании» развития контекста стратегия оказывается успешной, но в противном случае эта же стратегия становится провальной, когда относительно «предугаданного» будущего что-то идёт не так.
Фишка в том, что нам не нужно пытаться предсказать или угадать будущее. Наша задача – построить различные логически обоснованные варианты (модели) развития будущего, которые будут устанавливать границы изменения контекста компании. Ключевое слово тут «различные». Мы не должны пытаться предсказать одно точное будущее. Наша задача описать несколько различных сценариев. Сценарий не может быть один. Если он один, то вы либо очень много знаете, либо ваш горизонт стратегирования очень маленький (либо вы победитель битвы экстрасенсов на тнт).
Вторая фишка в том, что сценарии не могут существовать (т.е. реализовываться в будущем) одновременно. Сценарии – это взаимоисключающие реальности, в которых ваша компания (и отрасль в целом) может оказаться в будущем. Наша задача описать картину будущего с разных точек зрения и оценить возможные последствия того или иного варианта. Очертить границы изменения, как я писал выше.
Для описания таких границ или сценариев мне нравится подход 4P, который позволяет с разных сторон посмотреть на будущее:
- Probable (вероятное будущее). Проецируем/экстраполируем информацию из прошлого и настоящего в будущее, т.е. пытаемся спрогнозировать «в лоб» текущие и будущие тренды.
- Possible (возможные варианты будущего). Прорабатываем возможные сценарии на основе различных исходов неконтролируемых нами факторов. Вырабатываем 2-3 ключевых сценария развития будущего потока событий.
- Preferred (предпочитаемое будущее). То самое будущее, которое мы описываем в рамках «классического» подхода к стратегии. Как будет выглядеть контекст, рамки будущего, где мы получаем максимальную выгоду (как бизнес). Это будущее, в которое мы хотим попасть; состояние, где нас ждёт максимальная выгода. Это максимально приземлённое на реальность будущее, поэтому не стоит называть его идеальным.
- Preventable (предотвращаемое будущее). Включаем «оборонительное» мышление и прорабатываем пессимистичный или негативный образ будущего, в рамках которого нам придётся думать только о защите своей позиции или угрозы жизни компании в принципе.
И теперь наша задача найти и выбрать такую(-ие) поведенческую стратегию, последствия реализации которой были бы благоприятны при любом рассматриваемом сценарии. Она должна максимизировать наш выигрыш при любом варианте развития ситуации и обеспечивать минимальный уровень риска.
Затем, менеджеры начали экспериментировать. Что, если мы не только будем делать запрос на получение информации, но и вообще будем просить машину проанализировать и сделать выводы. А потом ещё и рекомендации по свойствам продукта. А потом ещё и макеты интерфейсов. А потом ещё и код. Дьявольская простота всех этих операций вскружила голову менеджерам. Они почуяли всемогущество. Ложное всемогущество.
Происходит (уже / прямо сейчас) проблема замещения. Когда вы просите машину не просто дать информацию, а сделать выводы, то вы замещаете процесс автоматизации процессом принятия решения. Тем самым вы теряете контроль и как менеджер больше не выполняете возложенную на себя функцию, потому что перестаёте владеть контекстом и причинно-следственной связью. А, как говорил Меровинген, единственный источник власти — это умение видеть причину.
Среда формирует нашу физиологию и мышление. Аналогично тому, как stories разжижают мозговину (к сожалению, мне тоже сложно соскочить с этой иглы), использование ИИ для задачи анализа постепенно атрофируют наши собственные способности к этому. Нам все сложнее вычленять главное и работать с большими объемами информации. Вместо понимания принципов, мы ищем кейсы. Вместо формирования долгосрочной стратегии — сбор низковисящих фруктов. Вместо выбора правильного, мы выбираем простое.
Делегируя процесс принятия решений в машину сотрудник превращается из менеджера продукта в оператора, чьей задачей является нажимать кнопки. При этом можно даже не особо понимать значение входных и выходных сигналов из chatgpt. Кстати говоря, именно такая модель и лежит в основе самого популярного мысленного эксперимента по критике теста Тьюринга. Он называется "Китайская комната" и был предложен Джоном Серлем как демонстрация того, что машине необязательно осознавать, что именно она делает, при этом прекрасно создавая видимость интеллекта. Стандартная проблема при найме, не так ли?
А вот теперь представьте, что вы руководитель и у вас в подчинении менеджеры продуктов. Присмотритесь к ним повнимательнее — действительно ли они менеджеры или превратились в операторов? Действительно ли они могут думать самостоятельно или вместо них работают 15 индийских микросервисов? А если вы работаете удаленно, вы вообще уверены, что они существуют? :))
Да и эффективность тестовых заданий для продактов, в которые я искренне верил и использовал, теперь можно поставить под серьезное сомнение. Если ответ можно сгенерировать, то в чем смысл испытания? Мне теперь даже интересно, насколько можно "взломать" конкурсы Авито и взламывал ли их уже хоть кто-то с помощью ИИ.
Я не знаю, куда заведет использование ИИ в product management. Действительно ли мы получим "новое качество жизни управления" или поколение менеджеров, способных умножать только при помощи калькулятора. Будут ли они вообще менеджерами или превратятся в "операторов", блестяще умеющих "конфигурировать" концепты продуктов и их траекторию развития при помощи ИИ. Я не знаю этого, но вижу четкую тенденцию движения именно в ту сторону. Управление продуктами — это математика, а не творчество. Многокритериальная, вероятностная, с эффектами хаоса. Но математика. Рано или поздно ИИ с ней справится. Как только это наступит (а будущее наступает сегодня очень быстро или даже внезапно), роль менеджера продукта претерпит серьезные изменения.
ST
Вторая новость связана с этим каналом. Как видите, в гнезде живут грачи-бородачи. Поэтому канал “Борода продакта” теперь будут вести две бороды, а не одна. Мы будем чередовать наши посты с Никитой, стараясь выйти на регулярность в один пост в неделю. Такая частота позволяет не скатываться в блогинг с постами “очевидное невероятное про скоринг” из трех предложений, оставляя глубину и качество материалов. У нас все также не будет никакого контент плана. Мы будем стараться писать лишь о том, что сами считаем важным, а не делать посты ради них самих.
Всем хорошего дня! Грачи-бородачи.
P.S. У меня есть стойкое ощущение, что 2025 будет годом преображения. Позитивного или негативного, не знаю, но моментом, когда прежняя форма меняется, потому что больше не соответствует своему смыслу. Самое главное – никогда не забывать кто мы такие и почему здесь оказались.
Никита Ефимов, директор колледжа Сириус, ex-CPO Skillfactory, Яндекс Практикум и Звук. Более 20 лет опыта в ИТ. Автор фреймворка Feature Canvas для проработки идей продукта, чей шаблон добавили себе платформы Miro, Canvas, Figma. Большой опыт обучения людей на российском и зарубежных рынках.
После появления названия NEST, первой шуткой была «Строим в компаниях гнездо здравого смысла, чтобы кукуха не улетела раньше времени». Нас объединило желание прокачивать культуру менеджмента: людей, процессов, продуктов. Стратегию компании делать научились, а управлять потоком стратегических задач ещё предстоит. И мы в этом поможем.
У меня есть видение. Что управление продуктами не сводится к низковисящим фруктам, получаемым за счет простых инструментов. Не сводится он и к бесчисленному множеству моделей, никак не связанных друг с другом. Управление продуктами - это система, которая управляет конечным набором объектов по некоторому набору правил. Эта система красива так же, как красива математика возникающей снежинки. Я вижу эту красоту, восхищаюсь ей и хотел бы показать её компаниям, чтобы они быстрее и с меньшими для себя рисками могли менять реальность к лучшему.Читать полностью…