Category: Uncategorized

This is a four-part series on how early stage B2B software companies should approach product marketing. Part 1 is about the role of product marketing at the early stage, Part 2 describes a positioning framework I like to use, Part 3 describes my favorite formats for documenting positioning and Part 4 is a summary and commentary on the most effective frameworks I know for pricing and packaging. 

I’ve found this framework incredibly useful for running a positioning exercise over the years. It’s inspired by April Dunford’s approach (highly recommend her book) and Clay Christensen’s jobs to be done framework (first described in the Innovator’s Solution).

Step 1 Start with the ‘jobs to be done’

What: Define the ‘jobs’ your product can be ‘hired’ to perform

Why: As Peter Drucker once said, customers don’t buy products or features, they buy benefits. Jobs-to-be-done helps you look at your product from your customers perspective, making it easier to separate the benefits from the features. 

Example:

Take Cloudflare’s home page for example. They don’t mention a single product or feature, instead focusing on the benefits their target customers most care about — security, reliability, privacy and speed.

Benefit	Example products or features
Security	DDoS Protection, SSL/TLS
Reliability	CDN, Load Balancing
Speed	SSL/TLS
Privacy	CDN, DDoS Protection

Which customer jobs could have led them to identify these core benefits? Having not worked at Cloudflare, I can only speculate, but I imagine they could be something along the lines of:

1. I want to protect my internet assets from bad actors.
2. I want my web applications to deliver the best performance regardless of where my users are located. 
3. I want user data to stay private and encrypted when it moves between my servers and user applications.
4. My applications should be able to handle drastic changes in traffic without changes in performance.

As an early stage company, you probably only have one or two products. The benefits you identify will be more granular than Cloudflare. This typically makes it harder to separate them from your features.    

Step 2 Segment your TAM

What: Segment customers in your TAM using obvious and visible characteristics.

Why: For segmentation to be effective, it needs to be based on obvious and visible characteristics for a number of reasons –

• They drive alignment across the team by helping engineering, sales and product unambiguously define different customer types in their TAM. There’s very little room for confusion when you use characteristics like ‘JavaScript developer’, ‘sales manager, ‘SDR’, ‘lead generation software provider’, ‘BPO’ etc. 
• Clearly defined and labeled customer segments make demand generation and prospecting easier down the line. 
• They make it easier to categorize customer feedback. 
• They also make it easier to identify and evaluate competitors.
• Finally, they help you see which features are most used by customers with different characteristics, a critical input for packaging.   

Let your understanding of the value provided by your product guide identifying these characteristics. They can be external — company size, number of seats, title or role or related to the product — usage or time to deploy the solution. 

Example:

Gong.io does a fantastic job of segmenting their TAM using company roles and responsibilities.The product records sales conversations and uses AI to transcribe and analyze calls to derive insights that can improve sales performance. Insights include topics discussed, objections, competitors mentioned, spotting red flags and identifying opportunities for coaching.

They’ve adopted a broader position to start — ‘Revenue Intelligence’ vs ‘Sales Intelligence’, so that they can sell directly to the top decision maker on the sales side, whether that’s the CRO, COO or another executive title. It also positions them as a strategic investment as opposed to yet another sales acceleration tool.

But they’ve also done a great job targeting all of the other roles that could either be influencers or decision makers in buying the product with positioning that speaks specifically to their ‘jobs to be done’.

Step 3 Map jobs to be done to benefits

What: Map the ‘jobs’ each segment cares about to the benefits delivered by your product or feature.

Why: Each customer segment does not care about all the benefits you have to offer. Mapping helps you identify which products or features, and therefore benefits you highlight when positioning your product to a particular customer segment. 

Example 

Gong again does a great job here. They recognize that their product is valuable to any role responsible for sales performance like sales leaders, frontline sales managers, sales enablement managers and account executives. 

Each role needs Gong for a different set of jobs:

Role	Jobs-to-be-done
Sales Leader	I need my sales team to be closing deals using a consistent and predictable process.
Sales Manager	I need all my reps to perform like my best reps.
Sales Enablement	I need new sales reps to become productive as fast as possible and onboarded sales reps to continue hitting their goals.
Account Executive	I need to consistently meet or exceed my quota.

Each role as a result cares about different benefits:

Role	Benefits
Sales Leader	Ensure reps are adhering to the pitch and best practicesAbility to quantify and benchmark rep performanceMeasure and monitor sales process performance
Sales Manager	Efficient call coachingIdentify best practices and areas of improvementShare best practices within the team
Sales Enablement	Identify areas of improvementMonitor training adoption in the fieldIdentify new competitors and objections
Account Executive	Close more deals faster

