Вообще, на этот Product Sense мы с разными коллегами подавали аж три доклада, но ни один из них не прошел. Сложно сказать, почему именно. Может быть потому, что контент слишком методологического характера и не совпадает с духом других докладов. Может быть потому, что мы плохо смогли донести ценность для аудитории. Может быть потому, что не смогли выстроить понятный сторителлинг.

Ну а сами доклады на такие темы:

1) С коллегами из Теле2 Казахстана мы хотели рассказать о создании Integrated Product Indicator - комплексного показателя для оценки эффективности работы менеджера продукта, который включает не только достижимость целей, но и само качество работы по разным процессам: заполнение артефактов, прогресс роста показателей продукта, качество процесса разработки и т.д.

2) С коллегами из душевного Контура мы хотели рассказать про карту-конфигуратор навыков менеджера, которая позволяет просто и понятно определить зону ответственности специалиста, его дальнейший трек и грейд. В компании, где существуют продукты разных размеров и этапов жизненного цикла, где одни менеджеры могут отвечать только за продукт, а другие за целую связку бизнес-юнитов. При этом все могут называться "менеджер продукта". А также результаты оценки по этой системе на паре сотен менеджеров.

3) С питерской бандой мы хотели рассказать о специфике управления внутренними продуктами: что есть рынок, как тестировать ценность, как перейти от схемы "заказчик - исполнитель" к полноценной продуктовой работе, как это синхронизировать с инвестиционным циклом бюджетирования, как аргументировать свои решения перед бордом и что делать с продуктом дальше после запуска. Потому что в этом году мы с коллегами адаптировали Product Architecture Framework под специфику управления внутренними продуктами, упаковав в отдельную методологию 3K. На базе которой мы собрали курс, который анонсируем в скором времени.

Поэтому, если вас интересует какие-то перечисленные темы или вы устраиваете свои конференции - приглашайте и пишите. Мы с удовольствием расскажем :)

Всем привет. Завтра и послезавтра будет проходить Product Sense. Внезапно на нем буду и я в секции экспертов, которую организует ЦИАН, где каждый может найти эксперта по своей проблеме и проконсультироваться с ним 20-30 минут. Бесплатно и без смс.

Чтобы это сделать, нужно установить приложение Event.Rocks, найти через поиск Product Sense и авторизоваться в ней. Там будет кнопонька "Встречи с экспертами", где можно найти нужного человека и забронировать слот для встречи, чтобы он, голубчик, не отвертелся. И всё. Он ваш. Клетка захлопнулась.

Или же другой вариант - искать среди примерно 1500 участников по залам :) В любом случае, желаю всем полезных знакомств и новых идей.

Make Value. Make Sense. Not something else.

За эти 8 лет работы над PAF мне, наконец-то, не стыдно назвать его фреймворком, потому что в нем появилось то, что и определяет суть любого фреймворка - это модель мышления. PAF задает структуру через которую можно мыслить о реальности, тем самым либо научившись решать более широкий спектр задач, либо делая это с меньшими рисками и ресурсами, либо с большим качеством.

PAF включает четыре слоя управления: Strategy, Business Unit, Operational Product Management и Hypothesis. Для каждого слоя определены объектная модель, процессы и артефакты и определена их декомпозиция. Для каждого процесса есть инструменты, для каждого артефакта шаблоны. Есть набор сквозных моделей вроде модели бизнес-юнита или value stream, которые объединяют инструменты разных уровней в целостную картинку. Также, для наглядности я вынес несколько ценностей на саму картинку фреймворка:
- Понимание контекста важнее генерации идей. Время на получение одной хорошей гипотезы будет меньше, чем время на тестирование десяти низкокачественных.
- Спринт продукта важнее спринта разработки. Управляйте продуктом, а не разработкой и утилизацией её ресурсов. Приоритизируйте бутылочные горлышки и точки роста продукта, а не элементы беклогов.
- Успешность развития продукта не определяется вашими представлениями об успешности. Оно определяется этапами жизненного цикла рынка и продукта.
- Структура ролей команд определяется объектами управления и бизнес-функциями, а не названием должностей.
- Продукты сокращают ресурсы потребителей на переход из состояния неудовлетворенной потребности в состояние удовлетворенной потребности. Этот путь называется value stream. Value stream определены иерархией потребностей. Границы продукта определяются Value Stream.
- Ценность для бизнеса создается за счет создания ценности для потребителя. Ценность для потребителя создается благодаря созданию ценности для бизнеса. Это одна и та же медаль.
- Видение и стратегия определяют цели текущего момента с учетом обстоятельств среды. Реактивность определяет способ реализации проактивности, но не формирует её.

Конечно же, предстоит еще огромный пласт работы по формализации фреймворка, чтобы по качеству описания он встал в один ряд с BABOK или SAFe. Это дело следующих нескольких лет. А вот, что произойдет в течение пары месяцев - я проведу серию вебинаров, где расскажу про каждую из частей Product Architecture Framework, чем он отличается от других методологий и в чем может быть профит от его использования в вашей компании. Об этом я сообщу отдельно.

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

