Airtable's Path to Product-Market Fit

Сегодня на The Review мы рады запустить совершенно новую серию о product-market fit, которую ведёт партнёр First Round Todd Jackson (бывший VP of Product в Dropbox, Product Director в Twitter, сооснователь Cover и PM в Google и Facebook). Джексон подробнее рассказывает о том, что вдохновило его на эту серию, во вступительной заметке ниже, но если вы хотите сразу перейти к нашему первому интервью с сооснователем Airtable Эндрю Офстадом, нажмите сюда.

Product-market fit — одно из самых важных и в то же время неуловимых понятий в построении компании. Это не чёткая метрика, которую можно измерить, и не веха, которую легко вычеркнуть из списка дел. Я воспринимаю product-market fit как тот переломный момент, который чувствуешь как основатель, когда переходишь от «навязывания» продукта людям к тому, что они сами «выхватывают» его у тебя из рук. Но путь к этому глубоко индивидуален. Дорога одного основателя к product-market fit может выглядеть совершенно иначе, чем у другого, и при этом оба пути могут быть абсолютно правильными — а это затрудняет понимание того, какие уроки можно извлечь, когда смотришь со стороны.

В последние годы число статей на эту тему явно выросло, однако на удивление мало по-настоящему полезной информации о конкретных шагах, необходимых для обретения product-market fit. Те рекомендации, что существуют, либо слишком жёсткие, потому что основаны на опыте одного человека, либо слишком общие, чтобы их можно было применить на практике.

Поиск PMF был постоянной темой на протяжении всей моей карьеры, поэтому я прошёл этот путь на собственном опыте — выводил Gmail из беты к более чем 200 миллионам пользователей в роли PM и основал собственную компанию Cover ещё в 2013 году. Теперь, будучи партнёром First Round, я провожу дни, помогая основателям справляться именно с этим вызовом.

В последнее время я вижу, что поиск product-market fit приобретает всё большую срочность, поскольку привлекать последующие раунды финансирования становится сложнее, а давление с целью достичь блестящих метрик нарастает. Поэтому большую часть этого года я провёл, беря интервью у основателей, которые уже преодолели этот барьер, чтобы помочь основателям на более ранних стадиях. (Загляните в пост о валидации стартап-идей, которым я поделился ранее в этом году в Lenny’s Newsletter, или в несколько эпизодов подкаста In Depth, которые я вёл в качестве приглашённого ведущего на эту тему.)

Сегодня я рад сообщить, что объединяю усилия с командой First Round Review для новой серии, посвящённой тому, чтобы рассказывать больше таких историй. Мы уже поделились несколькими замечательными материалами здесь, на The Review — например, широко известным руководством по PMF от Superhuman и Rahul Vohra — и я рад внести вклад в пополнение нашей коллекции советов на эту тему.

Вот чего вы можете ожидать: каждые две недели я буду делиться интервью с основателем, чтобы вы могли услышать о самых поворотных моментах на их пути к product-market fit — от того, как они наткнулись на идею своей компании, до их первого «ага-момента» и всех мельчайших деталей между ними.

Я буду беседовать с десятками основателей разного бэкграунда, из разных вертикалей и на разных стадиях, чтобы показать многообразие путей к PMF. Хотя единого сценария или рецепта, которому можно следовать, не существует, я твёрдо убеждён, что многому можно научиться, реконструируя фреймворки и тактики, на которые опирались другие, чтобы добиться большого успеха. Моя догадка в том, что, если мы соберём достаточно историй, мы сможем начать выделять темы, паттерны и инсайты, которые можно использовать, чтобы давать советы, действительно помогающие основателям дойти до PMF.

Надеюсь, вы будете следить за серией. Не стесняйтесь делиться любой обратной связью со мной в Twitter или предлагать идеи гостей для будущих интервью!

А теперь давайте перейдём к моему первому интервью — с Эндрю Офстадом из Airtable.

— Todd Jackson

