Наглядная схема как связать Business Strategy, Product Strategy, Product Discovery и Product Delivery в шаблоне Miro

И всё же, понедельник – день Огня

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

Баланса в пламени недели!

Угадай профессию с одной попытки

A/B лукавят.
Stories – чушь.
Чуйка подводит.
Разум ошибочен.
Сроки – вымысел.
Эйчары не нужны.
Фидбек – коварен.
MVP – не минимум.
Касдев – размытие.
Процессы – сложно.
Родмэпы – старость.
Ретро не из будущего.
Данные – манипуляции.
JTBD не то, чем кажется.
Культура есть стратегию.
Стратегия – не навигация.
Команда может тормозить.
Стейкхолдеры меняют виды.
Инновации не в расписаниях.
Приоритеты – есть самообман.
Лояльность – временное св-во?

Эмоции клиентов – вот что Суть

Советы по проведению качественного исследования

0. Помни о главном – цели исследования.

Цель исследования – ответ на поставленный в его начале вопрос.

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

1. Определи как и откуда идёт сбор данных

– Источники: чужие данные (вымышленные либо реальные), собственные метрики, опросы, интервью, эксперименты или наблюдения;
– процесс отбора данных (сегменты, пре-фильтрация данных);
– период + периодичность сбора данных (время).

2. Понимай, как ты анализируешь данные

– Как и чем получаемые данные помогают найти ответ на исследовательский вопрос? Насколько они целостные?

– Придерживайся своих же правил и критериев для отсеивания (не)релевантных данных. Исключительные по своей сути данные не должны попадать в отсеивающий фильтр, а сохраняться отдельно.

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

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

Активнее всего ищи данные, которые могут ОПРОВЕРГНУТЬ твои гипотезы

3. Отделяй наблюдения от интерпретаций. Наблюдения – "факты?". Интерпретации – "варианты?".

4. Осознавай ограничения исследования (искусственные и органические): небольшой сегмент пользователей, недостоверный источник данных, сезонность или даже неправильно сформулированный в начале вопрос накладывают отпечаток на применимость таких данных в условиях продукта/рынка.

5. Проверяй сделанные выводы. Через взаимный аудит, через параллельные исследования (продакт + product designer + маркетинг), через те же A/B (главное, не наоборот).

6. Делай результаты исследования понятными для всех участников команды. Информируй стейкхолдеров/руководителей по результатам любых исследований – для них эти данные тоже должны стать пищей для размышлений.

Microsoft вчера анонсировала поддержку MCP в Windows и пару интересных ИИ-инструментов:

1. Операционки Windows теперь работают с MCP и обеспечивают доступ ИИ-агентов к файловой системе и другим службам(!).

2. Windows AI Foundry Local SDK — набор инструментов, встроенных в Windows, которые упрощают локальный запуск и интеграцию моделей ИИ на ПК.

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

3. NLWeb — это бесплатный инструмент от Microsoft, который позволяет любому пользователю общаться с вашим веб-сайтом по аналогии как с виджетом онлайн-консультанта.

NLWeb берёт информацию, которую сайт уже публикует в стандартных форматах (например, Schema или RSS), и превращает её в простой запрос для ИИ.

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

Microsoft CTO Кевин Скотт сравнивает MCP с HTTP

Качества выдающегося продакт-менеджера

1. Баланс продакта с его продуктом в тактико-стратегии. Связывай монотонную ежедневную работу с долгосрочными целями компании. И время начнёт идти по-другому.

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

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

4. Улучшенная старая фича лучше новых двух (сворованных).

Лучший способ улучшить продукт — это убирать функции, а не добавлять их. (с) Будда

5. Задавай неудобные вопросы, которые заставляют(!) команду пересматривать свои убеждения.

Пример для новых фич: «А что случится, если мы её не сделаем?».

6. Поощряй в команде идеи, которые сначала кажутся сложным/невозможными/невыполнимыми и ставят под сомнение даже фундаментальные убеждения, на которых строится продукт.

Именно фундаментальные убеждения стареют первыми на рынке

7. Осознанно НЕ давай команде всех ответов, чтобы стимулировать самостоятельное мышление и поиски решений, позволяя команде входить в состояния творческой неопределённости.

8. Развивай не только сам продукт, но и процесс его создания. Умышленно создавайте искусственные ограничения и неопределённости, чтобы в их условиях стимулировать творческую разработку нестандартных (самых простых) решений.

9. И снова балансируй между новыми и существующими фичами.

0. Смотри на всё глазами пользователей

5 уровней ИИ-агентов от простых к сложным

ИИ-агент это не просто дополнение к промптам в духе "You are senior product manager" или "ты в роли Стива Джобса". ИИ-агенты это логическое продолжение (начало?) самой ИИ, работающее как интеллектуальный интерфейс между машиной и человеком.

Level 1: ИИ-агент с инструментами и инструкциями

Инструкции «учат» агента, как выполнять запрос, а инструменты позволяют агентам взаимодействовать с внешними средами для передачи или извлечения данных.

Это начальный базовый уровень работы с ИИ и когда коллега говорит, что ИИ-агенты — "это просто вызовы LLM + доп. инструменты", это говорит лишь об уровне его понимания ИИ.

Level 2: Агент со знаниями и хранилищем

