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

Например: * Увеличить скорость выкатки ценности для потребителей за счет внедрения scrum. Time-to-market сокращен до 4 недель. * Снизить отток пользователей BI-продукта за счет добавления новых аналитических шаблонов. Retention rate 2 периода увеличился с 27% до 35%. Переток со старых на новые шаблоны не менее 60% пользователей базы. * Увеличить количество активаций, пришедших через VK за счет изменения плейсмента и внедрения новых офферов. Объем активаций увеличился до 2500. * Увеличить доходимость до конца курсов студентов за счет добавления тренажеров навыков. Конверсия в завершенный курс 70%. NPS 85%. Конечно же, это только одна из точек зрения на шаблон формулирования цели. Так как я вывожу её от объектов управления, то пусть она называется школой кибернетики. Шаблон решает одни задачи и не решает других.

Все эти ошибки возникают, когда менеджер на самом деле не представляет, чем именно он управляет. Менеджерам рассказали, что есть цели. Потом рассказали, что у целей есть критерии достижимости. Потом, что они должны измеряться. А вот что такое цели с точки зрения менеджмента менеджерам рассказать забыли. Давайте восстановим картину. Есть разные объекты управления: продукты, бизнес-модели, процессы, отделы сотрудников, проекты и т.д. у объектов есть свойства, у свойств есть значения. Конкретная связка свойств объекта и их значений, называется состоянием объекта. Так вот, ключевая задача управления - это перевод объекта из текущего состояния в целевое (изменение значений и/или свойств). Менеджмент - это про управление состоянием, а не раздачу задач сотрудникам. Целевое состояние не зря носит название целевого - оно и определяет цель. Исходя из такой логики, хорошая формулировка цели должна включать четыре элемента: 1) обозначение объекта управления 2) обозначение его свойства 3) обозначение целевого значения свойства 4) и то воздействие, которое должен осуществить менеджер, чтобы изменить текущее состояние до целевого Если добавить логику OKR, то Objective - это 1, 2 и 4 пункт, а key result - метрики, по которым мы поймём изменение 3 (перечитайте прошлый mondaily). При этом Objective формулируется по шаблону: "глагол" + "свойство объекиа управления" + за счёт + "воздействие".

#mondaily Формула цели от объекта управления В продолжение прошлого #mondaily хочу рассказать о шаблоне целеполагания, который строится от объекта управления и его свойств. Он использует логику разделения цели на Objective и Key Result, а потому может быть органично вписан в систему OKR. На прошлом Product Sense я проводил мастер-класс, где рассказывал об этой формуле и популярных проблемах при целеполагании, с которыми сталкивался при внедрении процесса целеполагании в продуктовых командах: 1) Непонятно, чем обоснована достижимость цели = отсутствие информации "за счёт чего". Например, увеличить число активаций через Facebook до 5000. 2) Замещение цели способом ее достижения. Например, найти оптимальный набор уведомлений для повышения вовлечённости потребителя. 3) Несовместимость Objective и Key Result. Например, Objective "Обеспечить потребителю потрясающий опыт", kr1 "повысить NPS c X до Y", kr2 "удерживать CAC не выше Y". 4) Сложно измерить результат / отсутствие KR. Например, "запустить процесс квартального целеполагания в нескольких командах". 5) Замещение KR конкретными задачами. Например, Objective "Подготовить стратегию выхода на рынок", kr1 "проанализировать конкурентов", kr2 "сделать swot-анализ", kr3 "провести глубинное интервью", kr4 "собрать всех в одной комнате", kr5 "собрать всех в другой комнате" и т.д. 6) Сложно оценить прогресс достижения цели. Например, Objective "узнать, кто является нашим сегментом, и научиться с ним работать", kr1 "узнать", kr2 "научиться". Все эти ошибки возникают, когда менеджер на самом деле не представляет, чем именно он управляет.

Всем привет! Меня зовут Алексей Шеин, я руковожу маркетингом в компании Документерра. Сейчас провожу исследование, чтобы понять отношение продактов к пользовательской документации: в какой момент они задумываются о её необходимости/качестве, с чем это связано. Как понимают и оценивают качество влияния документации на удовлетворённость юзеров. Продолжительность созвона: 30-60 минут. Записаться тут 👉 https://forms.yandex.ru/cloud/6629219c50569077add81e2d/ Всем прошедшим опрос, отправим небольшой подарок - фирменную футболку. 🎁

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

