Сломанный телефон звонит не только в понедельник

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

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

– ...Обсуди с X / Согласуй с Y / Окни у Z...
– ...Ок / Хорошо / Принято...

Но и это даже не самое главное.

Самое главное – в любом сломанном телефоне теряется Суть, Ценность и их Создатель.

И размазав такие тасочки/сообщения к обеду по новым ответственным, мы выдыхаем, называя это гордым словом "де-ле-гиро-вание".

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

Что самое интересное – мы пытаемся "делегировать" их не сколько на плечи XYZ, а... на плечи времени.

Время работает для иного

Но с каждым понедельником всё больше идей, вопросов, и задач "делегируются" на XYZ...∞, теряя свой импульс и пропадая во времени, из которого мы, снова, спустя время, пытаемся урывками вспоминать и доставать ту самую Суть, Ценность, и ища их Создателей.

Ценной недели!

🕥🫖

Причина №1 неудач продуктов – пользователи понимают, что продукты не предоставляют им достаточно ценности.

Причина №0 неудач продуктов – продакт-менеджеры не понимают, что на самом деле для пользователей означает Ценность.

Уравнение ценности Хормози (Hormozi's Value Equation) — это концепция, которая помогает всем понять, как создавать исключительную ценность для пользователей и строить востребованный продукт.

Ценность = [Мечта × Вероятность] ÷ [Время × Усилия × Стоимость]

💭 Мечта. Как ваш продукт помогает пользователям достичь своих реальных желаний?

– Укажите результат, который пользователи хотят получить.
– Будьте абсолютно конкретны в формулировках.
– Используйте яркий и эмоциональный язык.

Пример: «Улучши своё здоровье сам»

🏆 Воспринимаемая вероятность достижения мечты. Воспринимаемая — ключевое слово.

– Продемонстрируйте сильную экспертизу.
– Поделитесь историями успеха.
– Выделите отзывы и рекомендации.

Пример: «Это приложение изменило моё здоровье и жизнь»

⏱️ Задержка по времени. То, как можно сократить время до получения ценности.

– Давайте мгновенную ценность на старте.
– Используйте поэтапнное вовлечение.
– Отображайте и напоминайте о прогрессе.

🤕 Усилия и стоимость. То, как сделать так, чтобы продукт казался суперпростым и доступным.

– Минимизируйте болевые точки в CJM.
– Предлагайте гарантии и сервис.
– Публично работайте с лояльностью.

Пример: «Мы автоматически предоставляем месяц бесплатного доступа. No credit card required»

↑ Максимизируйте мечту.
↑ Максимизируйте вероятность успеха.

↓ Минимизируйте время достижения успеха.
↓ Минимизируйте усилия и стоимость.

The only product management framework that actually works

Кошмарный велосипед

...На мой взгляд, самая важная идея в дизайне продуктов — избегать «кошмарного велосипеда».

Представьте себе гипотетический велосипед, при проектировании которого менеджер по продукту сказал:

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

И это было бы ужасно! Ведь пользователи потеряли бы интуитивное понимание того, как использовать передачи для решения любой ситуации, с которой они сталкиваются: какой режим использовать для спуска по гравию? А при подъёме? А на пустой уличной дороге?

Любой может понять пронумерованные передачи после небольшой практики. И люди способны на это!

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

На самом деле нет.

У неё может быть только кнопка с таймером времени, а люди сами разберутся, как им готовить.

Хорошие продукты раскрывают систематическую структуру

И они опираются на способность своих пользователей понимать и применять эту структуру в новых ситуациях.

Мы были рождены для этого.

Плохие продукты теряют свою структуру за поверхностными ярлыками и кнопками, которые скрывают за собой базовую систему, препятствуя способности пользователей строить чёткие модели и образы в своём сознании...

Andrea diSessa, Changing Minds (с)

Юки Ямашита был пользователем Figma, а потом стал её CPO

«Я пошел в Figma не потому, что думал, что это будет большой бизнес, а потому, что они создавали волшебный инструмент, который мне очень понравился».

В эксклюзивном интервью Ямашита рассказывает о своём трехэтапном подходе к созданию и запуску новых продуктов.

Сочное:

– Cмотрите, как пользователи взламывают ваш основной продукт.

– Лучшие продукты появляются в результате небольшого внутреннего конфликта, когда одна часть команды отстаивает вариант его использования таким образом, который противоречит интуитивному пониманию его использования другой частью команды.

– Чтобы создавать новые продукты на базе старых, необходимо создать новую среду. Не бойтесь привлекать сторонних специалистов для более глубокого понимания новых пользователей.

– Путь продукта от 1 до 10 — это постоянный балансирующий акт создания новых вариантов использования продукта при сохранении его простоты, поэтому не идите на компромиссы с простотой.

Чем больше вы создаёте расхождений, тем сложнее будет объединить их позже

– Пользователи не наблюдают эволюции — они приходят без контекста.

Недавно я наблюдал, как третьеклассники в Японии используют Figma. И если вам приходится много объяснять, что именно происходит в продукте, то это верный признак того, что вы недостаточно упростили ценностное предложение.

🧃 https://review.firstround.com/lessons-in-product-scaling-and-storytelling-from-figmas-cpo/

Один день Joan Westenberg продакт-менеджера

Самая большая ложь в управлении продуктом – необходимость освоить всё, сразу и как можно быстрее. И этот подход убивает.

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

Настоящие решения, которые мы ищем, почти всегда прячутся на виду.

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

Какую ОДНУ вещь я могу сделать, чтобы всё остальное стало проще или ненужно?

Не «какую структуру мне следует изучить?»
Не «какой инструмент мне следует освоить?»
Не «как мне угодить всем?»

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

Вот почему большинство менеджеров продуктов в конечном итоге становятся менеджерами проектов, а не создателями Ценностей.

Ещё одна суровая правда для менеджеров продуктов:

Когда вы стремитесь к величию, хаос обязательно появится

Ваша задача не в том, чтобы предотвращать хаос. Ваша задача — примириться с ним, оставаясь сосредоточенным на самом важном.

Для продакт-менеджера это означает – не начинать с процессов. Начинайте с результатов.

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

Какая ОДНА вещь сделает большинство ваших текущих задач ненужными?

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

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

Ваша задача – найти свою ОДНУ вещь.
Выделить для неё время.
Всё остальное будет хаосом.

"The ONE Thing" by Gary Keller

Понедельник – день влияния

Несмотря на всё давление понедельников, когда в один день умещается целая рабочая неделя, именно в понедельник можно (нужно?) прикладывать свои усилия, чтобы влиять на правильные вещи.

Потому что:

–  в понедельник все вокруг "по общему умолчанию" открыты и настроены к любой новой информации больше чем когда-либо на неделе;

–  в понедельник важную информацию никто не смеет открыто игнорировать;

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

Ведь это понедельник

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

Продуктивной недели!

⚡️🫖

MCP простыми словами и почему это круто для ИИ

MCP (Multi-Agent Communication Protocol) или "Протокол коммуникации между агентами" – это стандарт с открытым исходным кодом от Anthropic, который позволяет моделям ИИ подключаться к базам данных, API сервисов, файловым системам и другим инструментам без необходимости написания специального кода для каждой новой интеграции.

Простыми словами, MCP - это API для API, или "язык", на котором разные ИИ-системы могут "разговаривать" между собой. Он определяет формат сообщений, способы обмена информацией и правила взаимодействия между ними.

Как работает MCP:

1. Хост (ИИ-модели и клиенты) запускает MCP Client.
2. MCP Client, компонент внутри модели ИИ, который позволяет ей взаимодействовать с серверами MCP, запрашивает информацию или действие у MCP сервера.
2. MCP сервер извлекает их из источников (базы данных или API) и передает ИИ.
3. Далее, ИИ модели используют эту информацию при обработке ответа и передают обратно MCP.

MCP состоит из 5 основных строительных блоков (также известных как примитивы), которые разделены между клиентом и сервером:

– Для клиентов строительными блоками являются Roots (безопасный доступ к файлам) и Sampling (запрос ИИ на генерацию запроса к БД).

– Для серверов существуют Prompts (инструкции для ИИ), Resources (объекты данных, на которые может ссылаться ИИ) и Tools (функции, которые может вызывать ИИ, например, выполнение запроса к БД).

🤖 https://github.com/modelcontextprotocol

MCP для продакт-менеджера простыми словами:

– Вы начинаете работать над фичей. Любая фича реализуется на основе родмэпа, фидбека, PRD, аналитики, дизайна и текущего кода.

– У вас есть MCP сервера, которые извлекают родмэп и PRD из Jira, фидбек из сапорт-тикетов, аналитику из GA/Mixpanel, дизайн-систему из Figma, код из репы в Github, переписки из Slack.

– Всё это через MCP систематически и на постоянной основе скармливается в ИИ, где ИИ распознаёт и обрабатывает всю получаемую информацию.

Каждое действие прозрачно и вы как ИИ-менеджер можете видеть/изменять/дополнять любой из этапов-источников данных.

– А можете этого и не делать (шутка?) – MCP сервер/ИИ-агент может самостоятельно инциировать такие вопросы-уточнения в Jira/Slack/где угодно у авторов родмэпа, фидбека, PRD, дизайна и текущего кода.

– Далее, MCP работает с ИИ в обратную сторону и управляет тем, что:

1) Jira через себя, GA/mixpanel, тикеты, Slack обогащает в себе PRD, формируя и приоритизируя новый родмэп/фичи глазами ИИ;

