{"id":14275,"url":"\/distributions\/14275\/click?bit=1&hash=bccbaeb320d3784aa2d1badbee38ca8d11406e8938daaca7e74be177682eb28b","title":"\u041d\u0430 \u0447\u0451\u043c \u0437\u0430\u0440\u0430\u0431\u0430\u0442\u044b\u0432\u0430\u044e\u0442 \u043f\u0440\u043e\u0444\u0435\u0441\u0441\u0438\u043e\u043d\u0430\u043b\u044c\u043d\u044b\u0435 \u043f\u0440\u043e\u0434\u0430\u0432\u0446\u044b \u0430\u0432\u0442\u043e?","buttonText":"\u0423\u0437\u043d\u0430\u0442\u044c","imageUuid":"f72066c6-8459-501b-aea6-770cd3ac60a6"}

Обзор книги «Вдохновленный: как создавать продукты, которые нравятся покупателям»

Марти Кейган
Партнер в Silicon Valley Product Group, бывший лидер по продуктам в eBay, Netscape и HP. 

Марти Кейган (можно встретить вариант фамилии — Каган) — легенда в мире продакт-менеджмента. Основатель современного управления технологическими продуктами (конечно, вместе со Стивом Джобсом). В этом обзоре поделюсь с вами двумя новыми аспектами, раскрытыми автором во втором издании указанной книги.

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

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

О чем книга?

Что делает Марти Кейгана таким феноменом? Чтобы найти ответ на этот вопрос, обратимся к его книги. Эта книга одна из первых в своем роде. Она просто кладезь практических советов по созданию качественного и привлекательного продукта. Да, с момента ее издания выпущено уже огромное количество других книг по управлению и разработке, но началось все именно с произведения Кейгана.

Вот некоторые вещи, которые я узнал из этой книги и потом применил на практике:

  • Появление хорошего продукта не случайно, он создается целенаправленно, и автор подтверждает этот тезис десятью аргументами. По словам Марти, у менеджера по продукту есть две ключевые обязанности: оценка возможностей продукта и определение востребовательности продукта.
  • Создание нужного продукта. Марти подчеркивает, что менеджер несет ответственность за принятие решений, а команда программистов лучше знает, как идея воплощается на практике, поэтому тесное сотрудничество просто необходимо. В пятой главе описаны три практических способа такого взаимодействия, в результате которого определяется не конечный продукт, а минимально возможный, но соответствующий поставленным целям.
  • Набор хороших менеджеров по продукту. В шестой главе автор описывает ключевые качества, на которые следует обращать внимание при найме сотрудников. Я сравнил списки важных качеств, составленные мной и Кейганом. И единственное, о чем хотелось бы узнать побольше от «гуру продукта», — коммуникация и связанные с ней гибкие навыки. В небольшом разделе о коммуникации в основном сказано о написании понятных текстов и общих навыках презентации. Но мне все еще интересно, как Марти работает с незаинтересованными сторонами, побуждая покупать идею или делать инвестиции.
  • Оценка возможностей продукта. Это одна из главных вещей, которую я узнал от Марти несколько лет назад, и она имеет огромное практическое значение. Автор предлагает набор вопросов для оценки, но даже если вы задаете себе не все, эффект все равно ощутим. Больше всего мне в этой оценке возможностей нравится то, что она фокусируется на пользовательской или бизнес-проблеме, а не на конкретном решении.
  • Формулировка решения о продукте. В тринадцатой главе книги автор подчеркивает важность этого совета. Держите вместе все, что создаете и придумываете. Я узнал, как легко можно упустить из виду ключевые факторы принятия решений, как просто подумать, что все находятся на одной волне, когда это не так.

Основные причины неудачных попыток создания продукта

В книге множество материалов о создании отличных продуктов и об управлении ими но я хочу сосредоточить внимание на рекомендациях автора по распространению продуктов. Начнем с перечисленных им «основных причин неудачных попыток создания продукта».

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

Старайтесь узнать то, чего вы не можете знать.