You can see this reflected in dedicated web pages for each role:

• Sales Leader
• Sales Manager
• Sales Enablement
• Account Executive

Step 4 Analyze competitive alternatives

What: Analyze alternatives available to each customer segment for these jobs

Why: You can’t identify and articulate benefits in a vacuum. They need to be positioned against alternatives already available to the customer. Also remember that doing nothing, or using Excel or Email, or building from scratch in-house (in the case of API infrastructure) can always be an alternative. Knowing your strengths and weaknesses relative to alternatives helps you identify which benefits to emphasize in your positioning,  which ones to downplay, and also helps with objection handling in sales conversations.  

Example

I personally love this marketing tactic from Segment – https://segment.com/crm-is-not-enough/

Having created the CDP category and become the leading company in the space, they’re explicitly contrasting CDPs (and by extension Segment) against CRMs by focusing on the relative advantages that matter to their target customers — companies looking to build better customer experiences. 

Their positioning focuses on:

• Eliminating data lock-in through open APIs and frameworks.
• Flexibility to use the tech stack of your choice when building customer experiences (cough force.com cough).
• Removing inter-departmental silos to place the customer first.

Note another advantage of this approach. CRMs are much older than CDPs. Segment’s target customers are extremely familiar with CRMs. Explicitly positioning against CRMs gives their target customers a reference point, making it easier to understand the benefits of Segment.

Step 5 Articulate your value

What: Articulate the value your product provides relative to the alternatives in a way most likely to resonate with each segment.  

Why: This is where you bring your positioning home. Having identified the jobs to be done, benefits, customer segments and competitive alternatives, it’s much easier to articulate the value of your offering.  

Communicating the value of your offering to a target customer to get them to buy it at a target price.

Example

Let’s look at Segment again. They have identified three customer segments for their platform – Engineering, Product and Marketing and have dedicated web pages articulating the value most relevant to each one.

Customer segment	Value
Engineering	Data standardization Ease of integration Ease of compliance
Marketing	Personalization Optimizing product communications Predictive conversion modeling
Product	Single view of your customers Integrate with the best analytics, testing and data tools Cross-team collaboration on analytics

Once you’ve articulated the value of your offering, it’s critical to write it down for the rest of your company. It’s also important to treat it as a living document — your positioning is guaranteed to change over the lifetime of your company. A living document forces you to track changes systematically and provides a record of key positioning decisions. In Part 3, I’ll discuss some of my favorite formats for documenting positioning.

Who is this series for?

Early stage B2B or developer focused companies that have found their first few customers and believe they’re on a promising trajectory towards product/market fit. Spending time on product marketing without having any early traction is akin to spending time on 5 year revenue projections when you have just a handful of customers. You’ll end up with an elaborate work of fiction that you’ll need to throw away in six months when your understanding of the market inevitably changes.

Ideally, you want to start spending time on product marketing when you believe you’ve found enough customers with similar requirements and characteristics that want to use your product — a customer segment. But more often than not, I’ve seen startups wait too long to start working on product marketing as opposed to starting prematurely.

Why should you hear what I have to say?

I’ve spent the last 3 and a half years in product marketing at Twilio during a time of rapid change and transformation for the company.

We went from having barely any sales force at the time of going public, to growing the sales organization more than 10x by mid-2020. The scope of product marketing broadened from just developer awareness and adoption to prioritizing sales enablement and marketing campaigns focused on business and executive personas.

Some products I’ve positioned and launched:

• Programmable Voice: I launched the original public beta of Voice Insights and improved the on-boarding and developer experience for new sign-ups for the Programmable Voice product.
• Programmable Messaging: I launched Twilio Notify, scaled up sales enablement for the business unit and launched the Twilio WhatsApp API.
• Autopilot: I took the product from beta to GA by formalizing positioning and sales enablement. I was also the PM for the developer experience where I improved the documentation, launched new dev tools and improved the on-boarding experience.

I left Twilio in October 2020 to join Modern Treasury to lead product marketing. I love advising early stage companies on product marketing and go-to-market and invest when it makes sense. There’s more about my startup advising and investing here.

What is Product Marketing?

Communicating the value of your offering to a target customer to get them to buy it at a target price.

Great Product Marketing drives preference for your product in the marketplace. It ensures your target customers think of your product first when faced with the problem it solves.

For example, consider the following problems a software buyer might face and the products that are most likely to come to their mind:

Product	Problem
Stripe	I need to receive payments online
Square	I need to accept credit cards in my store
Twilio	I need to send text messages to my customers
Plaid	I need to link my customers’ bank accounts
DataDog	I need to monitor my cloud infrastructure

Products that are top of mind have great product marketing (in addition to being great products of course).

Product Marketing is the foundation of other marketing and sales activities like demand generation, outbound sales and community evangelism. It determines the core message, channel, target persona and call to action for each campaign. Running a deliberate marketing campaign before your first product marketing exercise is a recipe for failure.

The tactical focus of Product Marketing in a B2B startup changes based on stage — early product/market fit, late product/market fit and growth, and type — primarily top-enterprise sales and primarily bottom-up user or developer focused sales.

• Early product/market fit → segmentation, competitive analysis, quantifying customer value, pricing experiments
• Late product/market fit → case studies, packaging, campaign planning and prioritization, sales enablement
• Primarily top-down sales → case studies, customer advisory boards, webinars, RoI calculators
• Primarily bottoms-up sales → demos, documentation, developer experience, hackathons

By ‘early product/market fit’ I’m referring to the stage right after a startup finds their first target customer segment — when it makes sense to start working on product marketing.

Who owns Product Marketing at the early stage?

At the early stage, product marketing needs to be an input to your product strategy. Kicking off a few product marketing activities once you’ve found early traction ensures your product has a strong narrative from day one. It’s also very effective at placing you in your customer’s shoes, forcing you to look at your product from the outside-in.

In the absence of a dedicated product marketer, the same person that owns product management should own product marketing. A generalist marketer can also do a good job provided they’re entrepreneurial and technical enough to have sales conversations with your customers and comprehensively analyze the competition.

If  you’ve already raised money, chances are you’ve likely done some foundational product marketing work already. At this stage, there’s likely no difference between your product and your company. Some of the components of the story you’re telling investors can be repurposed in the story you’re telling customers — also known as positioning.

Breaking down Product Marketing

Product marketing consists of four components:

1. Segmentation, also known as dividing and prioritizing your target market.
2. Positioning, which determines how everyone at your company talks about the product to customers, whether on your marketing channels, sales conversations or support.
3. Packaging, which describes different configurations of your features or products customers can buy.
4. Pricing, which determines what and how you charge for individual products or packages.

You can see each component represented in the definition of product marketing I presented earlier:

Communicating the value of your offering to a target customer to get them to buy it at a target price.

• Value = Positioning
• Offering = Packaging
• Target Customer = Segmentation
• Target Price = Pricing

Packaging and pricing are only useful once you have completed segmentation and positioning. Segmentation and positioning are deeply intertwined. They can’t be performed discreetly. You can’t position a product without an audience in mind. And to identify an audience, you need a product and therefore a starting ‘position’. The good news is that your first set of customers are a great starting point for your first segmentation exercise. Positioning and segmentation set the foundation of great product marketing, and I’d argue even great product development.

It’s critical to not get too attached to your segmentation and positioning. Treat them as hypotheses that need to evolve with your business and the market environment.

Positioning and segmentation go hand-in-hand

Positioning can’t take place in a vacuum. Before you can come up with a compelling position for your product, you need to identify a target customer and the problems that matter to them. Looking at the same examples discussed earlier, each company is trying to reach a different target customer with their core product:

Product	Problem	Customer segment(s)
Stripe	I need to receive payments online	Developers, PMs
Square	I need to accept credit cards in my store	Small business owners
Twilio	I need to send text messages to my customers	Developers, PMs
Plaid	I need to link my customers’ bank accounts	Developers, PMs
DataDog	I need to monitor my cloud infrastructure	Developers, IT

Target customers must have one or more easily identifiable features — functions (as shown above), company size, industry, location and even company age — digital native or conventional enterprise, midmarket or SME.

You combine these features to create a customer segment. An example customer segment for Twilio could therefore be developers and PMs at automotive CRM companies.

Segmentation is critical because different customers value different capabilities of your product. They use different vocabularies to think about and describe their problems. You need to position your product differently to each segment.

Conversely, positioning success with one segment does not always translate to another segment. Consider software buyers with the following requirements:

I need software to run my 10,000 seat contact center.

Twilio wants to be the first name prospective customers think of here, but is still a newcomer to the contact center space. A lot of prospects that know of Twilio still only see it as an SMS company. The goal for Twilio with Flex is to position themselves as a serious option in a decades old contact center market dominated by incumbents.

I need serverless infrastructure to deploy my application

