Борода продакта

2023-02-15 12:09:44 Открыть/Комментировать

2023-02-15 12:07:56 Но вернемся к программам обучения. Следующим важным этапом в них стало внедрение не только сквозных историй, т.е. работы с кейсом-симуляцией или собственным проектом, но и самого фреймворка, мета-модели, которая помогает связать в единое целое методологию обучения и сквозь призму которого объясняются все остальные части программы.

Пожалуй, первая образовательная программа в котором используется сквозной фреймворк, это "Симулятор управления ростом продукта" от GoPractice, запущенная в 2021 году (хорошо, известная мне программа - если знаете другие, поделитесь, пожалуйста в комментариях). В нем была продемонстрирована модель, объединяющая четыре ключевых объекта управления (продукт, монетизация, каналы и рынок), через которую органично объясняются явления цепочек, драйверов и петель роста, бутылочных горлышек, связь с метриками и их влиянием друг на друга, а также явления product/market fit и product/channel fit. Подробнее мой отзыв о программе можно почитать вот здесь.

Герберт Саймон, нобелевский лауреат по экономике и лауреат премии Тьюринга, в своей книге "Науки об искусственном" сформулировал прекрасный тезис: "Решить задачу - это значит найти такое её представление, при котором ответ становится очевидным".

Для меня челленджем в поиске такого представления стала подготовка Общей Модели (нормального названия так и не придумано) для программы обучения CPO от Сколково и Яндекс Практикума, которую мы запустили в 2022 году. Общая Модель демонстрирует взаимосвязь между главными объектами управления в компаниях: рынка и его составляющих, а также моделей создания, дистрибуции и масштабирования ценности. К чему это привело:
1) выделение ключевых объектов, за которые отвечает CPO и члены продуктовой команды;
2) объяснение остальных моделей, предложенных в качестве инструментов для решения задач, а логике Общей Модели, демонстрация отображения их "точек зрения" на общую реальность;
3) демонстрация взаимовлияния разных объектов друг на друга;
4) отображение разницы между внешней и внутренней средой компании, маппирование событий и рисков одной на другую;
5) алгоритм поиска ограничений роста бизнес-модели компании;
6) объяснение разницы между процессами дистрибуции и процессами масштабирования самой компании;
7) отображение разницы между фокусами развития компании на создании ценности и её дистрибуции;
8) объяснение какие объекты должны быть учтены при построении roadmap;
9) демонстрация каким образом можно выстроить структуру продуктового отдела исходя их объектов управления и зон ответственности за бизнес-модель, продукт, дистрибуцию, IT платформы, дисквери-шмискавери и т.д.

В общем, Общая Модель оказалась настолько удачной (по крайней мере в контексте программы обучения), что я даже сам не ожидал. Она и стала тем ключевым стержнем, который связал все отдельные кусочки паззла в единую картинку. Позже я обязательно расскажу про неё детальнее, а также выложу на сайт фреймворка. Открыть/Комментировать

2023-02-15 12:03:50 В 2019 году до пандемии меня пригласили проводить Game of PAF в одну из программ обучения менеджеров продуктов для каждой когорты студентов (по-моему я успел провести для трех). Основной профит проводимой мной бизнес-игры, о котором мне рассказали студенты после участия в ней, был в том, что отдельные части всей программы обучения наконец-то встали на свои места. Стало понятно, как одна модель или концепция связывается с другой, тем самым рождая целостную и последовательную картину мира.

Организация целостности стало большим вызовом для тех, кто хотел создать качественный образовательный продукт. Пожалуй, первым успешным кейсом в этом направлении стал симулятор управления продуктом на основе данных GoPractice, в котором реализована сквозная история приложения Instachat, единый мега-кейс, на примере которого последовательно применяются модели и демонстрируется результат. Это был 2018 год.

