Перейти к содержанию
Публикация AiManual

От MVP до миллиарда пользователей: разбор сессии Google о продуктовых решениях на TechCrunch Disrupt 2026

Вице-президент по продукту Google Search Робби Стайн проведёт на TechCrunch Disrupt 2026 fireside chat о том, как меняются продуктовые решения при масштабирован

Коротко

Что будет в материале

  1. 01

    Что за сессия и почему она важна для продуктовых команд

  2. 02

    Как продуктовые решения меняются при масштабировании: ключевые оси

  3. 03

    Какие инстинкты раннего этапа помогают, а какие мешают на масштабе

  4. 04

    Как это применить к AI-продуктам: от локальных LLM до агентов

TechCrunch Disrupt 2026 пройдёт 13-15 октября в Moscone West в Сан-Франциско. На сцене Builders Stage вице-президент по продукту Google Search Робби Стайн проведёт fireside chat «From MVP to Billions of Users: How Product Decisions Must Change at Scale»: разговор о том, как меняются продуктовые решения, когда команда растёт от первых пользователей до миллиардов (анонс TechCrunch Disrupt).

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

Оговорка по фактам: сессия ещё не прошла, её тезисы и цитаты не опубликованы. Всё дальше в тексте - разбор заявленной темы, карьерного пути спикера и практических выводов для команд, которые масштабируют AI-продукты.

Что за сессия и почему она важна для продуктовых команд

Disrupt возвращается в Moscone West в Сан-Франциско 13-15 октября и собирает более 10 000 стартапов, инвесторов и технологических руководителей. В программе заявлено 250+ спикеров и 200+ сессий, а выступление Стайна стоит на Builders Stage - сцене, ориентированной на основателей и продуктовые команды, а не на корпоративные презентации.

Практическая польза, по формулировке анонса, не в копировании процессов Google. Ценность в разборе решений за этими процессами: где скорость даёт преимущество, где без дополнительной осторожности не обойтись и как понять, что способ разработки пора менять вместе с продуктом. Для команд, которые добавляют генеративный AI в свои продукты, это ровно тот набор вопросов, который обычно откладывают до первого серьёзного сбоя.

Кто такой Робби Стайн и почему его опыт релевантен

Карьерный путь Стайна соединяет два разных мира. Он соосновал и возглавлял Stamped, стартап социальных рекомендаций, который купил Yahoo. Затем пять лет руководил потребительскими продуктами в Instagram, где помогал строить и масштабировать продукты и команды за Stories, Feed, Direct Messaging и Reels. До возвращения в Google в 2024 году он был head of product в Artifact, AI-powered newsfeed. Сегодня он занимает должность вице-президента по продукту Google Search и работает над генеративными AI-продуктами и опытами внутри поиска.

Комбинация делает его подходящим спикером для темы масштабирования. Основатель стартапа знает, как выглядит скорость, когда ошибка стоит одного недовольного пользователя. Руководитель продуктов Instagram и Google Search знает, как выглядит цена ошибки, когда решения затрагивают миллиарды людей.

  • Stamped: ранняя стадия, поиск product-market fit, продажа Yahoo.
  • Instagram: масштабирование форматов - Stories, Feed, Direct Messaging, Reels - и команд под ними.
  • Artifact: лента новостей на генеративной модели.
  • Google Search: генеративные функции в продукте с аудиторией в миллиарды пользователей.

Формат и ключевые вопросы сессии

Fireside chat означает живой диалог с модератором: вопросы задают из зала, а тезисы рождаются по ходу разговора. Заранее зачитанного доклада с готовыми фреймворками ждать не стоит.

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

Как продуктовые решения меняются при масштабировании: ключевые оси

Три оси ниже - рамка для размышления, собранная из заявленных вопросов сессии и карьерного опыта спикера. Это не конспект выступления и не универсальный рецепт: в каждой команде пропорции свои.

Скорость против доверия: где ускоряться, а где притормозить

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

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

Для AI-продуктов критерий уточняется. Ошибка в подсказке при вводе запроса и ошибка в медицинской или юридической справке стоят по-разному, и одинаковый уровень контроля для них не подходит.

Инновации против надёжности: как добавлять новое, не ломая привычное

Новый формат не обязан вытеснять старый. В Instagram Stories появились рядом с лентой Feed, а не вместо неё, и это дало новое поведение, не отбирая привычное. Логика переносится на генеративный AI: ответ модели стоит рядом с классической выдачей, а не отменяет её.

Механика rollout выглядит так: ограниченный тест на лояльной аудитории, затем постепенное расширение с возможностью отката, и только потом включение по умолчанию для всех. Такой порядок дороже по времени, зато сбой остаётся локальным.

Экспериментирование на масштабе: как не потерять инстинкт основателя

Экспериментирование не исчезает при росте, оно меняет форму. Вместо «сделали и посмотрели» появляется гипотеза с метрикой, сроком проверки и ограниченным радиусом влияния. Разница принципиальная: в стартапе провал эксперимента никто не замечает, в продукте с миллионами пользователей его замечают сразу.

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

Какие инстинкты раннего этапа помогают, а какие мешают на масштабе