When Cloudflare launched a serverless computing platform called Workers, they were entering a crowded space consisting of major cloud platforms on one end and startups like Vercel, Netlify and Serverless on the other end. Workers was also a developer product, a very different persona than the IT or network admins Cloudflare typically sells to.

Their positioning for Workers is quite different from other Cloudflare products:

• It has a separate subdomain
• Code is front and center
• Focuses on specific technical benefits
• CTAs point to ‘Start Building’ or ‘Read docs’

Breaking down your TAM into customer segments also helps prioritize product decisions. Sometimes segmentation can even lead you to ignore a number of customer segments.

To summarize and conclude part 1, the goal of  product marketing is to drive preference for your product in the marketplace. It is the foundation of your marketing strategy because it helps you systematically identify the most compelling value proposition for a target customer segment. It’s key activities are positioning, packaging, segmentation and pricing. Positioning and segmentation come first, followed by pricing and then packaging.

In part 2, I’ll break down a positioning framework I like using.

A few things to note before you start reading:

Firstly, I wrote this piece almost two years ago but didn’t publish it because I thought it wasn’t very good. But then I read it again yesterday and thought it to be quite well-written! My past self was highly critical and insecure about my writing. I guess my present self has learned a lot about writing like no one is reading.

Secondly, a lot has changed about the enterprise collaboration market since I wrote this. Slack went public and is trying to become an enterprise social network (?) and Teams seems to be crushing it by using the Microsoft sales machine to prevent Slack from getting into the enterprise and investing in their own dev platform.

And to top it all off, Zoom is entering the chat. Like literally. They’re apparently building more robust chat features that will inevitably compete with Slack.

So if you’re looking for a current take, stop reading! I don’t want to waste your time. But if you’re interested in a snapshot of my thinking circa October 2018, go right on ahead. To be fair, I still think classifying Slack apps into Essential, Internal and Ecosystem apps still makes a lot of sense, and the number of companies primarily building for Slack has only grown since I wrote this post.

---

To build a sustainable moat, Slack is trying to become the connective tissue of the modern workplace. The Slack API is the lynchpin of this strategy.

Slack’s explosive growth over the past 4 years stole market share from HipChat, resulting in Atlasssian shutting down the product and selling it’s IP to Slack in exchange for a stake in the company. Slack is now dominant with a 70% share of the team chat market.

But what got Slack to its leadership position won’t help it stay there. User experience is not sufficient to build a sustainable moat and certainly not one that justifies a $7 billion dollar valuation. The competition is coming at Slack from all sides. On one side, it is threatened by startups like Flock and Chatwork and more established SaaS companies like Zoho looking to expand into team chat with Cliq. They’re competing with Slack primarily on price.

On the enterprise end, it’s competing with Microsoft Teams and Facebook Workplace. Microsoft is pushing Teams by using existing relationships and contracts and by bundling it into Office 365. They’re also likely to come after Slack’s bread and butter – mid market companies, with their deep pockets, larger sales teams and distribution partners.

To their credit, Slack realized this pretty early on, launching the App Directory in 2015, only two years after the company was founded. From the Verge article that reported on this announcement in 2015:

Slack built all of its initial integrations itself, starting with Google Docs, Github, and a bug tracker, among others. The team’s insight then, which helps explain its meteoric rise, is that those integrations fueled all-day usage of Slack. “The more information you pushed into the messaging system, the more people paid attention to it,” says Stewart Butterfield, Slack’s founder and CEO. “It was a virtuous circle. We didn’t realize how strategic it would be as a business deal until after Slack had launched. And then suddenly it was just very obvious — the more apps we get people to install, the more likely they are to keep using Slack.

In the last 3 years, the Slack API has been used by 200,000+ devs to build 1500+ apps in the directory. While increasing usage and retention may have been the goal of enabling third-party integrations in 2015, I think this thesis has changed considerably since then. The Slack API may have started as a growth hack. Today it is a critical component of the company’s product strategy.

Slack has an intensely loyal user base — most employees would revolt if IT tried to take away their Slack. But sustainable and defensible businesses can not be built on product loyalty alone. They are built by products that excel at locking in customers. These products do more and more jobs for their customers over time, gradually absorbing their customers’ workflows and processes. The more bespoke their implementation becomes, the harder it is for them to churn. Conversely, requiring a bespoke implementation for customers to start seeing any value can be a barrier to adoption. The most successful products are therefore easy to adopt, show value immediately after adoption, and can grow into the organization. They get adopted by more people, customized, inserted into more workflows and ultimately become a critical component of their customers’ operations. Salesforce is a prime example of this. It will never win any awards for design, and with the extremely confusing new Lightning experience, probably not for user experience either. But with the Salesforce APIs, the App Exchange and with products for almost every department and vertical, Salesforce excels at increasing lock-in.

