В ПРОДОЛЖЕНИИ К ПРЕДЫДУЩЕМУ ПОСТУ…

5️⃣ Золотая тройка: Product Manager + Designer + Engineer (не случайность)

Каган повторяет: инженеры — это не обслуживающий персонал, а партнёры в открытии.

Если ты сначала всё придумаешь, а потом попросишь инженеров «реализовать»:

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

Если инженеры включены с самого начала:

  • генерируют нестандартные решения
  • находят быстрые способы тестирования
  • видят риски, которые упустили другие
  • чувствуют себя создателями, а не исполнителями

6️⃣ Четыре риска, которые нужно проверить ДО разработки

Каган выделяет 4 типа рисков продукта: • Ценность: нужен ли людям вообще этот продукт? • Юзабилити: поймут ли люди, как это использовать? • Реализуемость: мы можем это построить/разработать? • Бизнес-жизнеспособность: получится ли это монетизировать?

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

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

7️⃣ Product Manager должен быть полиглотом (или хотя бы трилингвом)

Хороший Product Manager говорит на языке клиента, инженеров & бизнеса одновременно.

Потому что: Язык клиента → что им нужно, какая боль Язык инженеров → реально ли это, за какое время, какие подводные Язык бизнеса → как монетизировать, какие каналы, юридические ограничения, бренд-риски

Вывод: Product Manager, который говорит только о пользовательской ценности, но не понимает маркетинг или лимиты инженеров — это Half-Product Manager.

8️⃣ КУЛЬТУРА решает всё (даже больше, чем процесс)

Культура инноваций = speed, fast эксперименты, свобода, смелость рисковать

Культура защиты = процессы, дорожные карты, согласования, «а не рано ли?»

В компаниях с сильной продуктовой культурой:

  • Инженеры и Product Managerы говорят с клиентами напрямую
  • Релизы происходят часто (недели, а не кварталы)
  • Ошибки — это not a bug, it's a feature (в смысле, это данные)
  • Дорожная карта не священна, если рынок говорит другое
  • Если идея хорошая, её не придавят бюрократией

В компаниях с культурой защиты:

  • Всё согласовывается, рассчитывается, предсказывается (то и дело, что вангуют)
  • Релизы раз в квартал с триумфальным совещанием
  • Если не совпал с дорожной картой — это провал
  • Классные идеи умирают на комитетах

ВЫВОД: ВДОХНОВЛЕННЫЕ КОМАНДЫ СОЗДАЮТ ВДОХНОВЛЯЮЩИЕ ПРОДУКТЫ

Книга Кагана не про agile и не про дизайн-мышление.

Это книга про выбор: Будешь ли ты горящим миссионером, который создаёт хиты или командиром отряда исполнителей, который делает то, что попросили?

💡 Что я вынес для себя:

💎 Великие продукты рождаются не из процесса — из глубокого понимания клиентов и их потребностей 💎 Скорость обучения — твой главный конкурентный плюс (это я про быстрые тесты, провалы и новые эксперименты) 💎 Engineers, Product Design & Product Manager — это тройка, а не цепь подчинения 💎 Половина идей будет неверной — и это не ошибка, это ценные данные 💎 Культура организации важнее процессов (да, даже Agile)

Как то мне один хороший человек сказал следующее: _«Если водка мешает работе, то наер эту работу»

Объясняю: «Если процесс мешает результату, то наер этот результат»._

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

И главное: если сегодня ты делаешь продукт «как в ТЗ» — пора что-то менять. Потому что где-то есть команда, которая делает это же, но лучше и быстрее.

P.S. Для ознакомления с книгой выложил mindmap в свой телеграм канал.

В ПРОДОЛЖЕНИИ К ПРЕДЫДУЩЕМУ ПОСТУ… | Сетка — социальная сеть от hh.ru