Tag Archives: platforms

Sequencing Business Models: So You Want To Be A Platform?

This is part three of a three part series on sequencing business models. This post is a collaboration with Gilad Horev.

In part two of our Sequencing Business Models series, we talked about the different types of marketplaces and what needs to be built to be effective in each of them. This builds on the first essay in the series of how there has been an increase in interest of SAAS-like models interested in becoming marketplaces over time. In that essay, we also talked about how a more common route for a SaaS business is to become a platform. Platforms can create an immense amount of long-term value for companies, or be a minor component of their product strategy to maintain product/market fit. In this post, we’ll talk about the different types of platforms and what needs to be true to create long-term success.

The Types of Platforms

Bill Gates’s definition of platform has been widely popularized, but it has some problems. To repeat, Bill said: 

A platform is when the economic value of everybody that uses it, exceeds the value of the company that creates it.

This quote outlines the extent to which platforms enable the success of businesses building on them. But as we try to define platform as a business model strategy separate from any other, we can see that this quote is incomplete as a definition. Assume your company manufactures and sells professional tools for plumbers. Presumably the aggregate economic value that plumbers get from the use of your tools is greater than the value of your company. If not, your tools are overpriced. But a wrench company is not what we mean when we say ‘platform.’

So, if a platform can’t be defined by economic value alone, how does one define it? Well, first, there are two distinct types of platform models SaaS companies tend to pursue, with drastically different chances of success and fundamental value for the company.

Integration Platforms
The first type is an integration platform. In an integration platform, the product integrates with other types of software the product’s customers already use. Integration platforms are ubiquitous in SaaS. It could be argued they are a requirement for long-term product/market fit in most industries SaaS companies compete in. Sure, if you are an upstart company like, say, Roam Research, you might not yet have an integration platform, but you almost certainly will build one as you scale. 

If a SaaS company is going to build a successful integration platform, it will need to attract the right integrations that help their customers. Many times, SaaS companies adopt a “build the platform and they will come” approach that doesn’t work in practice. Even if developers do come, and they happen to build integrations that help customers; if incentives aren’t aligned between the two companies, lasting investment will not happen, and the integrations will be poorly maintained. Apps and integrations will simply break over time as the company and integrators reorganize, shift strategy or update APIs and functionality. Failing this test prevents a company from even getting started, and surely from sequencing to a more sophisticated platform model later. In fact, the quality of integrations can impact the customer’s perception of the core SaaS product. At Eventbrite, Gilad and his team found that many event creators who were actively using integrations didn’t even realize that they were engaging with a product built by external developers. From the customer’s perspective it doesn’t matter where the ‘product’ ends and the ‘integration’ begins—they are all part of one customer experience.

What is the right incentive for building an integration? Simply put, it’s when both the platform and developer think the integration will make their respective product better and more retentive for a segment of customers. If the drive for the developer is primarily user acquisition, however, the platform is more likely to end up with an ad than an app. There may be fewer developers who want to integrate for the right reasons than you would like, but volume of integrations shouldn’t be the goal. Incorrect incentives will lead to poor quality integrations. In the best case, those will result in lower usage and a disappointed developer. But the worst outcome is disappointed customers, and the mistrust of other integrations and even the SaaS product itself.

When kickstarting a platform, a SaaS company is creating a form of cross-side network effect. The demand side of the network should already exist. That demand is the base of SaaS customers using the core SaaS product. So, how do you create and manage the supply side? This is frequently done with a lot of business development work early on to get other companies to build integrations. An alternative is for the company to build integrations itself or to contract out the building. An increasingly common version of this is working with companies like Tray.io or Zapier to ensure the integration is successful and maintained. Having the right supply and quality decreases the risk of the network effect not kicking in. But, just because the demand side of the network effect already exists does not mean they naturally find and adopt these integrations either. Companies need to invest in discovery experiences for customers to find these integrations as well as shared documentation and co-marketing efforts.