Judging the strength of Slack’s lock-in involves taking a look at the types of apps that are being built with the Slack API. I think they can be divided into three broad categories — Essential Apps, Ecosystem Apps and Internal Apps.

Essential Apps

These are integrations with other staples of the workplace like Google Drive, Zendesk, Salesforce, Github and others. A lot of these are built and maintained by Slack itself, driven by that original insight that pulling in information from other systems people use frequently increases their Slack usage. People often spend more time in these apps than they do in Slack. Making Slack the way users collaborate when using these applications ensures that they still use it even when they’re not actively using Slack. Using the Google Drive integration to create and share docs with colleagues and responding to comments ensures that collaboration on documents happens inside Slack. Adding the JIRA or Trello integration to a Slack channel means project management workflows are driven by Slack, which is used to create, discuss and track new tasks. Slack is becoming the collaboration layer for these applications, even though a few of them have native collaboration features, like Salesforce with Chatter. These apps are essential to make Slack the place where work happens.

Ecosystem Apps

The majority of the 1500+ apps in the App Directory belong to this category. These are integrations with products that use Slack’s reach to acquire users and it’s popularity in the workplace to drive usage. Some of these apps are also being built exclusively for Slack. Take Donut for example, a Slack app that helps employees with on-boarding and building stronger personal connections with each other. It’s particularly useful for remote workforces, using Slack to pair up two random employees each week, making up for the lack of serendipitous interactions that take place when everyone is in the same building.

Developers are an extremely creative bunch. By allowing anyone to build an app, Slack is increasing the chances they use Slack APIs as the outlet for their creativity. I can see a future where an app comes along for Slack that is so unique and valuable in the experience it provides, that people install Slack just to be able to use that app. Platforms benefit when they make it possible for third parties to build highly differentiated apps.

It also allows Slack to observe trends in ecosystem app development in great detail. This provides valuable signals regarding what their users want. If Slack sees a certain type of app gaining adoption with users, they can decide to build it as a feature or even acquire a company if its strategically important enough. Hit applications tend to come from out of the blue. Having an ecosystem is essential to participate in this creative process.

Internal Apps

There are likely orders of magnitude more apps running internally within different teams than the 1500+ apps in the App Directory. They can be as simple as a Zapier integration or as complex as a custom built incident management workflow. I think these types of apps tend to have the most lock-in value. They tend to be highly customized and are proof that Slack has become so integral to the operations of a team that they are willing to invest developer resources to build custom software around it. Once in place, these integrations are extremely difficult to displace. Employees get trained to use them and grow accustomed to them. Companies also want to minimize the developer resources they invest on non-revenue generating software. Prioritizing building a replacement, either outside of Slack or on a competitor is always hard to justify. Having custom integrations in each department effectively compounds this lock-in — there’s more people to convince and more code to replace. While Slack hasn’t made any data on the state of internal integrations publicly available, its clear from their latest positioning that they’re emphasizing the value of building internal integrations.

Conclusion

The Slack API allows anybody to build an app for Slack. It has great documentation, tutorials and best practices. Initiatives such as this public roadmap for the Slack platform and a new developer conference are indications that the company is serious about developer relations.

I think Slack has the opportunity to shape the very nature of work. It’s already well on its way to becoming the collaboration center of the modern workplace. The next step is to create an entirely new category of products and experiences for the workplace, one that can only be built and delivered over Slack. I don’t know what this ultimately looks like, but I can see early signs of this. More and more products like Donut and Niles, which adds chats to a team wiki, making it easier to document tribal knowledge, are being built that are (for now) unique to Slack. Locking-in users is ultimately critical because business applications are playing a zero-sum game. Users have a finite number of jobs-to-be-done, and a finite amount of time to do them. Every minute a user spends in Slack is a minute not spent using another product.

Developers are an even more scarce resource than users. Investing in documentation, education and developer relations is the right start, but won’t be sufficient in the long run. Slack needs to provide them with business models to successfully monetize their applications. This is the final piece of the puzzle in my opinion. Allowing developers to build sustainable businesses on top of Slack is critical to making it a true platform.

Throughout my time at Twilio, I’ve often wondered why some software infrastructure companies become massive businesses while others falter. What is it about the nature of certain products and the markets they target that makes it possible to build large infrastructure platforms? This post is an attempt to structure what I’ve learned about this question and was prompted by a series of conversations I’ve had recently with early stage API infrastructure companies about product and go-to-market strategy.

