DoorDash's v1 was 8 PDF menus on a static HTML website

Первая версия DoorDash — это 8 PDF-меню на статичном HTML-сайте

Пересматриваем стратегию Minimum Viable Product, её сильные и слабые стороны

Продукт DoorDash, версия 1.0Многие из вас, возможно, знают, что я занят организацией a16z speedrun — нашей 12-недельной программы в SF/LA, в рамках которой мы инвестируем до $1M в seed/pre-seed стартапы. В рамках этого я пригласил выступить перед стартапами целый ряд выдающихся основателей, включая основателей Figma, Supercell, Zynga, Carta, Twilio и многих других, и мне выпала возможность провести Q&A с Tony Xu о ранних днях DoorDash. И там была забавная и поучительная история о том, как всё начиналось.

Вот так выглядела «версия 1.0» DoorDash:

статичная HTML-страница8 ресторанных меню в PDFномер Google Voice, который перенаправлял звонок на одного из основателейпервоначально называлось «Palo Alto Deliveries»на сборку ушло всего 45 минут

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

Это эссе могло бы быть просто притчей о запуске нового продукта и о пользе Minimum Viable Product. Но я здесь не для того, чтобы вас утомлять, поэтому мы не будем говорить обо всех преимуществах MVP — эта идея стала частью стартап-лексикона после того, как Eric Ries популяризовал её в своей книге The Lean Startup.

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

Проблемы, преследующие MVPЭто важные вопросы, наряду с рядом распространённых проблем, которые постоянно подставляют подножку, когда MVP применяется на этапе zero-to-one в разработке продукта. Продуктовые команды часто сталкиваются с такими сложностями:

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

… и многое другое.

К этому моменту многое из этого, вероятно, кажется знакомым. И теперь вы видите настоящую тему этого эссе: мы здесь, чтобы поговорить обо всех бесконечных проблемах и спорах, которые возникают при попытке внедрить MVP как часть стратегии разработки продукта, — чтобы вы увидели, что это не серебряная пуля.

Начнём с нескольких наблюдений о тестировании и интерпретации результатов:

будьте готовы к тому, что большинство ваших тестов окажутся неубедительными. Процесс zero-to-one при создании новых продуктов — это жёсткое испытание: в основном это череда повторяющихся неудач, особенно если вы работаете в новой категории. Одна особенность, которую вы заметите в v1 продуктов: их результаты, как правило, заканчиваются неоднозначно (и со смещением в негативную сторону). Ваш продукт провалился, потому что вы не сделали достаточно функций? Или, может быть, брендинг был неудачный? Или просто нужен был более качественный онбординг? Будьте готовы к тому, что ваша продуктовая команда будет буксовать на месте после каждого провалившегося эксперимента. Чтобы эти провалы были полезны, нужно реально провести чистый тест, ведущий к выводу. Если наиболее вероятный исход — провал, вам нужно как минимум иметь возможность вычеркнуть несколько гипотез и, может быть, увидеть проблеск успеха. Это естественно ведёт к стратегиям вроде тестирования по одной вещи за раз и превращения One Main Feature в ядро продуктового опыта. Если эта фича похоронена под кучей других вещей, результаты окажутся неубедительными.ложноотрицательные результаты приводят к ложным перезапускам. Самый опасный исход в продуктовом тестировании — получить ложную информацию, и она чаще всего приходит в виде ложноотрицательных результатов, учитывая упомянутое выше: новые продукты — это про череду неудач. Слишком минимальные MVP часто проваливаются, потому что выглядят слабо на фоне существующих продуктов — у них скудные фичи, брендинг и UX. Получаемые метрики вовлечённости, скорее всего, ударятся о дно по сравнению с тем, что вы увидели бы после надлежащей итерации и шлифовки. И вот настоящая проблема: вы можете ошибочно заключить, что всё направление продукта — бесполезное. Это вдвойне опасно: вы не только можете отказаться от потенциально перспективного пути, но и, накопив несколько таких ложноотрицательных результатов, скорее всего, разочаруетесь и сдадитесь. Это запускает полный продуктовый ресет, когда вы пивотите в совершенно новое направление и начинаете всё сначала. Это цикл экспериментирования, который даёт крайне мало реального инсайта о рынке.будьте готовы запускать, потом перезапускать, потом перезапускать снова. Какая у вас стратегия? Разумеется, каждый тест MVP требует, чтобы вы провели следующий, контрольный тест. Так вы сможете перепроверить инсайт, развивая его, уточняя и проверяя, действительно ли существует причинно-следственная связь, о которой вы предполагали. Но провести контрольный тест сложно, потому что ваши существующие пользователи уже «загрязнены» предыдущим тестом — так что же делать? Возможно, они отвергнут v2 продукта, потому что уже попробовали v1. Поэтому вам понадобится какой-то процесс экспериментирования, при котором вы можете подтягивать новых пользователей из waitlist и помещать их в новый опыт. Или, если у вас социальный продукт, вы захотите подключать различные обособленные команды к вашему инструменту коллаборации или разные школы — к вашему мессенджеру. Если у вас нет чёткой стратегии, позволяющей тестировать на десятках когорт, вы будете ограничены в числе тестов, которые сможете провести, и в скорости обучения.

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

Я решительно предпочитаю этот подход прокладыванию пути в совершенно новые продуктовые категории. С новой категорией вы понятия не имеете, есть ли там вообще «that there there». Даже если вы итерациями дойдёте до на вид жизнеспособного продукта, нет никакой уверенности, что у него будут нужные вам бизнес-характеристики. Возьмём, к примеру, travel-продукты — присущая им низкая частота использования и высокий CAC фундаментальны для категории. Вы можете узнать это горьким путём через итерации, либо распознать эти характеристики заранее, понимая рыночную динамику.

