В современном управлении продуктами часто доминирует подход, основанный на мнениях руководителей, что может приводить к катастрофическим потерям ресурсов. В рамках подкаста Lenny's Podcast эксперт по продуктовой стратегии Итамар Гилад (Itamar Gilad) обсуждает с ведущим Ленни Рачитски (Lenny Rachitsky) свою книгу «Evidence-Guided» и предлагает системный переход к принятию решений на основе доказательств. На примерах провалов и успехов в Google он раскрывает эффективность модели GIST и практических инструментов вроде матрицы уверенности и деревьев метрик.
📉 Крах Google+: Эпоха управления на основе мнений 4:36
Итамар Гилад присоединился к команде Gmail в августе 2011 года. В этот период руководство Google было серьёзно обеспокоено взрывным ростом социальной сети Facebook. Люди проводили на платформе конкурента часы, что воспринималось поисковым гигантом как прямая экзистенциальная угроза. В качестве ответного шага топ-менеджмент принял стратегическое решение запустить собственную социальную сеть — Google+. Компания не жалела ресурсов на этот проект: было создано отдельное закрытое подразделение, сопоставимое по масштабам с командами Android или Google Docs. Перед разработчиками поставили директивную задачу — принудительно связать Gmail, YouTube и поисковую систему с Google+, чтобы сделать их более «социальными» и персонализированными.
Внутри новой структуры была развёрнута работа по методике, которую Итамар Гилад называет «планируй и исполняй» (plan and execute) или разработкой на основе мнений (opinion-based development). Команда создавала огромное количество функций, проводила масштабные редизайны и итерации в течение нескольких лет. На пике развития в подразделении Google+ работало около 1000 сотрудников. Проект разрабатывался в режиме строгой секретности, что напоминало классический подход Стива Джобса. По воспоминаниям Ленни Рачитски, в самом Facebook эта ситуация вызвала панику уровня DEFCON 1, заставив компанию временно заблокировать внутренние процессы для защиты.
Однако, несмотря на колоссальные вложения миллионов человеко-часов, интеграция полностью провалилась. Пользователям не была нужна ещё одна социальная сеть, они ею не пользовались. Спустя несколько лет команде Gmail пришлось полностью свернуть все интеграции с Google+, а сама социальная сеть была окончательно закрыта в 2019 году. По мнению Итамара Гилада, Google не просто потратил ресурсы впустую, но и упустил гораздо более перспективные мобильные тренды. Находясь в непосредственной близости от штаб-квартиры Google, стартап WhatsApp создавал продукт, которым пользовались сотни миллионов человек по всему миру, и в итоге стал для Facebook гораздо более реальной угрозой, чем вся инфраструктура Google+. Этот провал стал поворотной точкой в карьере Гилада, заставив его искать альтернативные методы управления продуктами.
📥 Вкладки в Gmail: Как доказательный подход спас продукт от хаоса 8:37
В первое десятилетие своего существования Google развивался как компания, ведомая доказательствами (evidence-guided). Продуктовая культура компании опиралась на пристальное внимание к пользователям, сбор данных, запуск сырых бета-версий и знаменитую парадигму «быстрого провала» (fail fast). Если проект не демонстрировал результатов, его без колебаний закрывали или радикально меняли его курс (pivot). В случае с Google+ эта ДНК была временно отброшена в пользу авторитарного планирования, однако внутри команды Gmail принципы доказательного подхода сохранились и легли в основу следующего крупного проекта — разделения входящих писем по вкладкам (tabbed inbox).
Проект сортировки писем начинался как скромная идея, в которую изначально никто в компании не верил. Итамар Гилад обратил внимание на то, что пользователи тонули в хаосе из социальных уведомлений и рекламных рассылок. Большинство пользователей занимали пассивную позицию: они не чистили почтовые ящики вручную и страдали от захламления интерфейса. Когда Гилад предложил автоматическое разделение писем, он планировал действовать по старой схеме «планируй и исполняй», однако коллеги выступили с резкой критикой. Они указали на то, что Google уже создавал множество инструментов для организации почты, но пользователи их игнорировали.
Этот отпор заставил команду переключиться на глубокие пользовательские исследования. Разработчики начали тестировать гипотезы на собственных ящиках, затем подключили внутренних сотрудников Google (dogfooding), а позже вышли на внешние группы тестеров. Были сформированы специальные команды по анализу данных (data mining) и машинному обучению для создания точных алгоритмов категоризации. Результат оказался неожиданным: для продвинутых ИТ-специалистов идея разделения почты казалась глупой, но для 85–88% обычных пользователей она стала спасением. Сегодня Gmail насчитывает около 1,8 миллиарда активных пользователей, и абсолютное большинство из них использует систему вкладок, разделяющую основные письма, социальные сети и промоакции. Проект доказал, что снижение уверенности в собственных мнениях и опора на жесткие факты позволяют создавать продукты высочайшего уровня.
🗺️ Стратегия за рамками шаблонов: Мифы об инновациях Стива Джобса 13:33
Итамар Гилад утверждает, что основатели компаний играют ключевую роль на этапах запуска и масштабирования стартапов, генерируя важнейшие идеи. Однако их видение не должно приниматься слепо; организация обязана критически оценивать предложения топ-менеджмента и запрашивать доказательства. По словам Итамара Гилада, популярная история о том, что Стив Джобс просто придумал iPhone на своей кухне и приказал команде его собрать, является мифом. Реальная история создания смартфона от Apple — это многолетний процесс открытий, проб и ошибок, включавший множество провальных промежуточных проектов и прототипов сенсорных телефонов. Джобс выступал в роли главного архитектора, который соединял точки и менял свое мнение по мере того, как инженеры демонстрировали ему работающие демо-версии и технологические доказательства.
Даже в открытой культуре Google открыто заявлять основателям вроде Ларри Пейджа или Сергея Брина об их неправоте было нормой, но в спорах без твердых данных всегда побеждало мнение самого высокопоставленного сотрудника. Гилад рекомендует сотрудникам среднего звена использовать данные как инструмент защиты от авторитаризма руководителей.
Если топ-менеджер не готов слушать аргументы, Итамар советует провести быстрый закрытый эксперимент и вернуться с наглядными результатами. В таких ситуациях реакция руководства обычно делится на два типа:
- Руководитель впадает в ярость и требует строго следовать приказам. В этом случае Гилад рекомендует начать обновлять резюме и искать другое место работы, так как поведение управленца нерационально.
- Руководитель оказывается приятно удивлен предоставленными фактами и меняет свою точку зрения. Именно так происходило со Стивом Джобсом, который изначально выступал против создания телефона Apple и технологии мультитач, но изменил позицию под воздействием демонстраций.
Понимание того, является ли компания действительно ведомой доказательствами, можно определить по нескольким ключевым симптомам отсутствия такого подхода:
- Цели компании размыты, абстрактны или сфокусированы исключительно на объёме выпускаемых фич (output), а не на реальной ценности для бизнеса и пользователей (outcome).
- Используются только верхнеуровневые финансовые показатели (выручка, доля рынка), но полностью отсутствуют метрики, отражающие пользовательский опыт.
- Огромное количество времени топ-менеджмента уходит на долгосрочное планирование и составление идеальных дорожных карт (roadmaps).
- Инженерная команда оторвана от бизнеса и пользователей, фокусируясь только на механической сдаче кода в продакшн.
📊 Модель GIST: Четыре уровня доказательного управления 21:13
Для системного изменения продуктовой культуры Итамар Гилад разработал мета-фреймворк GIST, объединяющий принципы Lean Startup, дизайн-мышления, продуктового поиска (product discovery) и методологий роста. Фреймворк делит процесс управления на четыре автономных уровня:
- Goals (Цели) — описание конечного состояния, к которому стремится компания.
- Ideas (Идеи) — гипотетические варианты достижения поставленных целей.
- Steps (Шаги) — последовательные итерации по реализации и одновременной валидации идей через циклы «создай–измерь–научись».
- Tasks (Задачи) — конкретные элементы разработки, управляемые через Kanban-доски или Jira.
На уровне целей Гилад рекомендует использовать модель петли обмена ценностью (value exchange loop), согласно которой организация должна максимизировать ценность, поставляемую на рынок, и эффективно возвращать часть этой ценности в виде дохода. Для этого внедряются две ключевые метрики. Поставляемая ценность измеряется через метрику Полярной звезды (North Star metric), а возвращаемая — через главный бизнес-показатель (Top KPI: выручка, прибыль).
Спикер подчеркивает, что настоящая метрика Полярной звезды всегда отражает ценность для клиента, а не для компании. Он приводит в пример несколько успешных компаний:
- WhatsApp на протяжении долгого времени использовал в качестве North Star количество отправленных сообщений, так как каждое сообщение несло бесплатную и быструю ценность пользователям по сравнению с SMS.
- Airbnb ориентируется на показатель забронированных ночевок (nights booked).
- Amplitude замеряет количество недельных пользователей активного обучения (weekly active learning users) — тех, кто нашел инсайт в аналитике и поделился им минимум с двумя коллегами.
Эти две корневые метрики затем детализируются до самого глубокого уровня в виде так называемых деревьев метрик (metrics trees). Математическое разложение показателей на под-метрики (например, коэффициент активации) позволяет точно оценивать потенциальный экономический эффект от любого эксперимента, выстраивать топологию кросс-функциональных команд вокруг конкретных ветвей дерева и обеспечивать полную прозрачность при выстраивании приоритетов.
⚖️ Оценка идей по методу ICE и «термометр уверенности» 33:42
Компании регулярно затапливает потоком идей от основателей, конкурентов и клиентов, что часто приводит к политическим битвам мнений или доминированию позиции HiPPO (мнения самого высокооплачиваемого человека в комнате). Чтобы сделать этот процесс прозрачным, Итамар Гилад рекомендует классическую модель ICE (Impact, Confidence, Ease), созданную Шоном Эллисом (Sean Ellis) — основоположником движения growth hacking. При этом Гилад намеренно предпочитает лаконичную ICE более сложной модификации RICE, упаковывая показатель охвата (reach) внутрь оценки влияния (impact).
Оценка влияния (Impact) и простоты реализации (Ease) в классическом виде представляют собой лишь предположения (guesstimates). Главной проблемой становится склонность менеджеров завышать показатель уверенности в собственных идеях, выставляя 8 баллов из 10 на основе чистого энтузиазма. Для устранения этого субъективного фактора Гилад создал инструмент «Индекс уверенности» (Confidence Meter), работающий по принципу термометра со шкалой от 0 до 10:
- 0.01 – 0.1 балла (Синяя зона) — Чистые мнения. Сюда относятся личная убежденность продакта, красивый питч-дек, шестистраничный документ или поддержка модных технологических трендов (таких как искусственный интеллект или блокчейн). Привязка идеи к общей стратегии компании также дает не более 0.1 балла, так как тысячи провальных идей прямо сейчас реализуются под эгидой «стратегических приоритетов».
- Средняя зона — Обсуждение идеи с коллегами и экспертами, проведение базовых расчетов (back-of-the-envelope calculations), а также сбор поверхностных данных. Сюда же относится копирование функций конкурентов. Гилад предупреждает: предположение, что ваши конкуренты понимают, что они делают, лучше вас — это опасная иллюзия. Чуть выше ценятся масштабные рыночные исследования и опросы.
- Высокая зона (Красная зона) — Реальные тесты и эксперименты на пользователях (А/В-тестирование, программы раннего доступа).
Индекс уверенности позволяет соотносить объем инвестиций в идею с текущим уровнем доказательств: на ранних этапах следует проводить самые дешевые тесты, отсекая нежизнеспособные концепции. В то же время Гилад отмечает, что для низкорисковых или очевидных задач (например, изменение порядка пунктов меню) проводить полноценные исследования избыточно — их можно сразу отправлять в релиз. Основная задача продакт-менеджера — уметь говорить «нет» плохим идеям, и Confidence Meter служит экологичным инструментом для аргументированного отказа. Доказательный подход меняет главную продуктовую метрику со скорости доставки кода в продакшн на «время до достижения бизнес-результата» (time to outcomes).
🧪 Слой Steps: Как проверять гипотезы без написания кода 50:13
Многие компании совершают ошибку, полагая, что проверка идеи обязательно требует создания полноценного минимально жизнеспособного продукта (MVP), который на практике оказывается перегруженным функциями и дорогим в разработке. Слой Steps в модели GIST предлагает постепенную валидацию через пять последовательных этапов: оценка (Assessment), сбор фактов (Fact-finding), тесты (Tests), эксперименты (Experiments) и анализ результатов релиза (Release results).
На этапе тестов (Tests) критически важно проверять ключевые допущения с минимальными затратами, используя методики имитации («подделки») функционала. К ним относятся тесты фальш-дверей (fake door tests), дымовые тесты (smoke tests), а также механики «Волшебника страны Оз» (Wizard of Oz) и консьерж-сервис.
Историческим примером такого тестирования послужила разработка вкладок в Gmail. Первая версия продукта была создана исследователями и дизайнерами без написания единой строки промышленного кода. Пользователям демонстрировался работающий интерфейс, собиравшийся на базе HTML-фасада. В фоновом режиме, используя выданные пользователями разрешения, скрипты и операторы вручную переносили темы и имена отправителей топ-50 писем в соответствующие категории. Во время интервью модератор намеренно отвлекал тестировщика, после чего показывал ему «обновленный» почтовый ящик. Восторженная реакция пользователей, увидевших идеально упорякомленную почту, дала команде Gmail неопровержимые доказательства для полноценного запуска разработки.
Только после подтверждения ценности на «фасадах» продакт-менеджерам следует переходить к среднеуровневым тестам — программам альфа-тестирования, долгосрочным исследованиям пользователей и этапу «рыбьего корма» (fish food). Итамар Гилад поясняет, что термин fish food — это внутренний жаргон Google, означающий dogfooding (тестирование продукта сотрудниками), но ограниченный масштабами исключительно одной непосредственной команды разработки.