2) Figma на основе PRD и дизайн-системы (shadcn всех съел) рисует версии дизайнОВ;

3) v0 или Github Copliot на основе PRD и дизайна трансформирует всё в код, катит на дев и сам же его там тестит либо сообщает команде, что пора тестить фичу, и после снова собрает фидбек, баги, откатывает релизы, обогащает PRD, переписывает код и снова катит апдейты.

4) МСР также катит релизы в прод на мелкие сегменты и на основе своих же А/B определяет, какая фича зашла, а какая нет.

Ошибка на любом из этапов? ИИ через MCP увидит её где угодно, от источника и кода, до ошибок в браузере и может снова инициировать их обсуждения в Slack/где угодно, собирая данные и прогоняя цикл по новому кругу.

Всё это автоматизированно, модифицируемо, вариативно, версионно, повторяемо и под управлением ИИ и пока ещё продакт-менеджера.

Сбывается "мечта" всех продактов – успешные релизы по пятницам скоро станут реальностью!

Амазон планирует сократить 14,000 менеджерских позиций в 2025, что позволит компании ежегодно экономить зарабатывать $3,6 млрд.

Amazon told Business Insider that it had "added a lot of managers" in recent years and that "now is the right time" to make this change.

"Removing layers, operating with fewer managers and flattening the organization are all in focus to move faster," it said in the note.