Другой способ организации целостности заключается в работе над собственным продуктом студента, на примере которого и выполняются различные задачи программы обучения. Т.е. подготовка скрипта интервью, lean canvas, построение иерархии метрик, построение user story mapping совершают над одним и тем же кейсом студента. Уровень вовлеченности и конечный профит для работы при таком подходе значительно выше, чем симуляция (но далеко не всегда, ведь в симуляторе можно смоделировать данные, которых может не существовать в контексте продукта студента). Именно такой подход я выбирал для программ обучения, которые подготавливал и проводил для EPAM, Nedra.Digital, Леруа Мерлен.

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

Продуктовых моделей - великое множество. Главное - это понимать, что именно за ними стоит, какие конкретно явления они описывают. Каждая такая модель - это точка зрения на объективную реальность, которая рассматривает те или иные её характеристики для решения своих задач. Цепочки формирования стоимости не появились, когда Майкл Портер сформировал их модель, они уже существовали. Как и задачи потребителей существовали задолго до формирования концепции jobs-to-be-done.

"Реальность - это то, что не исчезает, когда вы прекращаете в неё верить". Филип Дик

Именно с этого и началась моя работа над Product Architecture Framework. Когда я изучил и попробовал на деле десятки различных моделей, мне захотелось собрать их в единую целостную систему, ведь они это разные кусочки одной и той же большой мозаики области управления продуктами. Прошло шесть лет до момента, как родилась первая версия PAF в 2018 году. Она была плоха и представляла собой просто классификацию разных моделей. Сейчас фреймворк прошел большой путь, но работа еще далека от завершения. Открыть/Комментировать

2023-02-15 12:01:00 Разговор №5 о системном образовании менеджеров продукта

Его нет. До сих пор. Чтобы ответить почему так, нужно вспомнить путь, который прошло обучение менеджменту продуктов в России.

Первые программы стали появляться лет 10-12 назад. Их продвигали те же, кто обучал разработчиков скраму и другим гибким методологиям. Например, ScumTrek или Octoberry. Программы обучения, что логично, не выходили далеко за пределы роли Product Owner (не менеджера, заметьте) в контексте скрама, разве что были приправлены общими сведениями по практикам Lean Startup и Design Thinking, вроде impact mapping, lean canvas, RACI, story mapping, MVP, модели Кано, lean циклов и HEART метрик (ой, а где же jtbd? а не было его еще тогда). Основной фокус, что менеджер продукта - это человек, который помогает команде взаимодействовать с миром заинтересованных лиц (куда входят, как мы помним, и потребители).

Отрасль развивалась и в ней стали появляться люди, которые с одной стороны наработали навыки применения разных моделей (глубинные интервью, story mapping, customer journey map), а с другой стороны хотели поделиться ими с комьюнити. Так появились первые курсы, где можно было точечно изучить модель и кейсы её применения от экспертов. Кек, не уверен, но кажется именно в это же время и стали появляться продуктовые инфоциганы.

Плюс-минус шесть лет назад зародились первые "большие" программы обучения менеджменту продуктов, которые по сути представляли собой солянку лекций от разных представителей индустрии. Сразу стали видны минусы этих программ:
1) Приглашенные эксперты хоть и работали компаниях с громкими именами, носили звания синьоров, хед офов и директоров, но говорили в стиле Тони Робинсона "делайте хорошо, а плохо не делайте".
2) Приглашенные эксперты просто не могли (не умели?) нормально рассказать свою часть общей программы, а их представление о моделях ограничивалось только их собственным опытом, точкой зрения на реальность. Порой весьма ограниченной.
3) Задания в процессе обучения касались либо небожительских кейсов Netflix, Microsoft, Uber, Apple, либо искусственных кейсов, из которых сложно сделать нормальные выводы. В обоих случаях их практическая применимость сводилась к нулю.

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

2023-02-07 16:52:56 #временныйпост

Коллеги, которые отметили, что они владельцы каналов и готовы присоединиться к инициативе #ProductOpenTribune - пожалуйста, напишите мне в личку @sergeytikhomirov, чтобы обсудить общий манифест (понятные и прозрачные правила игры) и дальнейшие шаги по инициативе.

