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

Шесть месяцев назад компания Smooch, первая компания, специализирующаяся на API, в которую инвестировала Inovia, была приобретена Zendesk. Уроки, которые мы извлекли из пути Смучи, заставили задуматься о нюансах построения лидирующего в категории бизнеса, ориентированного на API. Некоторые из этих уроков были извлечены из первых рук, в то время как другие были извлечены на конференциях и через YouTube, наблюдая, как некоторые из сегодняшних технических титанов рассказывают о том, как они построили свой лидирующий в своей категории бизнес. Все эти уроки были подвергнуты испытанию в ходе бесед со следующим поколением претендентов, ориентированных на API. Мы надеемся, что вы найдете их такими же ценными, как и мы!

Уроки по созданию компаний, ориентированных на API, с доходом в миллиарды долларов

В концепции модульного доступа к критически важной инфраструктуре, которая позволяет выполнять ключевые бизнес-операции, нет ничего нового - AWS и распространение облачных вычислений в качестве замены локальных серверов были первоначальной волной компаний, ориентированных на API. Вскоре последовал модульный доступ к обработке платежей (Stripe, Ayden), телекоммуникациям (Twilio, MessageBird), поиску (Algolia, Coveo), банковским данным (Yodlee, Plaid) и многим другим бизнес-операциям.

Мы считаем, что существует круговой эффект между масштабируемостью и фрагментацией, что приведет к увеличению числа компаний, предпочитающих API. По мере появления API-интерфейсов и модульного построения доступа к критически важным функциям строительного бизнеса экономия от масштаба, которая приносит пользу действующим операторам, становится гораздо менее важной, а стоимость построения программного бизнеса падает. Этим пользуются претенденты, некоторые из которых переходят к модульному доступу к дополнительным областям критически важной инфраструктуры, и цикл следует за этим. На практике произошло поэтапное снижение затрат на запуск (и масштабирование) компании благодаря AWS и Google Cloud, а титаны, ориентированные на API, такие как Twilio и Stripe, предоставляют свои услуги поверх AWS.

Компании, ориентированные на API, попадают в две группы - компании с прямым и прямым потоком. Прямой API обеспечивает доступ к аппаратному активу, который он хранит внутри - AWS, Stripe и Scale AI - все это примеры этого. Сквозной API извлекает данные из множества других компаний - например, Plaid и Mulesoft. Я склонен думать о потоковых API как о штанге - сам API находится посередине и обеспечивает доступ к данным, поступающим от 2+ конечных точек к получателям.

Оценивая, что делает категорию лидером (и вообще достойной категорией), мы смотрим на создание ценности по четырем основным сегментам:

1) Это серьезная проблема?

Это один из центральных вопросов, которые мы задаем каждому бизнесу - в конечном итоге компании необходимо решать серьезную проблему с клиентами, а не незначительную болевую точку, чтобы создать устойчивую ценность. Мы думаем, что для компаний, ориентированных на API, в основном решаются три проблемы: тупость / демократизация, сложность и фрагментация. Тупость / демократизация имеет наименьший ров, но устранение болезненных рабочих процессов от внутренних разработчиков и / или предоставление возможности любому сотруднику организации делать то, что когда-то требовалось, технический опыт может быть ценным. Сложность обычно возникает, когда создание технически сложно или требует много времени из-за нормативных требований, регулирующих систем или просто из-за реальной технической сложности, превышающей норму. Фрагментация применяется к сквозным бизнесам, и чем больше предложение с обеих сторон, тем важнее решаемая проблема.

2) Есть ли попутный ветер на рынке? Какова временная динамика рынка?

Отличным сигналом ценности является золотая лихорадка, которая попутно попутно на рынке. Для Twilio это был стремительный рост смартфонов, в то время как Mulesoft извлекла выгоду из перехода на облачное программное обеспечение и последовавшего за этим бурного роста бизнеса SaaS.