ПЕРЕМАТЫВАЯ ЧАСЫ К ИСТОРИИ AIRTABLE:

После десятилетия построения компании у команды Airtable есть чем похвастаться. Low-code платформа может похвастаться клиентской базой из более чем 300 000 организаций, включая такие, как Amazon, Baker Hughes, Netflix и Nike. По сути, поразительные 80% компаний из Fortune 100 используют Airtable.

Движение low-code прочно закрепилось, компания нацелена на глобальную экспансию (открывает свою первую международную штаб-квартиру в Лондоне), а команда привлекла $1,36 млрд инвестиций при оценке в $11 млрд.

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

В 2012 году Andrew Ofstad и его сооснователи Howie Liu и Emmett Nicholas отправились в то, что стало «медленным строительством». В своей нынешней роли Офстад возглавляет долгосрочные продуктовые ставки компании, но сегодня он возвращает нас к самому началу, прослеживая путь Airtable к product-market fit.

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

ИССЛЕДОВАНИЕ ИДЕЙ И ВАЛИДАЦИЯ ВИДЕНИЯ:

Фаза «от −1 к 0» в построении компании может принимать самые разные формы. Некоторые команды основателей довольно быстро сплачиваются вокруг конкретной идеи, тогда как другие тратят несколько месяцев на изучение совершенно разрозненных отраслей. У троицы из Airtable раннее видение было широким, но имело чёткую конечную цель.

«Ранним видением была демократизация создания софта. Мы все чувствовали, что обладаем этой безумной суперсилой — умением создавать программы, что давало нам преимущества в карьере. Можно оказывать огромное влияние в организации — даже не будучи на руководящей должности — создавая софт и разворачивая его для людей. Так что в широком смысле мы исследовали, как сделать создание софта проще для непрограммистов», — говорит Офстад.

Бóльшая часть этого вдохновения коренилась в истории вычислительной техники. «Ранние дни вычислений сводились к использованию этих загадочных командных строк для управления компьютером. Лишь благодаря графическому интерфейсу Xerox PARC и Apple Mac вычисления стали более доступными для всех. Мы хотели сделать то же самое для софта — дать каждому стек программного обеспечения, поверх которого он мог бы строить полезные программы».

Но иметь идею на руках недостаточно — оценка её перспективности становится следующим критическим барьером, который начинающим основателям нужно преодолеть. Как доказать себе (и другим), что у неё есть будущее?

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

Не гонитесь за модой: «Мы были немного контрарианцами. В то время всё крутилось вокруг Lean Startup, получения ранней валидации от клиентов и быстрого провала. Ходившая по рукам книга под названием „The Four Steps to the Epiphany“ проповедовала эту модель экономной разработки компании, при которой ты выпускаешь супер-сырой прототип, чтобы узнать клиента и быстро сделать пивот», — говорит он. «Мы взяли скорее подход с точки зрения первооснов — мы не хотели просто кидать что попало в стену, поэтому очень глубоко погрузились в проблему, прежде чем формально приступить к строительству продукта и попыткам заполучить клиентов».Изучите предшествующие наработки: «Нам было интеллектуально интересно идти по этому пути в общем пространстве создания софта. Поэтому мы потратили много времени на исследования. Это было почти как саббатикал — мы читали все эти наработки старых пионеров вычислений, таких как Douglas Engelbart и Bill Atkinson, и даже современников, таких как Bret Victor. Мы играли со старыми продуктами, такими как HyperCard, в которых были оттенки создания софта для всех, и много читали о том, как визуализировать сложные системы».Оцените потенциал и нащупайте возможности: «Мы потратили много времени, размышляя: „Какой здесь рынок?“ Электронные таблицы существуют целую вечность, но большую часть времени люди используют их для отслеживания объектов: людей, компаний, простых таблиц. Они не занимаются моделированием и числовыми расчётами, для которых таблицы были изобретены», — говорит Офстад. «А когда Хоуи работал в Salesforce, он больше узнал о рынке корпоративного софта и увидел, что бóльшая часть существующих бизнес-приложений — это, по сути, просто базы данных с представлениями и бизнес-логикой поверх, и в вертикальном софте много изобретения велосипеда. Так мы увидели бизнес-потенциал того, как Salesforce — эта гигантская платформа — была более или менее просто гибкой базой данных. Но нужно было быть продвинутым админом, чтобы понять, как её настраивать и строить. Мы увидели потенциал в том, чтобы открыть такого рода создание софта гораздо большему рынку».Убедитесь, что вы преданы делу: «Мы не торопились на раннем этапе, чтобы убедиться, что это то, чему мы по-настоящему привержены. Если вы собираетесь браться за горизонтальный продукт, который довольно сложно продвигать и для которого нужно построить много всего, чтобы дойти до MVP, я бы рекомендовал потратить это время, чтобы убедиться, что вам по-настоящему интересна проблемная область и нравятся люди, с которыми вы работаете. Нам было бы трудно достичь такого уровня убеждённости без этого периода глубокого погружения в проблему».

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