What are examples of integration platforms? Pick almost any SaaS company, and you will find one. Successful examples include Slack, Gusto, and Docusign. In these instances, the integrations really do add to the experience, strengthening the product/market fit of the core product by either passing data or automating usage of the tools being integrated. We’re probably all familiar with the Giphy integration with Slack, but also Google Calendar, Google Drive, and Github. You may be less familiar with Gusto if you are not a small business, but they integrate well with every type of accounting software, point of sale system, or expense management tool you could possibly use. Docusign integrates with all sorts of productivity, sales and legal software. Go to almost any mature SaaS company’s home page, and you will typically find an integrations link in the footer.

Extension Platforms
Extension platforms are an evolution of the integration platform. First, let’s bring back Brandon Chu’s definition of an extension platform from the original essay:

A business that enables other developers to make your product better where the platform owns the relationship with the customer and provides some of the direct value itself 

This is where the distinction between a marketplace strategy and an extension platform strategy becomes the most clear. A successful extension platform strategy takes your existing customers and makes them available as demand for external developers. A SaaS transition to a marketplace takes your existing customers and tries to help them acquire more demand. So, whereas sequencing to a marketplace adds a demand side and turns the SaaS customers you acquired into the supply side of the marketplace, sequencing to an extension platform adds a supply side and turns the SaaS customers you acquired into demand for external developers. This means two things in contrast to integration platforms. A company integrates with your integration platform because they believe it improves their product/market fit, primarily improving retention of their existing customers. In extension platforms, new developers build new businesses on your platform because your platform is a source of customer acquisition in addition to attracting existing businesses your customers already use.

Why should you care about extension platforms vs. integration platforms? Successful extension platforms are much more rare than successful integration platforms, but when they are successful they create fundamentally large business outcomes. Salesforce, Shopify, and WordPress are some of the most notable extension platforms. All of these platforms have billion dollar companies that have been built on top of them. Most operating systems like Windows, iOS, and Android are also extension platforms. 

Why do extension platforms create such amazing outcomes? Well, in general, creating a cross side network effect enables the product to get better faster than the company can make it better on its own. Take Grubhub, for example. Initially, the key way that Grubhub got better for consumers was by acquiring more restaurants. When selection improved, the product experience got better. Extension platforms are a version of this phenomenon that is supercharged in two ways. First, while an incremental Grubhub restaurant is only useful to you if it delivers to your location, additional apps on an extension platform are more widely valuable–developers are not building apps for a 20 block radius. Second, every incremental app on an extension platform makes the platform and many of the existing apps more useful as a unit. An additional restaurant provides more choice, but either way you are only going to have one dinner a night. And you’re unlikely to order ingredients from different restaurants to comprise a better meal.

Just because a company has built a successful integration platform does not mean it can or should build an extension platform. Considering the practical differences between integration and extension platform helps clarify what is required for a given strategy. It helps diagnose where a company currently is, what order of operations might be, and concretely what to build, what not to build and where to invest. So first, let’s talk through the raw ingredients that seem to be required. Then, we can talk about the strategy elements that need to be defined to pursue this strategy correctly. 

Extension platforms are most likely to be successful when sequenced from successful integration platforms. Why is that? Well, developers want to see other developers already being successful on the platform, and the easiest way to do that is to show successful integrations from companies they already know. So, if a developer sees that Dropbox is integrated with the platform, it will have much higher social proof than an unknown developer. In essence, independent developers need to see that the cross side network effect of the platform already exists before they try to create a new business on the platform. Shopify has remarked about how long it took their extension platform to start working because they did not have these proof points.

Unlike Kwokchain, we do our graphs in Excel, like professionals.

The second thing that needs to be true to have a successful extension platform is having a large volume of customers. If an external developer hopes to run a successful business largely on top of your platform, there needs to be a lot of potential customers for them to acquire on it. It’s actually even harder than that though. It’s not just about volume. The core product needs to support a wide variety of customers and use cases. Otherwise, developers believe they will eventually need to compete with the core product when the company builds that feature itself, and the platform will of course have an unfair advantage. External developers build on top of extension platforms when they spot an opportunity to monetize something for customers on the platform they know the company won’t build itself. Usually, this is because it is just for one segment, niche or country when platforms usually only build horizontal features. Practically, this means most extension platforms won’t materialize until the company is already successful internationally.