9 проблем, с которыми сталкиваются компании, использующие «водопад»

  • Продукты ориентированы на уже заинтересованные стороны. Такой подход сверху вниз приводит к появлению слабых команд.
  • Вымышленные бизнес-кейсы. Я не могу полностью согласиться с утверждением Кейгана, что два основных параметра бизнес-кейса — сколько денег мы заработаем и сколько на это потратим. Мы не можем знать доход заранее, потому что это полностью зависит от того, насколько хорошими окажутся принятые решения. Многие продукты в конечном итоге не приносят прибыли!
  • Дорожные карты продукта. С ними связаны две традиционные проблемы. Во-первых, реальность такова, что половина продуктовых идей просто не срабатывает. Я всегда напрягаюсь, когда вижу дорожные карты продукта, которые содержат подробные функции с приоритетами на целый год. По моему опыту, пока вы не начнете находить, внедрять и запускать продукт, вы не узнаете, будет ли он работать. Во-вторых, даже когда у идеи действительно есть потенциал, требуется несколько итераций, чтобы достичь точки, в которой она принесет ценность для бизнеса. Кейган вводит термин «время к деньгам» для обозначения этого эволюционного процесса.
  • Требования заинтересованных сторон. Не собирайте их для последующего внедрения. Недавно я наткнулся на организацию, нанявшую целую команду менеджеров по проекту и бизнес-аналитиков, основная работа которых заключалась в сборе требований заинтересованных сторон и их документировании для последующей реализации. Кейган справедливо отмечает, что «это далеко от реальности современного управления технологическими продуктами».
  • UX-дизайнеры вовлекаются слишком поздно. Не привлекайте дизайнеров после того, как собрана обратная связь. Это слишком поздно, дизайнер не принесет достаточно пользы на этом этапе.
  • Программисты вовлекаются слишком поздно. Если разработчики занимаются исключительно программированием, то извлечь максимум ценности не получится. Мне нравится «маленький секрет», которым Кейган делится в книге: «разработчики — лучший и единственный источник инноваций». Он совершенно прав!
  • Agile только для команд доставки ценности. Кейган говорит об ошибке, когда группы разработки продуктов работают по Agile, а остальная часть организации нет.
  • Процессы, ориентированные на проекты. Компания обычно финансирует, продвигает и запускает проекты. К сожалению, продукт — это причина, а проект — это следствие. Я бы добавил, что большинство проектов — это разовые работы, тогда как продукты имеют непрерывный жизненный цикл, пока не будут сняты с производства.
  • Поиск клиентов начинается слишком поздно. Кейган указывает на самый большой недостаток старого каскадного процесса — весь риск сосредоточен в самом конце, а поиск клиентов начинается слишком поздно. Тогда как поиск клиентов должен быть непрерывными и должен начинаться практически с самого начала разработки.

Кейган предлагает три принципа, которые помогут преодолеть вышеупомянутые причины неудач:

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

Непрерывное открытие и реализация

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

В конечном итоге этот процесс позволяет получить ответы на четыре важных вопроса:

  • Купит ли это пользователь?
  • Поймет ли пользователь как это использовать?
  • Сможет ли программист это реализовать?
  • Поддержат ли продукт заинтересованные стороны?

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

  • Видение продукта и стратегия
  • Бизнес-цели

Риски

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

  • Финансовый риск — можем ли мы себе это позволить?
  • Риск развития бизнеса — сработает ли наше решение у партнеров?
  • Маркетинговый риск — соответствует ли решение бренду?
  • Риск продаж — смогут ли торговые представители это продать?
  • Правовой риск — все ли безопасно с юридической точки зрения?
  • Этический риск — следует ли принимать это решение с точки зрения этики?

Методы фрейминга открытий

Затем Кейган описывает три любимых метода фрейминга открытий.

1. Оценка возможностей

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

  • Для решения какой бизнес-задачи предназначена эта работа?
  • Как вы узнаете, что добились успеха?
  • Какую проблему клиентов вы решаете?
  • На каких клиентов вы ориентируетесь?

2. Письмо клиентам

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

3. Канва стартапа

Она полезна, когда вы работаете на ранней стадии или начинаете с нуля, подходит как для работы с бизнесом, так и с продуктом или услугой. Есть много примеров, на которые стоит взглянуть поближе. Я советую обратить внимание на канву бизнес-модели Алекса Остервальдера или на ориентированную на стартапы канву Эша Маурья.

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

Наконец, Кейган объясняет, что «ценность тестирования» — это ключевой момент, который следует учитывать при планировании поиска клиентов. Главное здесь — узнать, воспринимают ли клиенты ваш продукт лучше, чем аналогичный продукт у конкурентов. Многие компании и продуктовые группы думают, что все, что им нужно — соответствовать характеристикам конкурентных альтернатив. Эта идея о «паритете функций» не соответствует действительности. На самом деле, для того, чтобы покупатели отказались от имеющегося на рынке продукта, они должны считать, что новый продукт лучше, чем уже существующий.

Например, иногда неясно, хотят ли клиенты именно то, что мы собираемся создать. Очень рискованно думать: «Мы это сделаем, и клиенты придут». В книге Кейган рассказывает о том, как можно быстро и дешево проверить, есть ли спрос на продукт - запустить целевую страницу. На ней описывается новое предложение точно так же, как если бы действительно запустился сервис. Разница в том, что когда пользователь нажимает на кнопку “купить”, он видит сообщение с объяснением, что вы планируете запуск продукта и хотите получить первоначальный фидбэк от пользователей. Все это подпадает под мантру «Делай то, что масштабируется», впервые представленную Полом Грэмом, основателем Y Combinator.

Главная мысль книги

«Вдохновленный: как создавать продукты, которые нравятся клиентам» - это фактически сборник конкретных указаний и правил по разработке привлекательных продуктов и по созданию культуры, ориентированной на продукт. Неважно, новичок вы или занимаетесь этим уже несколько лет, я почти уверен, что каждый сможет чему-то научиться у такого мастера, как Марти Кейган!

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

Лучшие книги и материалы о создании и развитии цифровых продуктов для продакта и фаундера 😏 t.me/anonfiction

О чем будет следующий пост?
Поиск идей для продукта 
Инструменты валидации идей
Развитие продукта
Управление бэклогом
Методы выстраивания процессов производства
Взаимодействие в команде
Культура и организационные модели
Управление изменениями
Показать результаты
Переголосовать
Проголосовать
0
Комментарии
-3 комментариев
Раскрывать всегда