MVP могут подходить, а могут и не подходить вашей продуктовой категории и стадииКак я упоминал в начале эссе, для AI-продуктов и концепции MVP настало странное время. Что значит сделать MVP foundation-модели, когда начальные шаги по её созданию могут требовать сотни миллионов долларов затрат на обучение и R&D? Может быть, дело лишь в том, что «M» в MVP в этом случае получается довольно большой, но я думаю, эта идея всплывает в ряде ситуаций, потому что MVP зависит от рынка.

Вот что я имею в виду:

MVP — это часто нормальные, но не великие продукты, а нормальные продукты проигрывают на зрелых рынках. Строить мобильное приложение сейчас — это не то же самое, что в 2010 году, когда приложения были в новинку: сегодня ваши клиенты ожидают сильного дизайна и полировки, и вы, вероятно, конкурируете с большим числом уже существующих приложений. Сравните это с самыми ранними днями мобильных приложений, когда конкуренция была низкой и даже наспех собранные мелкие приложения могли выстрелить (например, всевозможные фонарики и pukko-приложения). MVP часто сталкиваются с проблемой: они хорошо конкурируют на ранней фазе S-кривой, когда фичи «оно работает» уже достаточно, и минимальное действительно может быть минимальным. Но меня не удивляет, что продукту вроде Figma или Notion потребовалось 4+ года на построение v1, потому что ожидания в их соответствующих категориях гораздо выше. Более того, великие продукты часто требуют той дополнительной полировки, которая ощущается как почти низкая ROI, — но лояльные, повторно возвращающиеся пользователи нередко видят и ценят всю эту полировку, и крошечные кусочки ROI накапливаются за долгое время. Это привело к наблюдениям, что многие продукты, следующие теории MVP, в итоге получают паршивый UX, на который итеративно прикручены заплатки, — если только команда не возьмёт реальную паузу, чтобы всё отшлифовать по мере сходимости.некоторые категории просто требуют больших стартовых вложений. Это могут звучать как крайние примеры, но представьте стартапы, нацеленные на создание новых ядерных реакторов, сверхзвуковых самолётов, методов лечения рака или человекообразных роботов. Хотя клиенты явно появились бы, если бы вам удалось построить эти продукты, потребовались бы сотни миллионов или даже миллиарды долларов только на создание первой работающей версии, которую кто-то реально купил бы. Это не значит, что стартапы в этих категориях не могут стать чрезвычайно ценными — могут, безусловно. Но реальность такова, что они требуют огромного стартового капитала, R&D-ресурсов и времени. Вы просто не можете создать по-настоящему минимальный V1 в этих областях. И это нормально. Это, очевидно, крайние примеры, но мы видим похожие паттерны и в других категориях. AI foundation model стартапы, о которых мы говорили ранее, разделяют некоторые из этих характеристик. Это просто к тому, что MVP может быть невозможен и может быть не самым подходящим инструментом в таких случаях. И тем не менее эти новые продуктовые идеи всё ещё могут быть потрясающими возможностями.легко создать чрезмерную опору на данные в ущерб подлинному пониманию клиента. За последнее десятилетие в tech мы видели, как метрики стали доминировать над качественными инсайтами в продуктовой стратегии. Это естественно, учитывая наш доступ к A/B-тестированию, аналитике и системам вроде OKR, которые задают строгую дисциплину исполнения по всей продуктовой организации. Проблема в том, что доминируют те данные, которые легко измерить, — не обязательно те, что определяют значимые продуктовые исходы. Хотя такие инкрементальные метрики могут помочь масштабировать уже успешный продукт, их попросту недостаточно для zero-to-one продуктов, которым нужно вырасти на порядки, чтобы стать релевантными. Продуктовым лидерам нужно понимать настоящую рыночную возможность, делать сложные выборы по направлению, а затем использовать эти количественные инструменты для оптимизации, как только большая стратегическая цель уже задана.

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

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

Что всё это означает для MVP сегодня?Чтобы было ясно: мои опасения по поводу MVP не следует трактовать как полное отрицание концепции. Я часто первым говорю компаниям, которые в изоляции строят продукт 12+ месяцев: «уже выкатите хоть что-нибудь», — или советую выбирать продуктовые области, где выпуск V1 действительно реализуем.

Однако я всё более скептичен в отношении некоторых подходов к валидации продукта, которые сам ранее отстаивал: лендинги со сбором email, метрики тяги в соцсетях или вирусные превью-видео — на вид они указывают на рыночный интерес, но редко переводятся в реальную «прилипаемость» продукта. Главное — решать существующие проблемы клиентов, такие, у которых, вероятно, есть прецеденты и текущие решения на рынке, а не пытаться создавать совершенно новые категории с нуля. Романтическая идея «остроумно придумать, выпустить MVP, прицелиться в перспективную фичу, выпустить ещё один MVP и так до бесконечности» часто приводит команды к бесконечным итерациям без направления. Вместо этого продуктам нужна стратегическая стартовая точка на привлекательном рынке — обычно валидируемая наличием других игроков в этой области.

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

Я начал это эссе с того, что подсветил изящный MVP-эксперимент DoorDash, и хотя мой короткий 40-секундный пост резонировал со многими читателями, он лишь царапает поверхность. Полное интервью с Tony длилось почти час и раскрывало бесчисленные итерации и тесты, которые они провели, прежде чем найти product-market fit. Прошло несколько лет, прежде чем траектория DoorDash стала ясной, — напоминание о том, что стартап-путь — это длинная и тяжёлая дорога. Я благодарен Tony за то, что он поделился этими инсайтами во время нашей сессии a16z speedrun, дав редкий взгляд на методичный процесс за тем, что теперь стало именем нарицательным. Более длинная версия интервью с DoorDash здесь.