В новом выпуске Lenny's Podcast ведущий Ленни Рачитски беседует с известным продуктовым экспертом и коучем Итамаром Гиладом, бывшим сотрудником Google, YouTube и Microsoft. Главной темой обсуждения стал переход от интуитивного планирования к подходу, управляемому доказательствами (evidence-guided), который лег в основу новой книги гостя. На примерах масштабных успехов и провалов в Кремниевой долине собеседники разобрали авторский фреймворк GIST, призванный избавить компании от разрушительного влияния субъективных мнений.
📉 Провал Google+: Как «культ мнений» приводит к колоссальным потерям ресурсов 4:36
История работы Итамара Гилада в команде Gmail началась в августе 2011 года. Первой задачей, которую перед ним поставило руководство, была интеграция почтового сервиса с зарождающейся социальной сетью Google+. В тот период Facebook рос стремительными темпами, что вызывало серьезное беспокойство у топ-менеджмента Google. Очевидным решением сверху стало создание собственного социального пространства. Под этот проект внутри корпорации было развернуто колоссальное отдельное подразделение, по масштабам сопоставимое с командами Android или Google Docs, занявшее целые отдельные здания. На пике развития в проекте было задействовано около 1000 человек. По воспоминаниям Ленни Рачитски, в самом Facebook тогда объявили высший уровень тревоги (DEFCON 1) и фактически заблокировали работу других направлений, испугавшись угрозы со стороны поискового гиганта.
Несмотря на то, что в проект были вложены миллионы человеко-часов, а сама идея казалась сотрудникам многообещающей, инициатива полностью провалилась. Как отмечает Итамар Гилад, пользователям просто не была нужна еще одна социальная сеть. В конечном итоге интеграцию с Google+ внутри Gmail свернули, а саму платформу официально ликвидировали в 2019 году. Истинная трагедия заключалась не только в пустой трате ресурсов, но и в упущенных возможностях. Пока Google бросал все силы на копирование Facebook, под самым носом у корпорации росли мобильные стартапы WhatsApp и Snapchat. Именно WhatsApp в итоге стал реальной угрозой для Facebook, собрав сотни миллионов пользователей. Итамар Гилад называет этот случай классическим примером разработки, основанной на мнениях (opinion-based development), когда вера в авторитетную идею заставляет руководство слепо инвестировать в долгосрочное планирование без проверки фактов. При этом в долгосрочной перспективе провал никак не затронул рекламные доходы ни Google, ни Facebook.
📥 Успех сортировки писем в Gmail: Возвращение к культуре проверки фактов 8:37
Несмотря на неудачу с соцсетью, в ДНК сотрудников Google оставался прежний подход, ориентированный на сбор доказательств. В первое десятилетие своего существования компания активно следовала парадигме «быстрого провала» (fail fast), запуская сырые беты и корректируя курс на основе поведения пользователей. По мнению Итамара Гилада, если бы этот принцип применили к Google+, проект закрыли или перестроили бы гораздо раньше. Сразу после закрытия социального направления команда Gmail занялась созданием разделенного на вкладки инбокса (Tabbed Inbox).
Этот проект развивался по сценарию, прямо противоположному Google+: он начался с крошечной идеи, в которую изначально никто в компании не верил. Исследования показали, что до 85-88% пользователей Gmail являются пассивными: они не очищают свои почтовые ящики от рекламных рассылок и уведомлений из соцсетей, из-за чего их инбоксы превращаются в хаос. Когда Гилад предложил автоматически сортировать такие письма по вкладкам, коллеги отнеслись к этому скептически, напомнив, что прошлые инструменты организации писем аудитория проигнорировала. Чтобы доказать жизнеспособность гипотезы, команде пришлось развернуть масштабное исследование. Процесс включал в себя следующие этапы:
- Тестирование алгоритмов на собственных почтовых ящиках разработчиков.
- Привлечение других сотрудников Google в рамках внутренней программы тестирования (dogfooding).
- Проведение глубоких юзабилити-тестов и запуск внешних тестовых групп.
- Создание выделенных команд по анализу данных и машинному обучению для точной категоризации.
Результат превзошел ожидания. Хотя продвинутым пользователям идея казалась нелепой, массовая аудитория встретила интерфейс с восторгом. Сегодня у Gmail насчитывается около 1,8 миллиарда активных пользователей, и абсолютное большинство из них использует эти вкладки. Ленни Рачитски в шутку пожаловался, что алгоритм регулярно отправляет его авторские рассылки во вкладку «Промоакции», на что Гилад признал, что обработка новостных писем остается одной из самых сложных инженерных задач для поискового движка. Главный вывод Итамара Гилада заключается в том, что успех вкладкам обеспечил отказ от слепой веры в собственное мнение в пользу гибкой системы сбора доказательств. Подобный баланс между человеческим суждением и фактами демонстрируют лучшие продуктовые компании мира в свои золотые эпохи, будь то Amazon, Airbnb или Apple.
📱 Развенчание мифа о Стиве Джобсе: Как договариваться с авторитарными лидерами 13:33
Книга Итамара Гилада «Evidence-Guided» представляет собой мета-фреймворк, помогающий внедрить современный продуктовый менеджмент в устоявшиеся структуры компаний. Часто менеджеры сталкиваются с тем, что идеи спускаются сверху авторитарными основателями. В индустрии силен миф о Стиве Джобсе, который якобы просто посидел на кухне, придумал iPhone и приказал команде его собрать. Как утверждает Итамар Гилад, реальная история создания iPhone кардинально отличается от этой легенды.
По словам эксперта, iPhone стал результатом долгого процесса продуктового открытия (discovery), бесчисленных проб и ошибок. Команда Apple разработала множество промежуточных прототипов телефонов и технологий мультитач, большинство из которых провалились. Сам Джобс долгое время выступал против идеи создания телефона, но изменил свое мнение, когда инженеры продемонстрировали ему работающие прототипы и неоспоримые доказательства потенциала технологии. Он выступил не единоличным творцом, а гениальным архитектором, сумевшим соединить разрозненные точки воедино.
Гилад дает практический совет сотрудникам, которые работают с жесткими руководителями: не нужно спорить мнениями, нужно приносить твердые данные. В компаниях, где открытая критика не приветствуется, эффективным методом может стать проведение «секретного» быстрого эксперимента. Предъявление руководителю готовых результатов обычно ведет к одному из двух исходов:
- Руководитель злится и требует вернуться к исполнению приказов. В таком случае Гилад прямо рекомендует обновлять резюме, поскольку иметь дело с неадекватным управлением бессмысленно.
- Руководитель оказывается приятно удивлен фактами. Это наиболее частый сценарий, работавший даже в случае со Стивом Джобсом. Твердые доказательства — единственный инструмент, дающий рядовому сотруднику силу оспорить решение руководства.
🚨 Симптомы «болезни мнений»: Как выявить кризис управления в компании 19:29
Существует несколько четких признаков того, что организация лишь имитирует работу на основе данных, оставаясь во власти субъективных суждений. Итамар Гилад выделяет следующие ключевые симптомы:
- Размытые, неясные или слишком многочисленные цели, которые сфокусированы на объеме выполненной работы (output), а не на реальном результате (outcome).
- Отсутствие метрик, ориентированных на пользователя. Компания отслеживает исключительно выручку или сугубо бизнес-показатели.
- Колоссальные затраты времени топ-менеджмента и продуктовых менеджеров на составление «идеальных» дорожных карт (roadmaps).
- Низкий уровень реального экспериментирования, а в тех редких случаях, когда тесты проводятся, из них не извлекаются уроки для изменения продукта.
- Полная деградация вовлеченности инженеров. Разработчики превращаются в пассивных исполнителей, оторванных от бизнеса и пользователей, заботясь лишь о своевременной сдаче кода.
📐 Знакомство с моделью GIST: Четыре уровня продуктовой трансформации 21:13
Для преодоления этих кризисов Итамар Гилад разработал модель GIST, которая раскладывает глобальные изменения в компании на четыре последовательных и управляемых слоя:
- Goals (Цели) — определение того, чего именно пытается достичь организация.
- Ideas (Идеи) — гипотетические и альтернативные способы достижения поставленных целей.
- Steps (Шаги) — небольшие проекты по реализации и одновременной валидации идей через циклы «сборка-замер-обучение».
- Tasks (Задачи) — конкретные операционные таски, управляемые разработчиками через Kanban, Jira и другие привычные инструменты.
Эта модель не является принципиально новым изобретением с нуля, а представляет собой мета-фреймворк, упорядочивающий подходы Lean Startup, Design Thinking, продуктовое открытие (Product Discovery) и Growth Hacking в единую работающую экосистему. При этом Гилад подчеркивает, что стратегический контекст, видение компании и глобальные исследования лежат за рамками GIST, предполагая, что они уже сформированы в организации. Каждая часть фреймворка в книге описывается через триаду «принципы, модели и процессы», причем процесс является самой хрупкой частью, которую каждая компания обязана адаптировать под свою специфику.
🔄 Уровень Goals: Петля обмена ценностью и построение дерева метрик 25:07
Правильная работа с целями — это не просто планирование того, что и к какому сроку нужно построить. Настоящие цели должны описывать конечное желаемое состояние системы. Распространенной ошибкой является разделение целей по изолированным департаментам, что порождает рассинхронизацию между инженерами, дизайнерами и маркетологами.
В качестве альтернативы Гилад предлагает опираться на концепцию петли обмена ценностью (Value Exchange Loop). Суть концепции заключается в том, что компания стремится отдать как можно больше ценности рынку и вернуть часть этой ценности себе в виде коммерческой выгоды. Этот баланс требует одновременного отслеживания двух ключевых показателей:
- Метрика Полярной звезды (North Star Metric) — измеряет совокупный объем пользы, создаваемой продуктом для пользователей.
- Верхнеуровневый KPI бизнеса (Top KPI) — отражает ценность, которую компания забирает обратно (выручка, маржинальность, доля рынка).
Спикер привел яркие исторические примеры настоящих метрик Полярной звезды. Так, мессенджер WhatsApp на протяжении долгого времени измерял исключительно количество отправленных сообщений (messages sent), поскольку каждое сообщение несло микроценность для пользователей, будучи бесплатным по сравнению с SMS. В Airbnb ключевой метрикой выступало число забронированных ночей (nights booked), что Ленни Рачитски подтвердил на основе своего опыта работы в компании. Аналитическая платформа Amplitude использует показатель еженедельно активных обучающихся пользователей (weekly active learning users) — тех, кто нашел в интерфейсе инсайт и поделился им минимум с двумя коллегами.
Эти две главные метрики (North Star и Top KPI) затем декомпозируются вниз, образуя разветвленное дерево метрик (Metrics Tree). Наличие визуализированного дерева метрик позволяет команде математически точно оценивать потенциальный эффект от любого локального эксперимента. Например, если команда планирует улучшить показатель активации на 10%, дерево наглядно продемонстрирует, как именно это изменение повлияет на глобальную выручку компании. Кроме того, дерево метрик помогает выстраивать правильную топологию команд, распределяя зоны ответственности сотрудников вокруг конкретных ветвей и целей, а не вокруг слепой архитектуры программного кода.
📊 Уровень Ideas: Скоринг по методике ICE и борьба с субъективностью 33:42
Продуктовые команды всегда перегружены идеями, поступающими от основателей, конкурентов, сейлзов и клиентов. Без четкого механизма фильтрации принятие решений скатывается к политическим играм или правилу HiPPO (доминированию мнения самого высокооплачиваемого сотрудника). Для объективного ранжирования гипотез Итамар Гилад рекомендует использовать классическую систему скоринга ICE (Impact, Confidence, Ease), созданную Шоном Эллисом — отцом движения Growth Hacking.
Система оценивает каждую идею по трем параметрам:
- Impact (Влияние) — потенциальный вклад идеи в изменение целевых метрик дерева.
- Ease (Простота) — показатель, обратный объему затрачиваемых усилий (effort).
- Confidence (Уверенность) — оценка того, насколько наши предположения о влиянии и простоте подкреплены реальными фактами, а не фантазиями.
Гилад сознательно выбирает оригинальный вариант ICE вместо популярного RICE (где добавляется охват — Reach), поскольку предпочитает закладывать охват внутрь параметра влияния, чтобы не перегружать формулы лишними математическими действиями.
Главная проблема традиционного использования ICE заключается в том, что менеджеры склонны ставить максимальный балл уверенности (например, 8 из 10), опираясь лишь на собственное предчувствие, что полностью ломает логику скоринга. Чтобы решить эту проблему, Итамар разработал инструмент под названием «Шкала уверенности» (Confidence Meter). Шкала проградуирована от 0 до 10 баллов и жестко привязывает оценку к характеру имеющихся доказательств:
- 0.01 – 0.1 балла (Зона мнений): Сюда относятся личная убежденность менеджера, красивый питч-дек, шестистраничный документ с описанием идеи или ее соответствие модному тренду (например, блокчейну или искусственному интеллекту). Гилад напоминает, что прямо сейчас в мире реализуются тысячи провальных проектов только потому, что они содержат аббревиатуру AI.
- 0.2 – 0.8 балла (Зона экспертных оценок и планов): Обсуждение идеи с коллегами, проведение первичных расчетов, оценка трудозатрат разработчиками.
- 1 – 3 балла (Зона предварительных данных): Наличие косвенных упоминаний в общих исследованиях, проведение опросов клиентов, глубокий конкурентный анализ или тот факт, что аналогичную функцию только что запустил главный конкурент. При этом эксперт предостерегает от слепого копирования конкурентов, так как они зачастую знают о рынке не больше вашего.
- 4 – 10 баллов (Зона тестов и релизов): Получение прямых доказательств в ходе практических экспериментов, юзабилити-тестирований и пилотных запусков.
Понимание своего положения на шкале уверенности позволяет гибко управлять инвестициями: на ранних этапах компания тратит копейки на дешевую проверку гипотез в «синей» зоне мнений, и лишь при подтверждении фактов выделяет бюджет на полноценную разработку в «красной» зоне экспериментов.
🏎️ Скорость разработки против скорости открытий: Баланс в разных компаниях 44:14
Многие продуктовые команды ошибочно полагают, что сбор доказательств драматически замедляет процессы, заставляя выбирать между скоростью написания кода и качеством исследований. Итамар Гилад считает это противопоставление ложным, указывая на то, что компании используют неверную метрику эффективности.
Главным показателем должна выступать не скорость отправки кода в продакшн (time to bits in production), а время до достижения бизнес-результата (time to outcomes). Методы, управляемые доказательствами, в разы эффективнее и быстрее традиционного планирования, поскольку они страхуют команду от многомесячной разработки продуктов, которые в итоге окажутся никому не нужны.
Специфика применения фреймворка напрямую зависит от стадии зрелости компании:
- Ранние стартапы (раунды А и B): На этой стадии построение сложных деревьев метрик может быть избыточным, так как бизнес еще не до конца понимает модель создания ценности. Главная цель стартапа — нащупать Product-Market Fit, постоянно и быстро итерируя бизнес-модель.
- Этап масштабирования (Scale-up): Когда в компанию приходит много людей и денег, возникает хаос. Здесь критически важно выстроить системный, прозрачный порядок оценки идей для удержания фокуса.
- Регрессирующие корпорации: Часто крупные компании, изначально создававшиеся как дата-центричные, со временем деградируют из-за смены менеджмента и бюрократизации культуры (как случилось с Google в период запуска Google+). Для них внедрение GIST — это способ вернуть утраченный дух предпринимательства.
Гилад категорически не рекомендует внедрять весь фреймворк целиком за один квартал, чтобы не вызвать усталость и отторжение у сотрудников. Начинать трансформацию нужно локально, выявив самую болезненную зону в текущих процессах.
🧪 Уровень Steps: Как тестировать идеи без написания кода 50:13
Слой Steps (Шаги) призван научить команды снижать стоимость проверки продуктовых предположений. Огромной ошибкой Итамар называет создание громоздких MVP, которые на деле превращаются в полноценные, дорогие в разработке продукты, являющиеся по сути обычными бета-версиями двадцатилетней давности. Вместо этого процесс валидации должен двигаться по цепочке от простых шагов к сложным:
- Оценка (Assessment): Первичный экспресс-анализ на соответствие целям, ICE-скоринг, картирование рисков по методике David J. Bland (Assumption Mapping) и выявление ограничений на встречах со стейкхолдерами.
- Поиск фактов (Fact finding): Работа с накопленной внутренней аналитикой, проведение целевых опросов, качественные интервью с пользователями и полевые исследования.
- Тесты и эксперименты (Tests & Experiments): Создание имитаций продукта до написания бэкенда.
В качестве иллюстрации беспрецедентной эффективности «фальшивых» тестов Гилад привел историю разработки интерфейса вкладок в Gmail. Самый первый прототип сортировщика писем был создан исследователями и дизайнерами без единой строчки программного кода. Они разработали интерактивный HTML-фасад, имитирующий работу почты. В ходе интервью модератор на некоторое время отвлекал внимание пользователя, а в этот момент команда за кулисами вручную переносила тему и отправителя первых 50 писем реального инбокса респондента во вкладки «Промоакции» или «Соцсети».
Когда пользователю возвращали экран, он видел идеально структурированную личную почту и приходил в восторг. Этот классический тест «Волшебник страны Оз» (Wizard of Oz) предоставил неоспоримые доказательства ценности фичи задолго до привлечения дорогостоящих инженеров по машинному обучению.
Лишь после успешного прохождения стадии «фальшивых» тестов команда может переходить к среднеуровневым испытаниям: запуску альфа-версий, программ раннего доступа и внутреннему тестированию на уровне подразделения (fish food). Итамар Гилад с улыбкой отмечает, что термин fish food («корм для рыбок») является локальным жаргонизмом внутри Google, обозначающим ультралокальное тестирование фичи внутри непосредственной команды разработки, предшествующее классическому общекорпоративному dogfooding.
