Цитаты из книг автора «Марти Каган»

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

Если инженеры-программисты впервые узнали об идее при планировании спринта, считайте, что вы потерпели неудачу.

Как сказал Марк Андриссен, «самое главное — понимать, какая информация вам недоступна»

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

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

Отметьте: наши менеджеры по поставке продукта на рынок играют ключевую роль в установлении любых сроков в рамках этих обязательств. Предположим, инженеры-программисты уверены, что на создание и поставку продукта уйдет всего две недели. Но что, если эта команда уже занята другой работой и не сможет начать новую еще месяц? А проектные менеджеры отслеживают все обязательства и взаимозависимости.

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

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

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

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