Ревизия собственных привычек при росте продукта - не критика прошлого опыта, а естественная эволюция. Часть установок основателя работает годами, часть начинает тормозить команду.

Что переносится из стартапа в большой продукт

Три вещи остаются ценными на любом масштабе: ориентация на проблему пользователя, скорость обучения и умение расставлять приоритеты. Продукты, которые Стайн помогал строить и масштабировать в Instagram, начинались как эксперименты внутри компании. Похожая логика применима в Google Search, где генеративные функции добавляются к продукту со сложившимися привычками аудитории.

Четвёртая установка - готовность работать с неопределённостью. На раннем этапе непонятно, сработает ли гипотеза вообще, и это нормальное состояние, а не признак плохого планирования.

Что приходится менять: от ручного управления к системным решениям

Основатель на старте может лично просмотреть каждую фичу перед релизом. В Google Search такой подход невозможен физически: число изменений велико, а решения затрагивают миллиарды пользователей. На смену ручному контролю приходят процессы, метрики, делегирование и автоматизированный контроль качества.

Инстинкт раннего этапаЧто с ним происходит на масштабеЧто делать
Проверять каждую фичу личноСтановится физически невозможнымАвтоматизировать регрессионные тесты и мониторинг качества
Решать по интуицииИнтуиция не покрывает разнородную аудиториюФормулировать гипотезу и метрику до релиза
Выпускать быстро и править на летуСбой получает огласку быстрее, чем приходит фиксЗакладывать механизм отката и постепенный rollout
Держать всё в одной головеПортфель продуктов и сценариев растётДелить ответственность между командами, сохраняя общий критерий качества

Как это применить к AI-продуктам: от локальных LLM до агентов

Те же оси работают для любой AI-фичи, будь то облачная функция или модель, запущенная локально. Разница в цене ошибки и в ресурсах на её исправление. Программу AI Stage на Disrupt 2026 с близкими вопросами разбирает отдельный материал AI-Manual, а сдвиги вокруг безопасности агентов и GTM-инжиниринга - в этом разборе.

Чек-лист для масштабирования AI-фичи

  1. Какова цена ошибки для пользователя? Галлюцинация в разговорном ассистенте и в юридической справке стоит по-разному.
  2. Есть ли механизм отката? Возможность отключить фичу или вернуть прошлую версию промпта и модели должна существовать до релиза.
  3. Как измеряется качество ответов? Без набора проверочных примеров и метрик рост нагрузки превращает редкие ошибки в регулярные.
  4. Готовы ли вы к нагрузке? Для локальных LLM всё упирается в VRAM и пропускную способность GPU, для облачных - в стоимость токенов и лимиты API.
  5. Как собирается обратная связь? Канал жалоб и разметка плохих ответов дают материал для следующей итерации.
  6. Есть ли план постепенного rollout? Тест на ограниченной группе, затем расширение.

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

Ограничения и риски: о чём говорит опыт Google

Масштаб не лечит ошибки генеративных моделей, а усиливает их последствия. Чем больше пользователей, тем больше редких случаев и тем заметнее систематические провалы качества. Большой продукт замечает проблему раньше, но и огласка приходит быстрее.

В некоторых пересказах фигурирует утверждение, что AI Mode в Google Search превысил 1 млрд месячных пользователей спустя год после запуска. В анонсе сессии, который используется как источник в этом материале, такой метрики нет. Принимать её за подтверждённый факт не стоит.

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

Практическая ценность сессии для основателей и продактов

Готовых рецептов сессия не даст. Даст рамку: когда подход к разработке пора менять, какие компромиссы придётся принять и как отличить полезное ускорение от опасного.

Кому точно стоит смотреть

Основателям на стадии роста - чтобы понять момент, когда ручное управление продуктом перестаёт работать. Продакт-менеджерам - чтобы получить критерии решений про скорость и контроль качества. Техническим лидерам, которые добавляют AI, - чтобы осознанно принять компромиссы между новизной и надёжностью.

Если вы только собираете первый MVP, сессия даст ориентир на будущее, но не решит текущих задач. Если продукт уже растёт, это возможность сверить свои решения с опытом человека, который проходил путь от Stamped до Google Search.

Как получить максимум от сессии

Сформулируйте до начала разговора три вопроса о своём продукте: где вы сейчас переплачиваете осторожностью, где, наоборот, рискуете доверием, и какое решение вы откладываете из-за страха ошибиться. Записывайте конкретные примеры из Instagram и Google Search, а не общие принципы: именно примеры переносятся на свою команду.

Логистика: цены на билеты повышаются 25 сентября в 23:59 по тихоокеанскому времени, до этого момента экономия достигает 200 долларов, а групповые пропуска от четырёх человек дают скидку до 30 процентов дополнительно. Если поездка не входит в планы, остаются записи и репортажи с площадки.

Начните с малого: возьмите одну AI-фичу из своего продукта и прогоните её по чек-листу из шести вопросов. Ответы про цену ошибки, откат и метрики качества покажут, готовы ли вы к следующему шагу масштабирования или пока стоит удержать фичу в песочнице.

Подписаться на канал