ПОСТРОЕНИЕ РАННЕГО ПРОДУКТА: МЕДЛЕННЫЙ ПУТЬ ОТ ПРОТОТИПА К ЗАПУСКУ

«Первая версия пыталась доказать, что мы можем сделать базу данных простой в использовании. Это было что-то вроде прототипа — много дыма и зеркал. Мы сосредоточились на 100% на UI и взаимодействиях. У нас по сути не было бэкенда, всё просто сохранялось в локальное хранилище и браузер — достаточно, чтобы убедиться, что мы можем протестировать взаимодействия и дойти до точки, где люди могли с этим поиграть. Мы хотели показать это людям и попросить их попробовать что-то организовать и посмотреть, смогут ли они действительно это сделать», — говорит Офстад.

Дифференциация продукта была ключом к успеху Airtable, но та ранняя версия подозрительно напоминала электронную таблицу. «Под капотом это была, очевидно, база данных, но мы переняли интерфейс таблицы, знакомый большинству работников умственного труда», — говорит он. «Мы встроили много таких же взаимодействий, хотя у нас были типизированные поля, таблицы и связи между ними по внешним ключам. Но для многих людей это просто не „щёлкало“. Нам потребовалось много итераций и таких вещей, как создание шаблонов, чтобы это ощущалось по-другому».

Вот пример: «Даже более мелкие детали, вроде полей с цветными вариантами выбора, помогали передать ту ментальную модель, что ты имеешь дело с записями, а не с таблицей. Мы также всегда делали акцент на прямом манипулировании, создавая ощущение, что можно протянуть руку и коснуться своих данных. Когда мы впервые сделали вложения, они шли с функцией drag-and-drop, потому что мы хотели, чтобы это ощущалось супер-интерактивно, так что мы вложили много усилий в архитектуру реального времени».

Несмотря на эти первоначальные трудности, всё же была аудитория ранних последователей. «Это были программисты или люди, работающие с базами данных, скорее персона „мастеровитого энтузиаста“, очень структурированно мыслящего», — говорит он. «У нас был друг — видеопродюсер, и он начал отслеживать свои видеопроизводства, создавая таблицы со своими актёрами и съёмочной группой и связывая их между собой».

Многие основатели могли бы поддаться искушению закинуть сеть пошире и привлечь больше пользователей на продукт — но Офстад снова предостерегает от слишком быстрого движения здесь. Имея лишь отдельные очаги тех «щёлкающих» клиентских моментов, команда Airtable понимала, что путь к запуску будет необычно медленным.

Оценивая свой собственный таймлайн, Офстад рекомендует сделать шаг назад и переосмыслить, действительно ли публичный запуск поможет вам достичь критически важной цели на этом раннем этапе. «Мы были сосредоточены на том, чтобы как можно раньше снять главный риск для компании. Для нас на раннем этапе это было: „Как нам на самом деле сделать эту базу данных доступной для непрограммистов?“» — говорит Офстад. «Это означало, что всё сводилось к тому, чтобы сделать её простой в использовании, итерировать прототип и получать много обратной связи. Казалось, что публичный запуск продукта на самом деле не дал бы нам больше данных и не ускорил бы путь к этой цели».