One other major factor that is rarely appreciated by companies pursuing this strategy is that the company needs a robust technology platform to support external developers. Developers are doing a cost benefit analysis. Why should they build on your platform? Yes, your customer base (i.e. their potential demand) is the biggest incentive. But if your technology is wanting and your documentation poor, the benefit is less likely to justify the cost. Developers will ask questions to figure this out. They’re going to inquire about your APIs, your SLAs, and your capabilities. If the company would be embarrassed to have to answer those questions, you may not be ready to build an extension platform. Wondering if you are robust enough? Ask your own engineers.

Now that we have defined the differences, let’s look at them on the same vectors as the types of marketplaces.

Click to view in more detail.

Supply Value Prop
Remember that supply in a platform is the group of external developers. In an integration platform, suppliers integrate with a SaaS company to improve their product/market fit, which increases their customer retention. For example, Mailchimp integrates with WordPress to make it easy for their customers to increase email subscribers from a WordPress site. In an extension platform, external developers do receive this value prop, but also list on the extension platform to find new customers. Acquisition becomes the primary value prop for the majority of developers. Shopify, for example, has multiple venture funded companies for whom the majority of their new customer acquisition comes from Shopify, like Shippo or ReCharge.

Demand Value Prop
Remember that demand in a platform is the SaaS company’s existing customers. In an integration platform, the main value prop of the customer is being able to integrate two tools customers already use so they can do things faster. Going back to the Mailchimp example, WordPress bloggers can integrate with Mailchimp to automatically send emails to subscribers when they post a new blog post to their WordPress site. Occasionally, an integration platform can make your customers switch to a tool similar to one that they already use if that integration is more robust. In an extension platform, customers look at external developers’ offerings for new functionality the core platform doesn’t offer. In an integration platform, the platform offers the ability to browse apps and search for specific integrations like “Evernote” or “Dropbox”. Think of this as the platform equivalent of branded search. In an extension platform, while branded search remains, a higher percentage of searches become unbranded search like “CRM” or “subscription.”

Payment
The question of control over the payment for platforms is similar to the one for marketplaces that we covered in the previous post. That is to say, when the platform controls payments, it has more flexibility to monetize the transaction, a greater ability to broker trust between developers and customers, and the ability to make the platform experience better for both supply and demand by improving payments. When Gilad evaluated this at Eventbrite it was clear that the benefits of owning the payment system didn’t outweigh the costs. Monetization of integrations isn’t a high priority since their primary value is in driving retention, trust is less of a challenge since most apps used by customers are known SaaS brands, and the experience of paying for integrations directly to the developer works well and is relatively infrequent. Therefore, at Eventbrite we chose to have the payment to the external developer happen off the platform. So, if an Eventbrite customer decides to integrate their Eventbrite account with SurveyMonkey, they pay SurveyMonkey separately from Eventbrite. That’s typical for integrations platforms—the SaaS customer pays the two SaaS tools independently from each other. However, in an extension platform, evaluating the same criteria usually yields a different result. Monetization is often a priority, the platform is generally far more trusted by customers than the majority of developers building on it, and the platform has room and incentive to improve the payments experience for customers and developers. So, in an extension platform, the platform typically is the payment provider for all developers selling tools on the platform and uses its own payments and billing infrastructure, like Apple’s in app payments. 

Demand Side Branding
In an integration platform, there is heavy co-branding of the two companies that are integrating. Integrations pages feature logos of other successful companies extremely prominently. In an extension platform, there is still co-branding, but because so many apps are bespoke to the extension platform, they lead with their value prop rather than with their corporate logo much of the time.

The top result under popular WordPress plugins is “Contact Form 7”, and in tiny font it says who built it. Contrast to Slack, where their popular page is all focused on brands.

Customer Service
This is an area that trips up some companies as they build out platforms. Companies need to build out an entirely new type of customer service to a totally new customer: other developers. This includes API documentation and support. For a platform, external developers are a hybrid of customer and partner. So often, the support function will grow out of business development, which, as we discussed, is how most companies get the first partner companies to build on their integration platform. As a company continues to build out the platform though, the support structure begins to include dedicated API support, partner management, developer support engineers, and technical writers.

