Юки Ямашита был пользователем 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) и не позволяем идеальному быть врагом хорошего.

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

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

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

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

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

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

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

Шёпот vs Высказывания

Высказывания — это не вызов коллегам, а проверка идей на прочность. Альтернатива – тихий шёпот в коридоре.

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

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

Это означает задавать сложные вопросы не для того, чтобы бросить вызов коллегам, а чтобы искать с ними Истины

И лучшие продакты/СРО/СЕО не просто допускают это – они требуют этого, потому что понимают, что лучшие идеи возникают в результате конструктивного внутреннего конфликта внутри команды.

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

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

P.S. Если бы воду можно было заряжать шёпотом, то вода офисного кулера вызывала бы рак (с)

SaaS Billing Report 2025

ChartMogul выпустили исследование рынка месячных и годовых подписок 2,500+ SaaS продуктов.

Полезное-интересное:

– Годовые подписки обеспечивают более высокое удержание и среднюю выручку. Ваш КО.

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

– По мере эволюции, средняя компания переходит с месячных планов на годовые, а потом... обратно на месячные.

– Эффективнее всего продавать подписку в Q1, сложнее в Q4.

– Скидки непопулярны. Всего 5-8% SaaS-продуктов дают их на месячные планы и 8-15% на годовые.

Исследование: https://chartmogul.com/reports/saas-billing-report/

Главная опасность ИИ – посредственные результаты люди

Потому что самое сложное в работе с ИИ — курировать, адаптировать и объединять полученные от неё результаты. Пока что, это до сих пор делает человек.

И в чём опасность?

Опасность в том, что большинство людей довольствуется средним

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

И если операторы ИИ не будут достаточно требовательны к:

а) постановке качественных вопросов;
б) получению качественных ответов;

то ИИ далее будет определять то снижающееся среднее, как приемлемое и подходящее для нас и для самой себя.

То, что мы создаём, говорит о том, кто мы есть

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

Уже больше не имеет значения, создано что-то с ИИ или нет.

Важно то, почему мы принимаем те или иные результаты работы ИИ.

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

Не онбординг, а адаптация 🕳️👨‍🦯

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

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

Но этот подход:

– не учитывает многогранность продукта;
– не учитывает постоянные обновления функционала;
– не учитывает различные сценарии его использования;
– не учитывает разный уровень образованности пользователей;

Поэтому такой онбординг не помогает адаптации пользователей.

5 шагов для правильной адаптации

Рассматривайте адаптацию как непрерывный, интеллектуальный и эмоциональный процесс, а не как однократное обучение

0. Прогрессивная адаптация

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

Это достигается многоуровневой системой функционала + принципом"периферийного зрения" в UI, где каждый новый слой фич находится и открывается постепенно и в подходящее для пользователя время-месте в его CJM.

1. Персонализированная адаптация

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

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

Всё это легко настраивается через систему гибких контекстных подсказок и символов (?) рядом с элементами, которые выглядят максимально органично и точно в то самое время-место, когда это: а) требуется пользователю; б) он готов к усвоению такой информации.

2) Социальная адаптация

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

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

3) Эмпатичная адаптация

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

И пусть ваш дизайнер создаст уже наконец уникальную(!) дизайн-систему (да, на базе shadcn), которая учитывает:

1) особенности вашего продукта и его логики/архитектуры (см. пункт №0);

2) психологические особенности восприятия информации вашей аудиторией;

сделав каждое взаимодействие: 1) своевременным → 2) уместным → 3) а значит, интуитивно понятным для пользователя.

4) Циклическая адаптация

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

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

Ну, либо и дальше используйте "1-2-3-Х-Понятно-Закрыть", но не удивляйтесь потом, почему пользователи закрывают ваш продукт.

5 фреймворков по промпт-инжинирингу любой темы