Второстепенным фактором здесь является то, насколько клиенты сами вложили средства в решение этой проблемы. Безвозвратные затраты характерны не только для API, но особенно для решаемой вами проблемы с меньшими затратами (т. Е. Тупости) расчет сборки и покупки может с трудом преодолеть инерцию внутреннего решения.

3) Является ли эта проблема слишком важной для клиентов, чтобы они могли полагаться на внешнюю сторону для ее решения?

Основополагающим принципом является предоставление клиентам чистой положительной стоимости (NPV). Сама по себе NPV не является уникальной концепцией - во всех случаях рентабельность инвестиций должна перевешивать сами инвестиции, чтобы покупатели могли их купить. Проблема для компаний, ориентированных на API, заключается в том, что когда NPV настолько высока, клиенты неизбежно видят ценность в наращивании этой возможности внутри компании. Мы оцениваем эту динамику, глядя на то, насколько важна эта проблема для потребительского этика. На практике мы спрашиваем: «Требуется ли это для предоставления услуги и / или без нее, будет ли покупатель оказывать заметно худшее впечатление своим конечным клиентам?» Этот фактор не существует изолированно - бизнес, ориентированный на API, который решает очень сложную проблему со значительными техническими проблемами, вряд ли увидит, как клиенты сами создают решение, даже если эта проблема является ключевой для их бизнес-модели. Однако власть ценообразования падает на покупателя, а не на поставщика услуг, и по мере нарастания конкуренции поставщик рискует превратиться в товар и спуститься вниз по цене. Точно так же время выхода на рынок может быть более ценным для клиента API, чем стоимость на быстро меняющемся рынке, и поэтому мы часто видим, что клиенты уже на раннем этапе принимают решения, которые являются основой их идеала. Однако по мере того, как эти клиенты достигают присутствия на рынке и достаточного масштаба, чтобы строить себя, снова возникает вопрос о том, насколько это важно для их бизнес-модели.

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

4) Каким образом этот бизнес может защитить себя?

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

Тактические стратегии влияют на дизайн продукта и маркетинговые стратегии. Некоторые компании сосредоточились на простоте использования, чтобы стимулировать тестирование (например, Aydin, Algolia, Smooch). Другие сфокусированы на опыте разработчиков, настраивая их в качестве реферальных каналов (например, Twilio, Stripe (ранее разработка / платежи), New Relic). Другая стратегия заключается в том, чтобы сфокусировать коммерческие сообщения на ценности для конечных клиентов, делая ставку для покупателей уровня C, которые снижают внедрение в своей организации (например, MessageBird). Другой тактикой был контент-маркетинг, который выделяет клиентов и их варианты использования - при отсутствии реального опыта работы с продуктом полезно продемонстрировать клиентский опыт (например, Twilio, Zapier).

Сетевые эффекты исторически оценивались через призму количества и качества интеграции. Это кратковременное преимущество, поскольку конкуренты неизбежно догонят его. Он также особенно уязвим для внезапных сдвигов в поставках - технологий скачка, которые нарушают существующие интеграции в пользу нового пула партнеров по интеграции, которые должны быть заблокированы. Учитывая эти проблемы, мы ищем возможности для компаний, ориентированных на API, чтобы использовать данные и / или расширить их охват для решения смежных проблем, чтобы стать полезной службой. Конкретные службы, которые могут быть наложены поверх служебной программы, получают информацию из данных, которые проходят через каналы API.

Мы с энтузиазмом относимся к возможностям появления еще большего числа компаний, ориентированных на API, а также к появлению новых предприятий, которые занимаются обнаружением, совместной работой, безопасностью, отслеживанием производительности и другими потребностями, возникающими в связи с множеством предприятий, ориентированных на API. созданный. Если вы работаете над чем-то в этой области или у вас есть мысли о вышеупомянутой структуре, свяжитесь с [email protected], чтобы пообщаться!