Разделите понятие получения обратной связи от клиентов и доработки продукта от понятия публичного запуска.

Офстад разбирает, как этот принцип работал на практике:

Альфа: оставайтесь экономными, пока снимаете свой главный риск.

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

Помимо отсрочки публичного запуска, эта стратегия также удерживала команду сравнительно компактной — избегая ловушки ранней стадии в виде избыточного найма. «Эту работу в фазе альфы было бы действительно трудно распараллелить. Нельзя нанять кучу инженеров, чтобы ускорить это. На самом деле было бы контрпродуктивно пытаться сильно масштабировать это, потому что нам нужно было выверить тот фундамент базы данных. Наём кучи людей затруднил бы гибкость и смену направления этого фундамента», — говорит он.

Если вы строите похожий тип продукта, совет Офстада — держать петлю обратной связи предельно тесной и ослабить ожидания относительно того, как «должен» выглядеть ваш MVP. «Мы садились с нашими клиентами, чтобы увидеть, для чего они используют продукт. С горизонтальными продуктами ты строишь эту очень общую штуку, и самое крутое — видеть, как люди её используют», — говорит Офстад.

MVP для нашего продукта не был чем-то одним. С горизонтальным продуктом ты постоянно открываешь новые сценарии использования.

«По мере добавления новых функций мы открывали новые сценарии использования. Это была медленная раскрутка: добавляешь представление календаря — и вдруг видишь, как люди используют его для маркетинговых задач. Или добавляешь kanban — и видишь, как люди используют его для процессов и пайплайнов».

Бета: тестируй, тестируй, тестируй — но подталкивай себя двигаться быстрее.

«В конце концов мы дошли до точки, где почувствовали себя комфортно, чтобы выпустить продукт в бету и попытаться привлечь больше клиентов. Мы публично запустились на Hacker News в 2014 году. Мы оставили статус беты, чтобы дать себе возможность сделать более крупный публичный пресс-запуск позже, и чтобы этот ярлык беты был на месте на случай, если что-то будет работать не так», — говорит Офстад.

«Оглядываясь назад, возможно, мы прождали немного слишком долго. Вероятно, мы могли бы запуститься раньше и урезать часть функций. Но по большей части мы получили нужные нам знания и запустились, когда были готовы. Мы пытались понять, находит ли продукт отклик у наших клиентов и сможем ли мы справиться с потенциальным дополнительным трафиком. Были ли у нас функции, чтобы люди не теряли данные и чтобы их восстановление не было для нас большой головной болью?»

ВЫСТРАИВАНИЕ GO-TO-MARKET И ОЦЕНКА КОНКУРЕНЦИИ:

«На раннем этапе наш подход к go-to-market был противоположен тому, что делает большинство компаний, — которые начинают с супер-нишевой аудитории, находят её, таргетируют и расширяются на новые рынки», — говорит он.

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

«Но по-настоящему супер-таргетированными в нашем go-to-market мы стали лишь в последние несколько лет», — говорит Офстад. «С тех пор мы стали гораздо более убеждёнными в своих взглядах и сузили апертуру. Сейчас мы в основном сосредоточены на маркетинговых и продуктовых подразделениях с точки зрения того, как мы изначально заходим в компанию. Отчасти это связано с тем, что у нас появилась гораздо более зрелая команда руководителей, помогающая нам всё это оттачивать, — наш CRO Seth Shaw и наш CMO Archana Agrawal» (которая поделилась своими уроками маркетинга в этом предыдущем эпизоде In Depth).

Но путь к этому пониманию был непростым. Вот совет Офстада для коллег — строителей горизонтальных продуктов:

1. Удваивайте ставку на раннюю тягу (осторожно).

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