Trust and Quality
Once a company embarks on any platform strategy, it has to determine if the apps on it are actually driving customer success and satisfaction. For integration platforms, this potentially can be managed in an internally facing way where the company polices or deletes apps that are not successfully serving customers and promotes apps that have high retention or satisfaction scores. In an extension platform, this typically becomes externally facing to customers with ratings and reviews.

Refund Policy
In comparison to many marketplace models, refunds are mainly handled by the supplier, the external developer. In an extension platform, that refund is more likely to pass through the platform’s payment flow, meaning refund tools need to be built into that system for developers to leverage.

Fees
Integration platforms don’t typically charge fees to external developers to be on the platform. For extension platforms, this can become a significant part of the business model. Apple, for example, charges 30% for in-app payments, and mandates usage of in-app payments for many types of transactions. Shopify charges 20% for payments, but app developers can choose not to use their payment solution.

Extension Platform Strategy

Committing to building an extension platform is a major strategic decision. It has implications for technical architecture, resourcing, the company’s own product roadmap, as well as its relationship with customers. 

One major strategic difference between pursuing an extension platform strategy vs. a marketplace strategy is how decisions are made that affect customers. In marketplaces, companies tend to centralize decision-making over time. So, the dominant marketplace strategy is to deeply understand the market and your supply of customers and control more of how they run their business to streamline the experience for demand over time. Extension platforms require decentralization of decision-making. External developers will decide more and more of the product experience your customers receive over time by what they decide to build and maintain. You can incentivize developers to move in a certain direction, but not control them.

Do not make this decision lightly. In order to pursue this strategy, a company needs to have a good understanding of what value it wants to provide, and what value it wants external developers to provide, and to design the platform in a way that incentivizes external developers to work on the right things and not the wrong things. Then, it needs to create rules or boundaries so that in a decentralized world, the product offering still generally goes in a direction that is good for the company. A framework the two of us have used to talk about this is to ask four questions:

  • What does the company need to own?
  • What does the company want to compete to win?
  • What does the company want to attract?
  • What does the company want to reject?

The best way to confuse a bunch of executives at a company is to ask the simple question, “what does this business need to own to be successful?” It sounds like a simple question, but it is most certainly not one. It’s a question all businesses need to answer, but particularly important for extension platform strategies as companies want to make sure external developers don’t build what the company needs to own. It’s a question Casey first had to answer at Grubhub, and subsequently at Pinterest and now Eventbrite. At Grubhub, the answer was the easiest. Grubhub had many partnership opportunities as they scaled, and they’d be willing to give partners data and allow them to build experiences that mutually benefited both companies. But Grubhub would never give partners customer data or delivery boundary data as that would allow partners to rebuild Grubhub more easily. Grubhub needed to own demand to win, and to keep proprietary data around restaurants to make the restaurant network functionality harder to recreate. At Pinterest, that question was harder to define, but as Pinterest developed an understanding of itself as a data network effect company, the user and pin data became a clear answer. Another common answer is owning the payment, which may be practical from a monetization standpoint, and for a marketplace, to enforce trust. This was true for Airbnb.

Deciding to own something means not owning it is an existential threat to the business. For example, at Grubhub Casey was part of a decision to reject integrating with Yelp because Grubhub would not have access to the customer data, and owning demand was the most critical component for Grubhub’s strategy. There are many other areas of a product you may want to own, but competitors are not existential threats, and there will be valid reasons your customers may want to use an external partner for them. We call these areas in which you want to compete. Shopify would love to own email marketing for all their customers, but know that some of their more sophisticated clients will upgrade to dedicated email providers with more functionality. So, they compete by offering their own email marketing tool, but also integrate with third party email marketing tools as well.

The attract category consists of things the company definitely will not build themselves, but wishes the core product would have to enhance value. For example, Salesforce does not build phone software, and they do not feel doing so would fit their core competencies. So they wish to attract integrations with call center companies sales teams use, so the data of length and volume of calls gets integrated into Salesforce. Dozens of companies and consultancies have since been created to enable this for Salesforce clients.