Однако, здравствуйте. В ряды продуктовых конференций прибыло. Организаторы конференции для аналитиков и маркетологов "Матемаркетинг" запустили продуктовое направление https://matemarketing.ru/aha Она пройдет 6 июня в Москве. Есть три секции: Product analytics, Product Ops и Business efficiency. Как и основная конференция, Aha фокусируется на data driven подходе и аналитике. Меня там тоже найдете - я расскажу о связке Product ops и метрик для оценки эффективности работы менеджера продукта. А ещё у конференции будет предварительная онлайн часть 30 мая, где выступит моя бывшая коллега Вика Пирогова, ныне CPO в OneCell. Она расскажет, с какими трудностями пришлось столкнуться при внедрении AI для диагностики онкозаболеваний на специально разработанном аппарате. Присоединяйтесь!

В первом случае менеджеры формулируют key result в виде конкретных метрик, но либо используют слишком верхнеуровневую вроде "прибыль", либо слишком низкоуровневую вроде "конверсия в начало user flow". Т.е. метрики тех объектов, которые находятся вне зоны их управления. В случае с дорожными картами фокус на метриках приводит к тому, что метрики меняются, а свойства объекта управления нет. То есть происходит некое "дотачивание" объекта вместо его изменения. На middle run это может привести в ловушку: вроде мы растем, вроде метрики меняются в лучшую сторону, но потом бац и конкуренция проиграна. Извините за аналогию, но у недавно умершего пациента температура будет как у живого. P.S. Когда-нибудь я буду успевать именно в понедельник.

#mondaily Замещение метриками смысла Мда, заголовок получился кликбейтным, но это потому что сложно формулировать просто. Я имею в виду не отрицание data driven подхода, а проблему замещения метриками того, что за ними стоит на самом деле. Метрики - это индикаторы состояния объекта управления или его отдельных свойств. Например, если объект управления это "бизнес-модель", у него есть свойство рентабельности, состояние которого определяется метриками ROI, NRV или LTV. Или свойство "воронка продаж", которое выражается не только числовыми метриками конверсии или скорости цикла, но ещё и нечисловой конфигурацией (набором этапов воронки). Метрика и свойство объекта - это разные сущности. И вот на этом этапе часто происходит сбой в голове менеджеров. Вместо того, чтобы оперировать уровнем объекта и свойств, они оперируют уровнем ниже - уровнем метрик. В их защиту стоит сказать, что это естественный способ экономии когнитивной энергии: проще работать с тем, что понятно, что измеримо, чем с абстрактными (на самом деле нет) свойствами. Особенно часто проблема замещения видна при формулировании целей или построении дорожной карты.

#mondaily Сравнение функций CPO и Продуктового Комитета Функции CPO, как и менеджер продукта, отличаются в зависимости от компании. Где-то он отвечает только за сотрудников, их развитие и процессы. Где-то - за показатели портфеля продуктов. Где-то он полностью владеет бизнес-юнитом и отвечает за экономические показатели. В общем, функции определяются объектами управления. Дополнительная сложность возникает, когда в компании одновременно с должностью CPO существует Продуктовый Комитет. Каким образом разделить ответственность между ними, чтобы не было пересечений, но при этом закрыты все зоны, подскажет табличка из вложения. Также, её можно использовать для подготовки job description для должности CPO. Интересное наблюдение. Как-то с Павлом Алферовым, профессором Школы управления Сколково, мы обсуждали специфику менеджмента российских компаний. Павел уже много лет внедряет собственную методологию проектного управления в корпорациях. Хорошо понимая психологию мышления руководителей, он подтвердил мои мысли, почему наравне с функцией CPO может существовать Продуктовый Комитет.  Первая причина рациональная - использование в качестве замены должности CPO, когда она временно или постоянно отсутствует в компании. Вторая причина - использование для координации нескольких CPO между собой в компаниях с несколькими большими бизнес-юнитами. А вот третья причина великолепна. Продуктовый Комитет существует вместе с функцией CPO просто потому, что руководство компании не готово делегировать ему полномочия. Не доверяет CPO или считает его недостаточно компетентным. При этом, не желая делегировать полномочия, не снимает с него ответственности :)

Короче. Ко мне есть три возражения. Что мало пишу в канал. Что если пишу, то слишком длинно. Что если пишу, то слишком сложно. Во-первых, извините, я тут играю роль профессора. Не видно что-ли. Во-вторых, всё правильно говорят. Поэтому я решил исправиться и запускаю рубрику #mondaily в формате Тёмной Стороны / Темнографики. По понедельникам я буду публиковать небольшие (по моим меркам) посты с полезными результатами моей методологической работы по теории управления продуктами или какими-то кейсами из консалтинговой практики. Чтобы соблюсти каденцию, мне даже пришлось сесть и составить контент-план на несколько недель вперед. Записано в синем блокнотике с надписью "make sense". Есть смысл, я считаю, иначе снова не выполню обещание. P.S. Первый пост опубликую сегодня как бы за вчера.