In my opinion, your startup’s target market must have the following characteristics for it to turn into a massive business:

1. The risk to the customer’s business of being locked into your infrastructure must not be prohibitive.
2. The opportunity cost of building the same infrastructure in-house must be high enough to consider buying it from a third-party.
3. There need to be enough customers that meet criteria (1) & (2) willing to pay what’s needed to support a market for it.

Startups that build APIs for problems that have a high opportunity cost to solving in-house relative to the risk of depending on a vendor have the highest chances of breaking out to become massive companies. Low opportunity costs mean your customers can easily build the same infrastructure in-house, and a low risk of lock-in means they can always switch you out. The sweet spot lies in providing infrastructure that’s hard to migrate from, resulting in a high risk of lock-in, but provides substantially more value than the opportunity cost of building in-house.

To begin exploring this question in detail though, you need to start with the company that started it all — Amazon Web Services.

1. Land and expand

The advantages of building on a cloud platform are clear as day today. For startups and increasingly for enterprises that need to move to digital business models, using APIs instead of setting up servers turns upfront capital costs into ongoing operational costs, provides instant scaling and eliminates the overhead of maintaining data centers. Even the most sophisticated companies will think twice before building their own data centers today.

If you trace the trajectory of products launched by AWS since they announced SQS in 2004, a pattern emerges. Over the years, AWS has moved up the application stack with new releases to provide infrastructure that is tailored to solving increasingly specific software development problems. These APIs are more opinionated i.e. they force you to build software in a certain way, and tightly integrated with AWS infrastructure, but also a lot easier to use. Jerry Hargove has drawn up this fantastic timeline of every single AWS launch since 2004 and grouped them into categories.

Today, developers can build applications on AWS with APIs providing different levels of abstraction. If you’re looking to build a video streaming application, you can directly use AWS Media Services without worrying about the underlying transcoding, storage and bandwidth infrastructure. But, if you’re looking for more control over your application, perhaps you need to run a custom transcoder optimized for your use case, you can build a video streaming stack using EC2, S3 and CloudFront. I arranged the categories Jerry uses by the general level of abstraction provided by it’s members to illustrate my point. I didn’t consider newer bets like AWS Ground Station or AWS RoboMaker, or horizontal utilities like Developer Tools or Cost Management.

AWS APIs that provide more abstraction generally charge higher prices because they can significantly simplify application development and decrease release times. They probably also have higher gross margins for AWS.

This general pattern — starting with lower level APIs, raw compute, storage and networking in AWS’s case, and moving up the stack over time isn’t unique to AWS. Almost every single successful API company founded since the advent of public cloud platforms has followed this strategy.

Twilio

Twilio’s first product was an API for making and receiving phone calls. Their second product was an SMS API. Since then, they’ve expanded to provide dedicated APIs for two-factor authentication, video conferencing, VoIP, WhatsApp and in-app chat. Recently, they moved even further up the stack with Flex, a programmable contact center that bundles these APIs together under a customizable UI framework.

Stripe

Stripe’s first product was an API for accepting payments. When they started seeing a lot of traction in e-commerce, they launched a UI framework to make building checkout experiences easier. When they saw a lot of traction from marketplace companies, they built Connect to simplify on-boarding and verifying sellers and routing payments. Since then, they’ve launched APIs for subscription and invoicing, fraud detection and card issuance.

Segment

Segment started off providing a unified API for ingesting customer and usage data from multiple sources and loading it into different business analytics tools. Today, they’ve built products that aggregate this data to provide a 360-degree view of each customer, allowing businesses to enrich existing customer data, build audiences in real time and create personalized experiences.

DataDog

DataDog’s first products were monitoring APIs for virtual machines and cloud instances. Since then, they’ve expanded to other cloud backend configurations like containers and serverless, while also moving up the stack to provide logging and monitoring solutions for middleware and applications.

This ability to land and expand is what separates the wildly successful infrastructure companies from those that fail to take off. This expansion happens horizontally, as more teams come to rely on their API and as they provide APIs at similar levels of abstraction for adjacent use cases, and vertically, as their customers start adopting higher level APIs to solve more specific problems. The beauty of this model, if you can get it right, is that all you need to do to identify new product opportunities is closely observe what applications your customers are building. A large enough number of customers building the same types of applications usually represents an opportunity to provide a higher-level API. This expansion also makes their infrastructure harder to replace, resulting in stellar revenue growth rates and net dollar retention numbers.