The repel category are apps the company does not intend to build, and they do not want external developers to build them either. For example, Apple rejects apps that disintermediate their relationship with developers, like Facebook Gaming, Google Stadia, and Xbox xCloud service.

Answering these four questions really well while developing a platform strategy can prevent many headaches in the future. Developers have plenty of examples of the rules changing on them because companies put off answering these questions like Apple’s recent spat on requiring in app payments with Hey and marketplaces that pivoted to online models during the pandemic, or Twitter’s numerous policy changes for bots, clients and monetization, or Shopify and Mailchimp breaking up in public. Just as platform companies want to avoid breaking changes for developers at the API level, they owe it to them to minimize strategic u-turns. Now, no amount of forethought can predict possible outcomes years into the future. A critique of the extension platform model is that more and more goes into the “compete” bucket over time, and the platform starts leveraging unfair advantages in that competition, like Spotify having to pay Apple 30% for in-app purchases, but its competitor Apple Music does not. Even with that critique, the more a company figures out how they want developers to be involved the less likely these scenarios are to emerge later. This is another danger of a “build it, and developers will come” approach to platforms. You may not like what they bring.

—
While many companies desire to be a platform, they don’t honestly know yet what that means for their business. While most SaaS companies need to add integrations over time, extension platforms have stricter criteria for being a successful long-term strategy and even stricter criteria for how to execute them well. Mapping these appropriately to your business and making the right strategic moves can be all the difference, and always superior to a “build it, and developers will come” approach that has plagued many companies interested in this direction.

Currently listening to my Ambient playlist.

The Problems With Martech, and Why Martech is Actually for Engineers

Since I spent some time in VC land and have a background in marketing, a lot of people ask me about martech, or technology built for the marketers. Are these good businesses? Which tools should they use/are on the rise?

In short, I hate martech, and think martech will decline as a category, and most martech businesses will not be very successful. I think there are a few reasons for this that are not well understood, but if you understand them, it can unlock some martech opportunities that are still quite large for entrepreneurs, and help marketers understand which technologies to bet on vs. bring in house. The main misunderstanding is that successful martech is actually for engineers, not marketers. Let’s talk about why that’s the case.

Martech is a Response to Engineering Constraints
A controversial opinion I have stated before is that the marketing function in technology companies is usually a response to engineering constraints. If you don’t have enough engineers to build a system to manage bidding for performance marketing, you hire a marketer. If you don’t have engineers that can work on SEO, you hire a marketer. If you can’t build a great email system, you hire a marketer. Most key marketing roles are manual tasks that can better be solved with engineering. The smartest marketers, realizing this, started automating a lot of their work through third party tools, and if they could, even better, first party tools. This is how martech exploded over the last decade. Marketers actually had important, if not critically under-weighted, responsibilities for the company. For example, I was in charge of getting new people to try ordering online at Grubhub, and to keep them coming back once they did. My team used a lot of martech tools to do that.

Engineering Constraints Are Being Laxed
While hiring engineers inside companies to solve these problems is still extremely competitive, engineering constraints are (slowly) being laxed across every technology company I meet. Startups and technology companies today have many more engineers working on more functions (due to improvements on engineering technology) than we had at Grubhub during similar stages of our company.

These engineering constraints being laxed means martech companies have to compete with the engineers at the company for the best way to solve a marketing problem. And besides there being more engineers in a company to work on these problems, engineers are now more likely to want to work on these problems or reject these tools as best practices. Growth teams have emerged to work on a lot of the traditional marketing problems marketing teams bought software for: email, SEO, landing page optimization, onboarding, etc.

Martech now finds itself in a more competitive environment since “build” in the “build or buy” equation is more likely than it used to be. Also, if engineers inside a company do decide to build instead of buy a solution, a lot of times what they build is more effective than what the martech provider can offer. This is not to say engineers inside tech companies are better than engineers inside martech companies; engineers inside tech companies simply have unfair advantages. Not only can engineers building the solution for their company build directly to the needs of their company instead of adapt some generic solution; they can also more easily integrate with the data needed for these tools to make the right decisions. It is notoriously difficult, for example, for many martech tools to integrate conversion data, and certainly much harder for lifetime value data. This is much more easily done with an in-house built tool.

