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

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".

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

У OTUS есть подписка на обучение, причём доступ сразу к трём разным курсам. Любым. Хочешь управление продуктом, аналитику данных и системный анализ параллельно? Без проблем. Через месяц сменить стек? Легко!

Что внутри:

— 200+ курсов по аналитике, менеджменту, маркетингу и не только;
— возможность учиться в своём ритме;
— консультации с экспертами.

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

Посмотреть, как это работает 👀

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

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

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

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

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

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

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

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

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

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

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

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

Контекст

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

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

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

Триггеры

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

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

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

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

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

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

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

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

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

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

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

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

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

TLDR:

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

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

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

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

product manager preparing to write a PRD no one will read

11 хард-скиллов продакт-менеджера God Mode:

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

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

– Наблюдение, отслеживание и контроль жизни фич во времени.

– Умение проводить собеседование с любым специалистом человеком.

– Умение работать с командами с разными навыками и опытом. Эмоциональная регуляция команды.

– Скорость обучения. Стратегическое терпение.

– Умение получать релевантные данные с рынка не только из первых рук.

– Поведенческая экономика. Ecosystem thinking.

– Конфигурации аналитических систем.

– Интуиция относительно того, что важно.

– Влияние без полномочий (заслуживать доверие через данные и убедительные доводы). И интуиция по людям.

В целом, дело даже НЕ в «хард-скиллах», а в том, насколько чётко ты понимаешь, в каком хаосе чём ты умеешь хорошо ориентироваться.

Понедельник — день отличий

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

И интересное в нём то, что отличительность — это практически отличность.

Отличной недели!

11 советов как продакт-менеджеру заранее предотвращать срывы сроков разработки (и что делать, если они срываются)

0. Всегда умножай оценки сроков х2-3. А при коммуникации со стейкхолдерами давай диапазоны вместо точных дат.

1. Не критикуй разрабов за пессимистичные прогнозы разработки – пусть лучше они честно скажут, что это займёт месяц, чем под давлением пообещают 2 недели и завалят всё на 2 месяца.

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

3. Декомпозируй задачи до уровня обнаружения в ней любых возможных блоков через 2-3 дня её разработки.

Если задачу нельзя разбить до такого уровня, значит задача недостаточно тобой детализированна.

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

Выделяй сеньоров на критический путь + всегда имей прозапас запасного участника такого уровня для критической части.

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

6. Требуй тех. задание от лид-инженера перед началом разработки.

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

Если лид не может написать ТЗ за 3 часа, значит задача УЖЕ недостаточно понятна для реализации

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

Вместо них можно ведите автоматизированный стендап в Slack с указанием % готовности задач и уведомлениями о превышении запланированных сроков и объяснением причин и новой оценкой времени со стороны тимлида.

Что делать, если сроки срываются?

8. Red Room – экстренный режим работы с ежедневными встречами всех ключевых участников для быстрого принятия решений и устранения блокеров.

Если Red Room длится более одной недели, значит проблема сроков разработки носит стратегический характер и требует структурных кадровых/культурных решений, а не разовых фиксов/припарок.

9. Урезание функционала это про чёткое понимание текущих приоритетов и их влияния на бизнес-цели, а не сокращение/навёрстывание сроков

Урезай фичу до версии, которая всё ещё решает основную пользовательскую проблему и приносит ценность юзерам/бизнесу

Урезанная версия идёт по 3 сценариям с чёткими критериями: время vs scope vs качество.

И если вы не можете убрать 30% скопа без потери основной ценности, значит изначальное решение было over-engineered.

Всегда документируй такие решения для избежания вопросов со стороны заинтересованных лиц (и конфликтов в будущем).

10. Перераспределение ресурсов с менее критичных задач и привлечение дополнительных разрабов работает только при наличии:

а) чёткой и описанной архитектуры;
б) возможностей для параллелизации задач;
в) разрабов с опытом в конкретной области/стэке;
г) наличии 1-2 недель на их онбординг.

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

11. Регулярные post-mortem после каждого релиза позволяют команде учиться на своих ошибках и повышать точность планирования. Если одни и те же проблемы повторяются в нескольких post-mortem, это снова про систематическую ошибку и кардинальные решения по её исправлению.

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

Почему разрабы мы все факапим сроки? Посвящается всем разрабам и продактам

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

– Требование → Инструкция → Решение
– Input → Output.
– Ошибка → Исправление.

Но продукты — это Системы, в которых есть Пользователи, Бизнес и Хаос.

И одержимость «параметрами» (функциями, спецификациями, архитектурой и культурой кода) считается самой слабой точкой влияния в любой Системе.

Самая сильная?
Ментальные модели и цели Системы.

Потому что продукт это не просто набор технически работающих фич. Это сложная Система, в которой:

– Каждая новая функция связана и влияет на существующие.

– Поведение пользователей создаёт цепочки общих циклов действий.

– И даже небольшие изменения могут иметь неожиданные последствия, создавая новые проблемы (Хаос).

И распространенная ошибка – поиск «первопричин проблем».

В Системах редко бывают первопричины.

Вместо этого есть структуры, которые создают Шаблоны поведения Систем и пользователей.

Более того, сами Системы обманывают нас, представляя себя как серию событий, на которые мы реагируем:

– Запросы фич от юзеров.
– Текущие ошибки в коде.
– Конкуренты/рыночек и всё такое.

Поэтому мы ошибочно фокусируем внимание на том, ЧТО и КАК строить, а не на понимании, ПОЧЕМУ Система ведёт себя так, а не иначе.

Это всего лишь со-бы-ти-я.

Настоящая сила продакта и разраба в том, чтобы видеть Шаблоны.

И наименее очевидная часть Системы, её функция и Цель, часто является наиболее важным фактором, определяющим само поведение Системы.

Наше мышление — не слабость. Это основа, потому что мы понимаем:

– Циклы обратной связи.
– Управление состояниями.
– Сложные зависимости.
– Системные ограничения.

Всё, что нам нужно – это применять их к Человеческим Системам, чаще задавая себе вопросы:

– Каковы скрытые Шаблоны?
– В чём задержки Системы?
– Какие ментальные модели определяют все решения?

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

Не начинайте с решений.
Не спешите с выводами.
Просто наблюдайте.

🤷‍♂️