🎻🫡

18 шуток метрик: метрики не шутят шутки

– Искусственное "выравнивание" метрик по неделям/месяцам может скрывать критически важные изменения в поведении пользователей внутри дня.

– Среднее время/MAU/DAU могут не отражать вовлечённость. А высокое время, проведённое в продукте, может указывать на плохой UX и сложности в UI.

– "Ловушка пикового использования" создаётся, когда продукт оптимизируется под пиковые сценарии использования, которые составляют менее 1% всех сессий, но непропорционально влияют на восприятие и концентрацию на этом сценарии командой продукта.

– "Эффект красной кнопки" (искусственного роста) возникает за счёт чрезмерно привлекательных элементов интерфейса (яркие кнопки, элементы, агрессивные PUSH), показывая положительный краткосрочный результат, но негативный в долгосрочной перспективе.

– "Эффект новизны" фичи может искажать метрики активации и удержания из-за любопытства пользователей, что приводит к переоценке их ценности. Стабилизация метрик приходит через 4-8 недель.

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

– "Эффект забытого сегмента" происходит с фокусом на метриках доминирующего сегмента пользователей и приводит к игнорированию проблем/потребностей других сегментов.

– "Парадокс полноты данных" проявляется, когда улучшение систем сбора аналитики приводит к кажущемуся ухудшению метрик, хотя на самом деле просто выявляются ранее невидимые проблемы.

– "Эффект перекоса метрик" происходит, когда A/B-тестирования автоматически останавливают тесты при первом достижении статистической значимости, что приводит к систематической переоценке эффекта изменений.

– "Парадокс геймификации" вызвает ещё один перекос в активности и вовлеченности пока пользователи "играют" с новой системой вознаграждений.

– "Парадокс продвинутых пользователей" проявляется, когда лояльные пользователи с высокой вовлеченностью демонстрируют негативную динамику метрик из-за выгорания или достижения естественного предела использования продукта.

– "Иллюзия лояльности" возникает, когда высокие показатели возврата пользователей обусловлены не ценностью продукта, а искусственными мотиваторами (бонусами/скидками, бесплатным контентом/фичами). Снижайте интенсивности мотиваторов, чтобы оценить реальную привязанность к продукту.

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

– "Синдром универсальной метрики" возникает при попытке найти единую метрику, идеально отражающую здоровье продукта, что приводит к игнорированию многомерности пользовательского опыта.