P.S. опрос был анонимным, поэтому я не смогу вычислить вас сам :) Открыть/Комментировать

2023-01-30 16:25:05 О "голубом огоньке". Я верю, что движение вперед связано с плюрализмом, с обновлением поколений и переосмыслением старого. Нельзя один раз выбрать себе кумиров и потом все время на них равняться. Нужно слышать голоса новых специалистов, которые, есть гипотеза, весьма тихие. Либо потому что у них нет в портфолио кейсов известных компаний, либо потому что они пишут, но в канал на 30 человек, либо вообще отказываются что-либо говорить, хотя могли бы, т.к. не хотят вкладывать ресурсы в создание канала и поиск аудитории. Т.е. есть разница между "каналом" и "сообщением в канале".

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

Что, если создать некое "движение" #ProductOpenTribune, к которому могут присоединиться владельцы каналов. Если ты поддерживаешь это движение, ты должен предоставить возможность любому человеку опубликовать свою статью / мнение с аргументами / постановку проблему с этим тегом. Например, раз в неделю или две недели, как захочет владелец. При этом должны быть понятные и прозрачные правила отбора постов от желающих, которые также можно сделать едиными для этого движения (а потому простыми).

P.S. Ceterum censeo Carthaginem esse delendam. Открыть/Комментировать

2023-01-30 16:23:47 О каналах. Лидерство занимают те каналы, которым с одной стороны много лет, а с другой стороны которые пишут постоянно (необязательно про новое и необязательно нешаблонно). И это нормально, т.к. был большой спрос на новую информацию, который пытались удовлетворить. Помните шутку про "у каждого продакта должен быть канал в Телеграм". Так вот. Это не шутка. Точнее шутка, но уже несмешная. Потому что многие новые каналы либо делают репосты с топа, либо постят каждый год одну и ту же банальную информацию (извините).

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

Product Management включает в себя огромное количество разных аспектов, там копать не перекопать. Если стоять на месте и каждый год писать про jtbd или scrum (ХЕР ЛИ НЕПОНЯТНОГО ЕЩЕ МОЖЕТ БЫТЬ В СКРАМЕ В 2023 ГОДУ???), то непонятно, как двигаться вперед. Поэтому есть отличный способ - представить, что вы об этом уже написали и подумать о следующей теме, исходящей из этой, о которой можно написать. И снова выкинуть это в корзину. И вот только на третьей-четвертой теме можно остановиться, потому что она не будет такой банальной.

С другой стороны таких каналов становится овердохрена и чтобы найти там что-то интересное, нужно потратить много времени (либо все ставят на мьют). Это почти как найти золото в реке. А что происходит на рынках, когда из-за большого количество предложений у потребителей появляется проблема траты большого количества времени? Правильно, появляются продукты, которые эту проблему решают.

12 лет назад в Чикаго родился стартап The Printed Blog, который представлял собой красивую газету (физическую, печатную), контент которой был сверстан на основе постов интернет-пользователей. Они даже продали франшизу предпринимателям из Питера (за 1$), а те запустили глянцевый журнал (в сети даже можно найти промо-ролик). "Сжать всемирную паутину до размеров газеты" было прикольной идеей, но раз вы не слышали о The Printed Blog, видимо не очень прибыльной (монетизация планировалась через рекламу).

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

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

2023-01-30 16:23:01 Разговор №4 о продактстарах, каналах и открытой трибуне

* Топ-5 Telegram-каналов про продакт-менеджмент: «No Flame No Game», «Будни продакта», «Ваня Замесин», «ProductSense» и «Борода продакта».
* Топ-3 подкастов: make sense, Podlodka, Запуск завтра.
* Лучшие книги: Inspired, Спроси маму, Цель, Канеман, Lean Startup, От нуля к единице, Стратегия Румельта
* Эксперты, за которыми следят: Иван Замесин, Илья Красинский, Анна Булдакова, Анна Подображных, Олег Якубенков, Глеб Кудрявцев, Аркадий Морейнис, Андрей Менде, Михаил Карпов, Наталья Бабаева, Владимир Меркушев, Владимир Калмыков, Алексей Писаревский, Дмитрий Безуглый, Александр Горный.