«Здесь есть баланс, потому что вы также не хотите хвататься за первый же всплывший сценарий использования, особенно если это не то, что будет сильно расти или впишется в ваше долгосрочное видение компании», — говорит Офстад.

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

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

2. Сочетайте функциональное и устремлённое в будущее.

Одним из главных препятствий с горизонтальным продуктом был месседжинг. «За эти годы мы становились всё более и более сфокусированными в том, как описываем проблемы, которые решаем, и сценарии использования, для которых мы хороши. Но до того, как у нас появился product-market fit, описывать продукт в ранние дни было трудно», — говорит Офстад.

«У нас было несколько посылов. Один — „Это способ для вас создавать софт“. Мы всё ещё были в основном просто базой данных. Мы ещё не построили такие вещи, как автоматизации, но именно так мы формулировали миссию. А отдельно мы говорили: „Это гибрид таблицы и базы данных“ или „таблица с мощью базы данных“. Это пришло из того, как нас описывали наши клиенты: „Это простая в использовании база данных“ или „Это таблица, плюс-плюс“». (Отметим, что текст „Show HN“ от 2014 года гласил: Airtable, гибрид таблицы и базы данных в реальном времени.)

3. Картируйте своё внедрение.

Эти истории про «мы просто стали вирусными» в духе product-led growth никогда не особо релевантны для большинства стартапов, которые всё ещё пытаются нащупать тягу. Офстад глубже копает в траекторию роста Airtable:

«Это происходило в виде множества разных S-кривых. Мы начали замечать медиакомпании, где распространялись через сарафанное радио. Или глава производства переходил из Netflix в какую-то другую компанию и приносил инструмент с собой. Это было очень медленно, и лишь примерно к 2018 году рост по-настоящему пошёл по нарастающей», — говорит он.

«Этот функциональный и отраслевой рост через сарафанное радио, в сочетании с тем, что мы строили новые возможности, открывавшие больше сценариев использования, и обладали организационной зрелостью, чтобы расширяться внутри компаний, — всё это наслоилось друг на друга и привело к довольно солидному росту за последние пять лет».

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

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

4. Думайте о ценообразовании как о позиционировании уже на раннем этапе.

«Мы думали о ценообразовании с самых первых дней. Даже во время нашей альфы с первыми очагами пользователей у нас была страница с ценами и несколькими разными планами. Она в основном описывала функции, которые мы ещё не построили, но мы хотя бы хотели обозначить, что это продукт, за который мы будем брать деньги», — говорит Офстад.

«Мы также выбирали ценовые точки с точки зрения позиционирования — как нам позиционироваться относительно ценности, которую, как мы думаем, мы принесём компаниям? Мы устанавливали цены скорее относительно Salesforce и ServiceNow, нежели Evernote и Dropbox. Мы действительно предполагали, что люди будут строить приложения, обеспечивающие важные процессы компании, на Airtable, поэтому хотели ценообразовывать соответственно», — говорит он.

«Чего мы довольно долго не строили, так это собственно биллинговую систему, чтобы брать плату с клиентов. У нас на самом деле было место, спрятанное на одной из страниц настроек, где клиенты могли добровольно ввести свою кредитную карту, но мы с них не списывали. Мы были поражены, потому что некоторые наши клиенты действительно находили это, вводили свои кредитные карты, а затем жаловались нам, что с них не списали деньги», — говорит он.

Хотя это может показаться идеальной проблемой, которую хотелось бы иметь, Офстад отмечает два фактора, которые могут упускаться из виду, когда основатели колеблются, не браться ли за ценообразование слишком рано. «Наши клиенты беспокоились, что Airtable исчезнет. Так что, хотя мы строили ценообразование с маркетинговой точки зрения, было также важно донести, что мы здесь для того, чтобы построить устойчивый бизнес», — говорит он.