– "Иллюзия прогресса метрик" создаётся, когда последовательные улучшения отдельных микрометрик не трансформируются в улучшение макрорезультатов из-за наличия проблем в CJM.

– "Эффект продуктовой близорукости" проявляется, когда команда интерпретирует метрики исключительно через призму собственного продукта, игнорируя многоканальность пользовательского опыта, контекст и экосистему рынка.

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

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

Когда метрика становится целью, она перестаёт быть хорошей метрикой – закон Гудхарта

Отрасль IT с каждым днём всё больше выглядит как одна большая злая шутка:

"Стратегия всем понятна?". "Красивая преза!"

"Пользователям нужны новые фичи!". А что со старыми?

"Спринты запланировали!". Предсказуемые "итоги".

Метрики (не)растут? Это просто мы так считали.

Подписки отменяются? А на что подписывались...

Команда не понимает? "А что тут понимать?".

Конкуренты копируют? Скопируем у конкурентов.

Созвоны бесмысленны? Звонки идут по кругу.

Подташнивает в Linkedin? Там всех укачивает.

Коллеги "выгорают"? В котельной попрохладнее.

Коллеги "мотивированы"? Все боятся сокращений.

Бюджеты/коллег сократили? Это "оптимизация".

Бонусы отменили? А за что их раздавали?

Руководство не слышит? Оно и не слушало.

Инвесторы недовольны? Они верят в другие сказки.

Создание будущего через настоящее прошлое – не сказка.

Лучшее, что мы можем сделать – пытаться строить то, что создаёт некоторую Ценность для других и относиться к этому с мудростью, добротой и юмором. Главное – не менять их местами.

Оцениваем интуицию и инстинкты продакта на этапе интервью, а не спустя полгода просиживания штанов в родмэпе

+ собираем свежие инсайты, мысли и взгляды о своём продукте со стороны.

От простых к сложным:

– С какими проблемами наш продукт столкнётся в ближайший год, два года, десять лет? Что поможет их преодолению?

– Какие тренды на рынке вы лично считаете переоценёнными, а какие недооценёнными?

– Как вы решаете, что что-то НЕ нужно создавать/делать, когда для этого не хватает данных?

– Как вы ощущаете ценность идеи/механики/фичи и их потенциальное изменение до того, как они отразятся в метриках после релиза?

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

– Как вы наблюдаете за пользователями без метрик и аналитики?

– Опишите момент, когда вы интуитивно поняли, что фича будет/не будет работать, хотя все данные говорили об обратном.

– Был ли у вас момент, когда вы поняли, что нужно радикально изменять направление развития продукта. Как вы это ощутили? Как вы поступили далее?

– Вы когда-либо шли против данных/мнения команды, доверившись своей интуиции? Как вы управляли этой ситуацией?

– Если бы у вас была полная свобода действий и неограниченные ресурсы, что бы вы делали в продукте? А для команды?

– Если бы вы могли дать один совет начинающему продакт-менеджеру о развитии продуктовой интуиции, что бы вы посоветовали?

– Насколько вы считаете себя креативным?

Программа пятницы:

Понедельник – тихий день

Тишина в команде бывает трёх звучаний:

– Давящая, когда команда молчит и "работает" вместо того, чтобы говорить.

– Осознанная, когда команда работает молча, потому что всё уже сказано.

– Звенящая, когда команда работает над важным, научившись говорить молча.

Звук тишины совпадает с фокусом внимания команды.

Тихого понедельника и недели!

🌊🍵

Большинство работ в продуктах проходят одинаково:

1) ищем быстрее;
2) пилим быстрее;
3) быстрее доставляем;
0) и не позволяем идеальному быть врагом хорошего.

Многие продакты живут с этой мантрой годами.

И гибкая разработка ПО "прощаёт всё": тесты, новая версия, новый релиз – готово!

С физическими продуктами всё иначе.

Неправильно спроектированное здание никогда не будет достроено; ошибочная конфигурация кабелей приведёт к выведенному из строю оборудованию; неточность в книге приведёт к браку тиража. Каждая ошибка на вес золота и его времени.

Теперь ИИ создаёт продукты за считанные секунды и каждый может творить без особых усилий. Но машины не запрограммированы тратить месяцы на совершенствование логики пользователя и продукта.

Машины не могут воспроизвести человеческую одержимость, которая делает продукты Великими

Творить Великое – проявлять неустанное внимание к деталям, подвергая их сомнениям и вносить тысячи микрокорректировок до тех пор, пока идеальный опыт не станет тем самым великим преимуществом.