--------

Жизненные циклы и преимущество первого игрока на рынке существует и в профессиональной среде. Фактически, мы получили наш уютный продуктовый "Голубой огонек", где каждый год в хедлайнерах на конференциях и топах статистики одни и те же лица, в топах одни и те же книги, а во множестве новых и старых каналов снова и снова обсуждают, как же блеать правильно применять jobs-to-be-done и про выгорание (хотя Михаил Карпов каждый год открывая ProductCamp рассказывает о том, что темы интересов у комьюнити все-таки меняются и что становится в фокусе). С одной стороны - это закономерно и нормально, а с другой стороны это может быть признаком застоя. Вот об этом и хочется поговорить в этом посте. Открыть/Комментировать

2023-01-27 14:30:46 Последнее, о чем я хотел бы порассуждать - это потери. Структура компании и архитектура процессов управления может быть разной. При неоптимальном распределении ответственности и зонах управления по этой архитектуре будут возникать "потери": либо куски, за которые никто не отвечает, либо куски, за которые отвечают сразу несколько. Любая живая система, к которой относится и организация, состоит из отдельных частей, между которым происходит коммуникация: обмен сигналами, анализ состояния, принятие решений о действиях и т.д.

Что происходит, когда за частями этой системы никто не отвечает или отвечают сразу несколько? Это приводит к тотальному увеличению количества коммуникаций между друг другом. Когда вам нужно провести 10 совещаний с 50 людьми, чтобы только договориться. Т.е. в потоке ваших коммуникаций "эффективной" информации, которая призвана для того, чтобы весь механизм работал, минимум. А вот "синхронизационной" информации - максимум. Именно по этой причине у большинства продактов основная рабочая деятельность это встречи и общение, что и показывает исследование.

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

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

Ну да, ну да. Проще сказать, чем сделать.

Ceterum censeo Carthaginem esse delendam. Открыть/Комментировать

2023-01-27 14:30:00 Упрощенную схему ключевых объектов управления в product management можно посмотреть здесь. А вот полную я добавил на страницу карты навыков в Miro.

Такая карта позволяет не только проанализировать, за что именно отвечают менеджеры при текущих процессах и где находятся "лаги", т.е. куски, за которые никто не отвечает, но и понять, каким образом можно перестроить схему управления, разделить зоны ответственности между разными ролями в компании и подобрать соответствующие навыки для менеджеров.

Объект управления - это некоторый объект компании (например, продукт, схема монетизации, каналы привлечения и т.д.), чьем состоянием должен управлять менеджер (не обязательно с ролью product). Ключевая задача управления - это перевод объекта из текущего состояния в целевое. Цели, по сути, это комбинации целевых состояний одного или нескольких объектов управления.

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

Такая же история и с грейдами. Можно сколько угодно называться middle product manager или senior product manager, но важно понимать, каким образом это отображается на тех объектах управления, за которые вы отвечаете? Меняются ли они? Или меняется их "размер"? Или вместо одного продукта вы теперь управляете несколькими? Все это открытые вопросы, на которые каждая из компаний должна отвечать самостоятельно, ведь их схемы управления и архитектура бизнеса и продуктов отличаются друг от друга. Senior в Авито и Senior в Контуре - это два разных сеньора.

Развитие менеджера продуктов в такой логике может реализовываться в нескольких направлениях:
* увеличение проектов работы с тем же объектом управления;
* работа с тем объектом управления, но большим значением его свойств (работали над продуктом в небольшой компании, а потом перешли в Яндекс с огромной аудиторией);
* переход от "меньшего" объекта управления к "большему", например, feature → вертикаль → продукт → портфель продуктов → бизнес-модель → бизнес-юнит. Или, часть воронки → воронка → система дистрибуции и продаж → бизнес-модель → бизнес-юнит. Открыть/Комментировать