Защищайте продуктовые инициативы перед стейкхолдерами с правом вето на основе данных, а не мнений. Методология Марти Кагана из книги «Вдохновлённые» — теперь в формате диалоговых симуляций с ИИ-тренером.
«неважно, насколько хороши ваши разработчики, если они работают не над тем, что действительно стоит создавать»
Вдохновленные — это методология управления продуктами от основателя Silicon Valley Product Group Марти Кагана для проверки идей до начала разработки. Книга решает проблему создания невостребованного функционала и бесконечных согласований дорожной карты с руководством. На основе опыта работы в HP, Netscape и eBay автор разобрал 4 ключевых риска продукта, схемы интервью с пользователями и алгоритмы защиты целей перед стейкхолдерами.
Марти Каган — основатель Silicon Valley Product Group и автор книги «Вдохновлённые», продакт-менеджер с опытом создания продуктов в HP, Netscape и eBay.
Я прочитал Кагана, но в реальной работе всё равно соглашаюсь на фичи от руководства и боюсь сказать разработчикам нет
Мой последний релиз молча проигнорировали, а я даже не понимаю, в чём ошибся — в ценности или в бизнес-модели
На интервью с пользователями я сам того не замечая подсказываю ответы и порчу всю статистику
Мой бэклог забит хаотичным набором хотелок, а я не умею переписывать дорожную карту в измеримые результаты и цели
У руководства есть право вето на всё, и я не знаю, как аргументированно защищать свои продуктовые гипотезы без эмоций
Принцип Кагана на примере вашего продукта
Вопросы по гайду или книге, разбор ошибок
Оценка возможности и план дешёвой проверки
Ты играешь пользователя, вы тренируете разговор
Диагностика релиза по линзам книги
Видение, стратегия и принципы продукта по шагам
Пункты карты в проблемы, результаты и OKR
Карта стейкхолдеров и разыгрывание возражений
Идея горит, а риски слепы
«Все хотят новую фичу, но взлетит ли она?»
Мы хотим запилить корпоративный чат прямо в наш SaaS-продукт для бухгалтеров. Команда горит, пользователи просили «какую-то коммуникацию». Но я боюсь, что мы потратим 3 месяца разработки впустую.
Ты схватил классическую ловушку по Марти Кагану: путать желания пользователей с реальной ценностью. Продакт обязан оценивать четыре риска до написания кода: ценность, удобство использования, выполнимость и бизнес-жизнеспособность. Самый опасный здесь — риск ценности: будут ли бухгалтеры реально общаться в твоем инструменте или им проще остаться в Telegram? Конкретный шаг: давай разберем твою фичу по этим четырем рискам прямо сейчас. Какой из них кажется тебе самым уязвимым?
Риск ценности точно главный. Бухгалтеры замкнуты в своих отчетах, им некогда чатиться.
Отличная диагностика. Теперь мы знаем, что копать нужно в ценность, а не в интерфейс или архитектуру. План дешевой проверки: сделай прототип без кода и покажи пяти бухгалтерам за один день. Мы разобрали Режим 3: Оценка возможности и план дешевой проверки. Всего в тренажере 8 режимов — от проверки стейкхолдеров до разбора проигнорированных релизов. Принесешь свою продуктовую задачу — разберем дальше.
Да, хочу разобрать свой релиз и план проверки.
Директор рубит фичи
«Стейкхолдер с правом вето заворачивает идею»
У меня есть сильная гипотеза по продукту, но директор по безопасности каждый раз говорит «нет» на любые изменения, ссылаясь на риски. Разговор заходит в тупик.
Это классическая проблема работы со стейкхолдерами, у которых есть право вето. По Кагану, задача продакта — не спорить с ними, а разделять их страхи и заранее снимать их возражения через факты и тесты. Давай сыграем в симуляцию: я побуду твоим директором по безопасности. Скажи мне свое предложение так, чтобы снять вопрос о защите данных еще до моего возражения.
Мы хотим дать клиентам доступ к архиву документов, но сделаем это через защищенный токен без скачивания на локальные ПК.
Уже лучше, но звучит как оправдание. Директор слышит «доступ к архиву» и пугается утечки. Конкретная формулировка: «Я знаю, что безопасность наших данных — приоритет. Мы протестировали сценарий, при котором файлы вообще не покидают контур системы, вот метрики пилота». Чувствуешь разницу? Мы разобрали Режим 8: Карта стейкхолдеров и разыгрывание возражений. В тренажере можно отработать жесткие диалоги с любыми ролями. Принесешь свой сложный разговор?
Хочу отработать разговор с директором на своих ситуациях.
Дорожная карта — список фич
«Roadmap забит фичами, а метрики не растут»
Наш генеральный директор требует дорожную карту на год вперед с конкретными фичами. Мы их пишем, но продукт от этого лучше не становится, а команда превращается в фабрику по отгрузке кода.
Ты описываешь типичный синдром «фабрики фич», против которой яростно выступает Марти Каган. Настоящая стратегия продукта строится на результатах и решении проблем клиентов, а не на закупке списка функций. Конкретный пример: вместо пункта дорожной карты «сделать новый дашборд» запиши проблему «пользователи теряют 20 минут в день на поиск отчетов». Разницу чувствуешь? Давай перепишем один пункт из твоего текущего плана в измеримый результат.
У нас в карте стоит «интеграция с CRM-системой X».
Отлично. Интеграция — это инструмент, а не результат. Переформулируем: «Сократить время ручного ввода данных клиентами в два раза за счет автоимпорта из CRM-системы X». Мы разобрали Режим 7: Пункты карты в проблемы, результаты и OKR. В тренажере есть режимы для перестройки всей продуктовой стратегии. Принесешь свой Roadmap?
Да, хочу переписать наш квартальный план в проблемы.
Интервью с подсказками
«Я сам подсказываю клиентам на интервью то, что хочу услышать»
Я провожу кастдевы, но ловлю себя на том, что защищаю свой продукт. Когда клиент мне говорит, что интерфейс непонятен, я начинаю оправдываться и объяснять, как надо.
Это главная ловушка исследователя — искать подтверждение своей правоты вместо правды. Каган учит проводить интервью и юзабилити-тесты молча, без наводящих вопросов и споров. Конкретная реакция на критику интерфейса: не спорить, а сказать «Интересно. Расскажи подробнее, где именно ты застрял и что ожидал увидеть?». Давай проверим: если клиент говорит «у вас неудобная кнопка оплаты», что ты ответишь?
Я спрошу: «А почему вам показалось неудобно и куда бы вы ее поставили?»
Блистательно! Ты убрал защиту и перевел фокус на поведение пользователя. Мы разобрали Режим 4: Тренировка интервью с ИИ-участником. В тренажере можно отточить навык молчания и работы с возражениями. Принесешь реальный сценарий интервью?
Хочу потренироваться не спорить на сложных интервью.
Релиз провалился тихо
«Мы выкатили крутое обновление, но им никто не пользуется»
Мы потратили два месяца на крутой реддизайн личного кабинета, выкатили его вчера — и тишина. Никто из пользователей даже не написал возмущенный отзыв, просто ноль эмоций.
Худший враг продукта — не гнев пользователей, а их полное равнодушие. По методологии Кагана (вспомни кейс Word 6.0 против 6.1 или провалы раннего Netflix), это симптом того, что ценность фичи оказалась ниже порога ее освоения. Конкретный шаг диагностики: ответь на вопрос — какую реальную боль клиента решал этот редизайн или это было просто «удобнее для разработчиков»? Назови одну проблему, ради которой затевался редизайн.
Мы хотели сделать шрифты современнее и меню чуть компактнее.
Вот и ответ. Ни у одного клиента нет боли «устаревшие шрифты», пока это не мешает решать их задачи. Редизайн ради эстетики почти всегда проваливается без изменения ценности. Мы разобрали Режим 5: Диагностика релиза по линзам книги. Всего в тренажере 8 режимов для анализа продуктовых ошибок. Хочешь разобрать свой проваленный релиз?
Да, хочу разобрать, почему наш релиз не взлетел.
Ценность есть, денег нет
«Продукт нравится всем, но бизнес-модель не сходится»
Наш сервис востребован, пользователи в восторге от функций. Но юнит-экономика трещит по швам, мы сжигаем деньги на каждом клиенте из-за высокой стоимости поддержки.
Это классический разрыв между ценностью для пользователя и бизнес-жизнеспособностью. Как учит Марти Каган на примере Netflix 1999 года, когда они переходили на подписку: продукт и бизнес-модель решаются вместе. Конкретный шаг: найди точку в ценности продукта, за которую клиенты готовы платить больше, или пересобери механику так, чтобы снизить затраты на поддержку (например, через базу знаний или автоответы). Какая доля пользователей создает основную нагрузку на поддержку?
Около 20% клиентов пишут по одним и тем же базовым вопросам настроек.
Прекрасно. Вот твой рычаг бизнес-модели: не поднимать цены для всех, а встроить интерактивный онбординг, который закроет эти базовые вопросы до обращения в саппорт. Мы разобрали Режим 1: Принцип Кагана на примере вашего продукта. В тренажере есть и другие режимы для поиска баланса ценности и экономики. Принесешь свою модель?
Да, хочу пересчитать ценность и экономику нашего продукта.
Определяет по горизонту, содержанию и назначению, чем является текст — видением, миссией или спецификацией, объясняет, чем видение отличается от миссии и от спецификации, и называет горизонт видения
Отличает «что получить» от «как делать» и результат от процесса, убирает из цели способ решения, проверяет, что результат измеряется числом, а не выпуском функции, и объясняет, что даёт каждый из двух принципов
Отвечает письменно на четыре вопроса оценки возможности — цель команды, измеримый ключевой результат, проблема клиента как трудность пользователя и конкретный целевой рынок — и не подставляет в проблему название функции
Определяет референсного клиента по признакам, объясняет, почему референсы нужны продажам и кто отвечает за их отсутствие, отличает его от бета-тестера, участника раннего релиза и заказчика и называет, для каких работ программа оправдана
Ведёт интервью с пользователем: открытыми вопросами выясняет, как человек решает проблему сегодня, возвращает его от желаемого к реальным фактам, не убеждает в достоинствах идеи и не обещает сроки и функции
Объясняет, что прототип делают ради обучения и он стоит на порядок дешевле продукта, подбирает детализацию под задачу, называет, какой риск прототип снимает и чего он не докажет, и не доращивает прототип до продукта
Ведёт тест молча и без подсказок: начинает со вводной, повторяет слова участника на его вопросы-наводки, описывает его действия, когда он молчит или застрял, и хвалит действием, а не оценкой
Планирует тест спроса с поддельной дверью: размещает опцию без признаков теста, описывает страницу после клика, заранее называет ожидаемую долю кликов и охват под тип компании, планирует разговоры с оставившими контакт и не выдаёт клики за подтверждённую ценность
Определяет заинтересованную сторону по праву вето, называет, какое именно ограничение она защищает, и относит человека с мнением, но без права вето, к источникам идей
Различает инновационную культуру и культуру исполнения своими словами, по описанной практике компании называет, какая из культур слаба и по какому пункту, и ищет причину нехватки инноваций или темпа в культуре, а не в процессе
Отработайте метод
Начать тренировку →