Platforms Also Limit Martech’s Reach
Martech companies face the squeeze from the other side of the integration as well. Usually, martech companies integrate into some other system: advertising companies like Google and Facebook, adtech companies like exchanges and demand side platforms, email service providers and email clients, etc. What happened is these martech companies built value added features on top of a platform to deliver extra value to customers. What is happening now is those platforms are either integrating those best features themselves, so you don’t need the martech company for it anymore, or deleting the access that enables it, because the platform doesn’t actually want that level of transparency.

Where Can Martech Be Successful?
So these companies have the platforms stealing their features or cutting off the access that makes them possible on one side, and engineers at the companies of their clients building deeper integrations themselves. So, if most martech solutions have a disadvantage to competing with in-house engineering solutions, or the platforms starts competing with them, what type of martech tools have an advantage?

Option 1: Leverage Data Network Effects
One key example where martech thrives is when the external data becomes more important than the internal data. If a martech tool can be gathering data from multiple companies, and create a data network effect from this aggregation, thereby helping all companies improve in a way they could not on their own, they are very defensible. Sift Science is a great example of this. By being used as a fraud provider across thousands of companies, they have data any individual company won’t have in determining if a transaction is fraudulent or not.

Option 2: Manage Pain
Similarly, integrations with a bunch of key operators or vendors are very defensible in martech. Litmus is a classic example historically. Email providers have notoriously finicky rules around what renders in their systems and how, and they are not very transparent. Engineers and designers hate coding for email, and it’s hard for them to remember all the rules for all the different types of email clients. Litmus allowed you to preview what your emails looked like across all major clients to spot errors before you send the email, and generally became an all-encompassing email QA tool. No engineer internally wants to build that, and they will never be as good as Litmus at doing it because Litmus has been doing it for billions of emails, so it has seen many more cases, and has better integrations with email providers. Another example of removing engineering pain is Heap Analytics, which auto-tags events, removing one of the most painful parts of setting up a new analytics vendor.

Option 3: Leverage Cross Side Network Effects
A more modern example is the customer data platform companies Segment and mParticle. These companies integrate with hundreds of other companies marketers use for various purposes: web analytics, conversion tracking for performance marketing, crash reporting, et al. Integrating these companies saves engineers time because they integrate once, and any other solutions they need can now be enabled instantly. These integrations not only help marketing, but product, and engineering as well. These companies have created a cross side network effect between customers and other technology providers. Data platform companies are hard to rip out once you integrate because they are so integrated in all of your processes.

The Real Answer: Change the Target Customer
Okay, so all of these are great options, but they actually share one thing in common: they have really shifted the target customer to the engineer instead of the marketer. Sure, the marketer may be the person requesting the solution, but the solution is chosen because the engineers like it. Many things an engineer has to do are painful, and as much as engineers like to solve their own problems, if you show value to them, they will appreciate it. So I am very bullish on engtech companies masquerading as martech. Other examples of this besides the ones above are data visualization platforms like Mode and Periscope.

Bonus Option: Pick the Right Marketing Customer
One other strategy that is very successful for martech companies is to build targeted solutions for the types of companies where marketing is more central to the organization’s success. While marketing is ebbing in importance in most tech companies, one area it is thriving is in ecommerce companies, whose main playbooks are logistical on product delivery, and where brand + performance marketing drive all sales. The product is something delivered offline, so the product and engineering teams are more subservient to marketing than in other functions, and because the product is delivered offline, these teams usually have less engineers than other companies. Narvar is a great example for ecommerce tracking. Buffer is a great example for social media marketing. Canva is a great tool to help design creative for marketing campaigns and social media posts.

—

Martech is a very challenging space for an entrepreneur. If you are going to tackle it, there are distinct strategies like data network effects, pain management and maintenance, and cross side network effects that make it more possible to build a sustainable business. Approaching the right customers, either in role (engineering) or space (ecommerce) also make the road easier.  If you have any other tips on building a great martech business, feel free to leave them in the comments.

Currently listening to Slide by George Clanton.