I think there’s a more fundamental question you need to ask then to answer the original question — why do some API infrastructure companies land and expand successfully? It starts with understanding the alternatives available to their prospective customers.

Every SaaS product’s toughest competitor is the customer not buying! The hardest customers to sell to think they don’t even have the problem your product solves. What’s every infrastructure product’s most formidable competitor then? Alongside not buying, it’s the customer deciding they can build the same capabilities in-house instead of integrating with a third party.

A customer buys infrastructure if the risk of being locked-in to a vendor is lower than the opportunity cost of building it in-house. API infrastructure companies that demonstrate enough value to overcome the perceived risk of lock-in find it easier to land within their customer’s application stack, expand and become massive companies.

2. Vendor lock-in dynamics

The more reliant a company becomes on a third party, the harder they find it to replace them. This risk isn’t unique to software infrastructure. But a thorough understanding of the risk of vendor lock-in from the customer’s perspective is the most important input to the strategy of any API infrastructure company. This risk is higher if the third party isn’t completely modular i.e. swapping them out is expensive, time-consuming and can have second or third order effects that are hard to predict.

Apple’s decision to move away from Intel is a classic example of vendor lock-in gone wrong. They’re replacing Intel’s chips with their own A-series chips (the same chips that power iOS devices) in all new Macs released in 2021 and beyond. This is going to be a complex transition for Apple because the A-series chips are based on ARM while Intel’s chips are based on the x86 architecture. Apple is bringing chip design in-house because Intel has fallen far behind TSMC in processor node size. TSMC started working on 5 nm chip this year while Intel is still stuck producing 14 nm chips. Intel was also increasingly the bottleneck for Mac innovation — Retina displays took longer to arrive on the Mac than on the iPhone because Intel’s production of 14 nm chips was delayed. Replacing Intel gives Apple full control over the entire Mac stack, allowing them to optimize performance and build features on their own timeline. The risk of depending on Intel ultimately wasn’t worth the benefits.

I’ve most frequently seen four types of vendor lock-in with software infrastructure companies.

• Tightly coupled architectures
• Economies of scale
• Developer experience
• Network effects

The lock-in can be quite formidable if more than one type is in play.

Tightly coupled architectures

If using a vendor requires you to explicitly design your software within the constraints of their API, your architecture can get tightly coupled to theirs. The degree to which this happens is hard to assess when you first make that decision because the immediate benefits — speed and implementation costs, are usually obvious, and vendors put a lot of work into making their APIs extremely easy to adopt. It’s only as you scale does the extent to which you’re coupled starts becoming obvious.

Implementing on AWS is the most obvious example here of making a decision that leads to tight coupling. It can be extremely hard to move off AWS, especially if you’ve come to rely on their higher-level APIs! Google’s decision to open-source Kubernetes was specifically targeted at this dynamic. Containers make it significantly easier to run software on multiple cloud providers.

Economies of scale

This dynamic comes into play typically when the service provided by the API infrastructure company has a hard cost to deliver. Take Twilio, Stripe and Cloudflare for example. Each company has an underlying cost to deliver their services, in addition to the cost of their own software and overhead. With Twilio, it’s the cost of text messages and voice minutes, Stripe it’s payment processing fees to Visa and MasterCard and with Cloudflare it’s bandwidth. As these platforms scale, they’re able to negotiate better terms with their suppliers, which they can then pass on to their customers. For a customer, going directly to their suppliers will result in higher prices because most companies can’t match the scale of these platforms.

Developer experience

Developers are increasingly decision makers, or at least important influencers in most software purchase decisions today. This is especially the case with software infrastructure companies. Building APIs that developers love and rely on can also be a significant source of lock-in. And it’s not just about great documentation, building a great community or ease of use. It’s also about how embedded your product can get in the development workflow. This is why so many API infrastructure companies have command line interfaces and support for tools used for continuous integration and continuous delivery pipelines.

Network effects

Network effects are less common because most API infrastructure companies operate multi-tenant systems designed to separate customer data as much as possible. They also don’t typically facilitate transactions between customers on the platform. But network effects can manifest on the supplier side and become a significant source of lock-in. Plaid is a great example of this. For each new financial institution they add to their platform, the value of choosing Plaid over a competitor increases.

3. Risks from vendor lock-in

If these lock-in dynamics create opportunities for infrastructure companies, they create risks for their customers.

• Execution risk
• Scaling risk
• Cost structure risk

The greater the perceived risks, the higher the value delivered by your infrastructure needs to be.

Execution risk