Всем привет. Вчера мне исполнилось 36 лет, и я решил, что это отличная дата, чтобы представить вам первую версию Product Architecture Framework. PAF - это фреймворк управления продуктами, над которым я работаю более 8 лет.

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

Поэтому спустя пару месяцев была готова модель жизненного цикла продукта, которая "задавала ритм" деятельности продакта. Модель определяет фокус на конкретной активности из всего множества, контрольные точки, риски и последовательность развития продукта (историческая отсылка). "Динамическая" модель была куда полезнее статической, поэтому параллельно с работой над самим фреймворком, хотелось решать задачу его дистрибуции. А чтобы проще донести идею жизненного цикла в конце 2018 года я упаковал все концепции в стратегическую бизнес-игру Game of PAF, которая проводится до сих пор.

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

В течение следующих нескольких лет я детализировал активности из модели жизненного цикла. Сейчас на сайте они лежат в разделах инструменты, гипотезы и библиотеки. Ключевой проблемой стало формирование связок. Например, все знают, что существуют jobs-to-be-done, customer journey map, empathy map и другие модели. Каждая из них как собственная точка зрения, исследующая собственные черты. Но ведь все эти точки зрения смотрят на один и тот же объект - потребителя. Значит должна существовать какая-то общая системная модель поведения потребителя. И если её нет, значит её можно создать. По подобной логике во фреймворке стали рождаться "связующие" модели вроде модели контекста потребителя или экосистемы продуктов. Они помогли соединить ранее независимо рассматриваемые кусочки управления продуктами. Но самое важное, что они привели к пониманию объектной модели, которая и помогла заново собрать мозаику и все расставила на свои места.

Оказалось, что количество объектов, которые важно учитывать при управлении продуктами, конЕчно и не превышает двух десятков (но и не составляет два или три, как многие любят упрощать). Оказалось, что приоритеты и ограничения роста могут быть вообще не в продукте, поэтому бессмысленно их решать продуктовыми инструментами. Оказалось, что scrum или safe вообще не решают задачу управления продуктами. Оказалось, что логика цикла управления фичами не отличается от логики управления продуктами. Оказалось, что для развития продукта не нужен беклог. Оказалось, что управление продуктами - это не творчество и ремесло, а наука и менеджмент. Оказалось, что Product Architecture Framework на самом деле не столько про управление продуктами, сколько про выстраивание бизнес архитектуры компании с позиции управления продуктами. То есть намного шире, чем я представлял себе ранее.

#mondaily
Сравнение функций CPO и Продуктового Комитета

Функции CPO, как и менеджер продукта, отличаются в зависимости от компании. Где-то он отвечает только за сотрудников, их развитие и процессы. Где-то - за показатели портфеля продуктов. Где-то он полностью владеет бизнес-юнитом и отвечает за экономические показатели. В общем, функции определяются объектами управления.

Дополнительная сложность возникает, когда в компании одновременно с должностью CPO существует Продуктовый Комитет. Каким образом разделить ответственность между ними, чтобы не было пересечений, но при этом закрыты все зоны, подскажет табличка из вложения. Также, её можно использовать для подготовки job description для должности CPO.

Интересное наблюдение. Как-то с Павлом Алферовым, профессором Школы управления Сколково, мы обсуждали специфику менеджмента российских компаний. Павел уже много лет внедряет собственную методологию проектного управления в корпорациях. Хорошо понимая психологию мышления руководителей, он подтвердил мои мысли, почему наравне с функцией CPO может существовать Продуктовый Комитет. 

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

Короче. Ко мне есть три претензии. Что мало пишу в канал. Что если пишу, то слишком длинно. Что если пишу, то слишком сложно.

Во-первых, извините, я тут играю роль профессора. Не видно, что ли?! Во-вторых, всё правильно говорят. Поэтому я решил исправиться и запускаю рубрику #mondaily в формате Тёмной Стороны / Темнографики.

По понедельникам я буду публиковать небольшие (по моим меркам) посты с полезными результатами моей методологической работы по теории управления продуктами или какими-то кейсами из консалтинговой практики.

Чтобы соблюсти каденцию, мне даже пришлось сесть и составить контент-план на несколько недель вперед. Записано в синем блокнотике с надписью "make sense". Есть смысл, я считаю, иначе снова не выполню обещание.

P.S. Первый пост опубликую сегодня как бы за вчера.

Небольшие обновления сайта PAF

Раздел "Балкон" превратился в "Лекториум". Раньше в нем были собраны все лонгриды и видео, а сейчас еще и добавлен раздел с ссылками на полезные посты из Telegram, Telegraph и других площадок.

Пока собирал ссылки, понял, что PAF скоро исполнится 6 лет. Датой релиза можно считать публикацию от 6 августа 2018 года. И я даже нашел видео с митапа, где презентовал его первую версию. Раньше он выглядел совсем по-другому. Да и вообще, его было сложно назвать фреймворком.

Но это все лирика. Добро пожаловать в Лекториум https://productframework.ru/library