ИИ редко имеет всю необходимую информацию для выполнения задачи + мы не можем запихнуть весь контекст в запрос, поэтому мы даём агенту знания, которые он ищет во время выполнения (Agentic RAG или Dynamic few-shot).

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

Хранилище сохраняет состояние ИИ-агента в базе данных. Простые вызовы LLM первого уровня не имеют «состояния», в то время как хранилище даёт ИИ-агентам свойство «состояние», сохраняя сообщения в базе данных и используя их при подготовке других ответов по мере необходимости.

Если вы используете chatgpt, хранилище — это то, что сохраняет состояние сеанса и позволяет нам продолжать чат после закрытия вкладки, а каждая ветка чата, которую вы видите на левой панели навигации, является «сеансом» в такое хранилище.

Level 3: ИИ-агент с памятью и рассуждениями

Память позволяет ИИ-агенту запоминать сведения о пользователе и персонализировать свои ответы в сеансах.

Рассуждения — ещё ключевая функция, которую нужно использовать в работе с ИИ. Но большая проблема с ИИ-агентами заключается в том, что показатель успешности агента уменьшается с числом шагов, которые должен выполнить агент.

Например: если показатель успешности 1 шага составляет 90%, средний показатель успешности агента, которому необходимо выполнить 5 шагов, составляет ~60%. Это не оч хорошо.

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

Level 4: Команды из нескольких ИИ-агентов

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

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

Level 5: Агентские ИИ-Системы

Агентские системы – следующий этап трансформации команд из ИИ-агентов. И это уже сложно: сервера и среды, MCP, API, БД с хранилищами знаний, рассуждений и состояний, асинхронные задачи, очереди задач, передача результатов по мере их готовности, вебсокеты, рожьэтовсё...

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

Но самое интересное в этом то, кто эволюционирует, а кто трансформируется – человек или ИИ?

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

И тот же Zapier недавно выкатил масштабное обновление MCP 2.0, которое открывает вашему ИИ-приложению/ИИ-агентам/пользователям доступ к 7,000 апп и более чем 30,000 действий через OAuth, которые можно расширять ещё больше с ИИ.

– Получили тикет по почте? ИИ завёл его и подготовил ответы в Notion (или уже ответил пользователю где ему удобно).

– Синкнуть данные фитнес-приложений и получать ИИ-рекомендации раз в неделю? Ок.

– В 500 м от дома? Вслед за умными лампочками красного света включается умный чайник и набирается горячая вода для ванны, а ИИ отвечает за последовательность.

– Чего у них там только нет.

Zapier успешно эволюционировав в новую эпоху Интернета и поэтому теперь позиционируется как "The most connected AI orchestration platform".

Жёсткая правда: то, что запрашивают ваши пользователи, редко является тем, что им действительно нужно (с)

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

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

И большинство продактов следуют этому НЕПРАВИЛЬНОМУ процессу:

1) давайте соберём отзывы;
2) сгруппируем похожие запросы;
3) расставим приоритеты по частоте;
4) внедрим самые популярные запросы.

Этот подход кажется ориентированным на данные, но на самом деле создает раздутые, запутанные продукты, которые решают поверхностные проблемы.

Потому что, когда пользователи говорят «добавьте панель управления для X», они на самом деле они просто говорят «Мне сложно понять X».

В тот момент, когда вы начинаете реализовывать запросы функций буквально, вы перестаёте быть менеджером по продукту и становитесь приёмщиком заказов.

Решение – метод извлечения сигнала.

Вместо того, чтобы воспринимать обратную связь буквально, извлеките базовый сигнал, используя 3-частную структуру:

1. Контекст.
2. Триггеры.
3. Желаемые результаты.

Контекст

Никогда не оценивайте обратную связь изолированно. Всегда спрашивайте:

«Над чем вы работали, когда вам это было нужно?»
«Где это вписывается в ваш процесс?»
«Как часто возникает эта ситуация?»

Это раскрывает фактический рабочий процесс, а не просто запрос новой функции.

Триггеры

Для каждого фрагмента обратной связи определите:

«Какое конкретное событие заставило вас задуматься об этом решении?»
«Чего вы пытались достичь, когда столкнулись с этой проблемой?»
«Какие обходные пути вы использовали?»

Желаемые результаты

Волшебный вопрос, который меняет всё:

«Если бы у вас была эта функция, что бы изменилось в вашей работе/жизни?»

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

Но большинство продактов буксуют на фразе:

«Но мои заинтересованные стороны хотят, чтобы мы были ориентированы на клиентов!»

Ответ, который изменит всё:

«Мы решаем основную потребность, стоящую за этими запросами. Вот три решения, которые решают эту проблему более эффективно».

Если они и дальше игнорируют качественную обратную связь:

«Мы выявили закономерность в 12 разговорах с клиентами. Этот сигнал сопоставляется с падением на 9% в воронке конверсии на шаге 3. Вот гипотеза, которую мы должны проверить».

Обратите внимание, как связывается боль пользователя с метриками.

TLDR:

– 5-7 глубоких бесед с клиентами достаточно;
– клиент выступает советчиком;
– поиск паттерна поведения;
– триангуляция отзывов с данными об использовании;
– сегментация отзывов по ценности для клиента;
– поиск решения для результата, а не запроса.

Решайте проблемы, а не функции.

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

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