Готовьтесь к длинному рассказу (не уместился в один пост): сейчас будет очень жизненно и местами неожиданно больно. Уверен, многие увидят в этих строчках себя или свою любимую компанию (или нелюбимую… тут уж как повезло). Если что — спорить разрешаю, можно даже в комментах, главное без слайдов из методички по Agile🙃 Сразу отмечу, что в книге речь про высокотехнологичные IT-продукты, однако точно есть чему поучиться и переложить на физические продукты.

На днях закончил книгу Кагана «Вдохновленные» (рекомендую) и собрал всё в mindmap. Потому что читать 300+ страниц и забыть — это не про мою продуктивность. А вот вернуться к схеме через месяц и вспомнить суть — вот это да, к тому же и поделиться можно с вами😉

Собственно сам mindmap можно посмотреть в моем телеграм канале.

🔥 ГЛАВНАЯ МЫСЛЬ, которая просто вывернула мозг Неважно, насколько крутые разработчики в вашей команде. Если они работают над НЕПРАВИЛЬНЫМ продуктом — получите красиво упакованное ничто.

1️⃣ Product Management ≠ сборщик требований

Project Manager = процесс Product Manager = результат

Если ты Product Manager, который просто:

• принимает идеи «сверху», как святое ТЗ
• планирует дорожную карту на год вперёд
• делает, что просит отдел продаж
• сдаёт в сроки и называет это успехом

…то ты просто fancy-менеджер проекта. Кагана бы это очень расстроило, правда.

Хороший Product Manager:

• проверяет каждую гипотезу на реальных пользователях
• говорит «нет» идеям, которые звучат красиво, но бесполезны
• знает, где именно люди жмут на кнопку (а где нет)
• не боится стартовать с прототипа вместо «полноценного решения»

2️⃣ Почему успешные компании становятся скучными (грустная история)

Вот как выглядит дорога деградации: 1. Компания создала крутой продукт 2. Начинает защищать его вместо того, чтобы создавать новый 3. Открывает «инкубационный центр инноваций» (спойлер: там только совещания и речь далеко не про инновации) 4. Внедряет ещё больше процессов (нужно же кого-то винить) 5. Инженер должен согласовать идею с N стейкхолдерами🤦 6. Классная идея окончательно заболевает в согласованиях (такие патологии часто встречаются) 7. Стартап же её подхватывает и выигрывает🚀

Каган говорит: дело не в размере компании, а дело в скорости проверки гипотез.

3️⃣Стартапы потому и быстрые, что… быстрые

Звучит как тавтология, но слушай: Стартап в день: идея → прототип → тест → выводы → итерация → повтор

Корпорация в день: совещание про совещание → на что выделить бюджет? → кого согласовать? → а не рано ли?

Побеждает не хаос, а скорость цикла обучения и конверсия гипотез:

Да, в стартапе бардак. Но:

• нет бюрократии
• инженеры включены с самого начала
• ошибки дешёвые
• всё тестируется немедленно
• знания растут экспоненциально

Итог: стартап учится быстрее, чем корпорация успевает согласовать.

4️⃣Миссионеры vs Наёмников (вот где правда)

Каган разделяет команды не по компетенции, а по мышлению.

Команда-наёмник:

• Делает фичи, как в ТЗ написано
• Гордится: «сдали в срок»
• Спрашивает: «А это в спецификации указано?»
• Ждёт конца рабочего дня
• Может в любой момент уйти на лучший оффер

Команда-миссионер:

• Понимает ценность продукта для пользователя
• Говорит с клиентами (даже если это не входит в ТЗ)
• Генерирует идеи
• Тестирует, ошибается, снова тестирует
• Вообще, с такими людьми компанию не построишь? Нет, такие люди и создают компании.

Продолжение следует…