«И я думаю, что сам бы отнёсся скептически, если бы начал пользоваться продуктом и было бы неясно, как они зарабатывают деньги. Возникают вопросы: продадут ли они мои данные? Не начнут ли они потом задирать цены? Эта прозрачность на самом деле хороша и для клиента, и помогает выстроить доверие к продукту».

5. Держите голову повёрнутой вперёд, когда дело касается конкуренции:

«Нам повезло выбрать пространство, в котором на раннем этапе не было большой конкуренции, дышащей нам в затылок. Конечно, у нас были сопоставимые продукты и заменители, которыми пользовались клиенты, вроде таблицы или приложения для управления проектами, но это были совсем другие типы продуктов», — говорит он. «Честно говоря, no-code как такового в 2012 году ещё не существовало, а B2B-софт для продуктивности не был особо привлекательным — всё крутилось вокруг потребительского социального. Это дало нам ландшафт, где не было большой прямой конкуренции».

Это, разумеется, больше не так. Но рост конкуренции не смущает Офстада. Вместо этого вот его философия: «Я раньше бегал кросс и занимался лёгкой атлетикой в старшей школе, и мой тренер всегда говорил: „Не оглядывайся назад. Ты замедлишься. Просто держи голову повёрнутой вперёд и чувствуй, что делают конкуренты, но не зацикливайся на этом слишком сильно, потому что потеряешь из виду, куда идёшь“», — говорит он.

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

Оставаться подкованным в хороших продуктах и трендах в более широкой экосистеме — крайне важно. Но это отличается от того, чтобы фокусироваться на ваших прямых конкурентах и впадать в близорукое состояние: „О, нам надо построить это, потому что они сделали“. Это контрпродуктивно.

ОБРЕТЕНИЕ ТЯГИ: «АГА»-МОМЕНТ С КЛИЕНТОМ

Product-market fit — это не единичный момент во времени, и к тому же это движущаяся мишень. Но, оглядываясь назад, у основателей, как правило, бывает «ага»-момент, когда всё встаёт на свои места.

«Есть пара разных вех, которые выделяются. Когда ты впервые видишь, как один человек получает ценность от продукта, — как наш друг, использовавший нас для видеопроизводства. Или когда ты впервые видишь, как команда использует нас и получает от этого ценность, — у нас была некоммерческая организация человек на 10 или 15, которая рано начала использовать нас для управления всеми своими заявителями», — говорит он.

Но момент, который запал Офстаду, был куда более ощутимым. «Мы зашли в WeWork, и продукт вирусно разросся внутри компании, охватив её более или менее сплошь. Когда я был в этом клиентском туре в Нью-Йорке — после того как в основном взаимодействовал с клиентами через канал поддержки или Zoom — я посетил WeWork. Я огляделся, и на мониторе каждого был открыт Airtable. И я подумал: „Боже мой, это и правда работает. Люди им пользуются“. В тот момент всё стало настолько более реальным. Это был первый момент, когда я подумал, что мы действительно построили что-то, что может состояться».

Сидя здесь, в 2022 году, кажется безопасным сказать, что у них и правда состоялось. Но для Офстада путь далёк от завершения.

«Мы постоянно стараемся сделать продукт проще в использовании. И это касается как человека, который строит приложения поверх Airtable, так и конечного пользователя, который этими приложениями пользуется. Мы, очевидно, всё больше фокусируемся на enterprise — на наших клиентах, которые гоняют крупные департаментальные и общекорпоративные процессы на Airtable. Так что нам предстоит много сделать вокруг больших масштабов, лучших прав доступа — всего того, что и ожидаешь», — говорит он.

«Всё больше мы воспринимаем Airtable как платформу связанных приложений, и это та категория, которую мы определяем. Это означает, что мы хотим дать отдельным командам и департаментам контроль над созданием и развёртыванием собственного софта, одновременно подключаясь к общим наборам данных и общим таблицам, которые помогают разрушать разрозненность внутри организаций». (Если хотите глубже погрузиться в долгосрочную стратегию Airtable, рекомендуем этот профиль в Protocol о сооснователе Офстада — Howie Liu.)