What happened with Apple and Intel is in a sense a great example of execution risk. As Intel struggled to keep up with TSMC, Apple realized they stood to gain more by bringing chip design in-house and outsourcing manufacturing to TSMC than relying on Intel for both design and manufacturing. Not only do they now get Intel’s margin on the chips, they don’t have to be constrained by Intel when launching new features, ensuring incidents like the delay on shipping Retina screens in 2015 would never take place.

When a company buys infrastructure instead of building it in-house, it’s making a bet on the vendor’s vision and ability to execute on their roadmap. The last thing they want is to depend on a vendor that can’t keep up with their roadmap. This is less of an issue for established infrastructure companies, but for startups allaying these concerns upfront is critical.

Scaling risk

The same calculus applies to the vendor’s ability to scale. Companies buying infrastructure want to know whether it can handle their existing transaction volume, manage volatility in volumes and add capacity to support increases in volume over time. Established infrastructure companies like Twilio, Stripe and DataDog got around this problem in part by first selling to startups. As WhatsApp, Uber, Lyft and AirBnB started growing rapidly, they scaled in tandem to build the capacity required to support larger enterprises later on.

Not all API infrastructure companies need to sell to startups or individual developers at the beginning. In fact, most companies are unlikely to have an addressable market with a long tail of small customers. If you’re selling to enterprises from day one, structuring the engagement like a professional services or custom software development contract can be effective at addressing this concern, while also giving you a deeper understanding of their requirements.

Cost structure risk

When a company decides to use Stripe instead of becoming a payment facilitator themselves, they’re giving up the ability to negotiate favorable payment processing fees with the card networks. This is a major selling point for long tail developers and small and medium businesses. It’s also a compelling reason to use Stripe for larger businesses that don’t have the appetite to integrate directly with banks and card networks. But for businesses processing hundreds of millions of dollars every year, each cent they pay Stripe on top of the fees charged by Visa and MasterCard starts to add up. Bringing payment processing in-house starts to look very attractive. Startups like Finix have emerged to allow companies to do just that without building a payments processing stack from scratch.

4. Opportunity costs

The opportunity cost of building infrastructure in-house is essentially the cost of the engineering team needed to build, operate and maintain it not working on something else. The calculus is straightforward — is it a better investment to have expensive engineers build software you could just plug in from a third-party instead of working on features that will differentiate your core product? There’s also an element of execution risk here — once built, can your team add features and scale faster than a third-party whose entire business depends on providing the best infrastructure possible?

The opportunity cost is inversely proportional to how strategically important the infrastructure is to the business model of the company. Taking an extreme example, Netflix would never use a third party video streaming API even though it could significantly lower their engineering costs. The opportunity cost is non-existent here because of how critical owning the end-to-end video streaming infrastructure is to their business. WhatsApp is an example on the other extreme — SMS verification is a core part of their user on-boarding flow. But the opportunity cost of directly connecting to every single carrier in the world is too high! It makes more sense to use Twilio than divert engineering resources from working on the core product. That’s also why WhatsApp, or any other chat app for that matter will never use a third party for their real-time messaging infrastructure.

In my experience, it’s hard for customers to measure opportunity costs systematically and objectively. They can only be considered when the build or buy decision is being made and depend on business priorities, budget constraints, market conditions and with larger companies, internal politics.

5. Clearing the threshold

It follows then that customers only derive value from API infrastructure if the opportunity costs are higher than some minimum threshold and the risk of lock-in is lower than some maximum threshold. Understanding these thresholds for your addressable market is critical to determining if you have product-market fit.

Here are a few questions I’ve found useful when evaluating the target market for an API infrastructure company.

Vendor lock-in

1. What scale are your target customers operating at? Typically expressed in usage or API calls.
2. Can your platform handle their scale over time?
3. How complex is the integration? Focus on how much additional work the customer needs to do to start seeing value from your API. Do they need to build a UI or integrate with Salesforce for example?
4. How sensitive is the data they’re sending you? Are you storing it?
5. How much is your roadmap and vision aligned with theirs?
6. What portion of their service delivery cost is your infrastructure?

Opportunity costs

1. How strategically important is this functionality?
2. How large an engineering team do they need to build and operate this in-house?
3. Is this something their engineers are excited to work on?
4. Are there on-going non-engineering costs like regulatory compliance, security overhead and complex contractual relationships?
5. Does building require maintaining a large number of third-party integrations?
6. Will cost and performance improve meaningfully with constant optimization

Thanks for reading — this post may have gotten a bit wonkier than I intended! Please send your thoughts and feedback to me on Twitter: @pranaveight.