SaaS Product to Platform: How Your Integration Capability Gets You There

​​We often say that the "gold standard" for your integration capability is when you are able to productize and externalize what you do internally to build integrations for your customers and partners.

In other words, you take the best practice that you've established, which includes integration tech, process, API, and much more, and you give it away. You allow others to build to you, so you don't always have to do it yourself. You open it up to the world.

To build a SaaS platform, not just a product, you must reach this milestone. You must be able to democratize "how we do it in house". Otherwise, you never provide your ecosystem of customers and partners the means to build "on your platform".

But, this doesn't happen overnight. You can't just buy being a platform.

Two fundamental and conjoined things must happen for you to get there: 1) You must develop an ecosystem led-strategy that eventually leads to becoming an ecosystem authority and 2) you must build an integration capability that you productize for that ecosystem.

This post will start with articulating a way to think about the difference between a SaaS product and a SaaS platform. Then, it'll get to how you gradually mature your integration capability to support a platform strategy.

What is a "SaaS platform"?

The word "platform" gets thrown around a lot, and most people don't even think about why they are saying it. However, there are some generally accepted definitions for what it means to be a platform.

Credit to Sunir's (from Cloud Software Association) post about channel conflict and Jeff Gardner's 2019 talk at SaaS Connect about transitioning to a "platform" from a "product" for this Bill Gates quote. Both also share fantastic content about this product->platform concept.

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

A platform is software that has its own ecosystem--its own gravity. People build businesses on and around it. It's usually pretty open and fairly unregulated, unlike a traditional sell-through channel. Platforms provide tools and build community around their core offering.

Think Shopify, Hubspot, the iPhone, or Windows. Billions (trillions?) of dollars in economic value have been created simply because solutions like this exist and are open enough for other companies to build businesses on them. They almost have their own sub-economies within them sometimes!

And, while it's helpful to define the term "platform", for this post it's actually more helpful to understand how a platform is different from a "product".

Why is a platform different from a product?

Put simply, a product is a thing that does a thing.

Your car transports humans from point A to point B. Your couch is for sitting. Your vacuum cleaner is for cleaning floors.

The same is basically true of software products, even if their digital nature can make them more flexible than your vacuum. Your email marketing product is for designing and sending emails in bulk. Your CRM is for keeping track of sales leads and opportunities. Your accounting system is for financial reporting.

It's exceedingly rare that a product is born, day one, as a platform. Most software endeavors start with a problem and piece of software that solves the problem (a product).

It's why you hear the term "product" over and over in the software business. It's why we have job titles like "VP Product" and "Product Manager" and "Product Marketing". It's why there are philosophies like "product-led growth". Software teams almost always build products--at least to start.

Some products are able to evolve into platforms. Most do not. A product, no matter how sophisticated, complicated, or expensive it gets, is still a product if it's fundamental quality is that the software company licenses it to users to solve their problem. Contrast that to making it available for the ecosystem to build on top of to solve many problems.

And, while it's generally easy to contrast a product from a platform (consider Salesforce versus a thousand CRMs you've never heard of), it's less clear what the journey between "product" and "platform" looks like.

Integrations and the Journey to "Platform"

According to Allan Adler, Managing Partner at Digital Bridge Partners:

The power of platforms is when you light up the network (aka the ecosystem). Platform business models are composed of a network of multi-sided participants who inter-dependently create a new market. In tech, many of these participants are ISVs who will not do the hard work to participate in the network unless the platform owner has a mature integration capability because the integrations create the network & define the interactions.

Let's be clear, integration is not the only thing that will make or break your journey to becoming a platform. Building an ecosystem of partners, nailing marketing/branding, understanding how to service customers, and virtually every other part of the business plays a part.

We want to focus on integration's role in that journey because 1) it tends to be underappreciated in its importance and 2) it's where we spend most of our time and energy at Blended Edge.

Your ability to mature from a product to a platform is largely influenced by the development of your integration capability. In other words, you will never successfully execute a platform-focused strategy without building the muscle to create connected, cross-product experiences between your product and others in the ecosystem.

Integrations are what create those cross-product experiences. You must develop a competency to deliver those integrations.

Mapping your journey to "platform" shouldn't look like "doing a bunch of stuff until you get to say 'platform'". Mapping the development and maturity of your integration capability gives you more of a step-by-step guide to getting there.

Consider the following maturity model for an integration capability and how that relates to your journey to "platform".

Integration Capability Maturity Model

The following is a five-phase maturity model to consider how your integration capability drives your journey from "product" to "platform". Use this to gauge where you are today and to understand where you should be headed next.

Integration Agnostic

Integration agnostic companies haven't started to consider integration or the creation of cross-product experiences as part of their product roadmap. Instead, these companies have a dedicated focus on their own product. They often adopt principles of product-led growth strategies, which engrains that perspective further.

If the team is handling integrations at all, it's reactively (probably begrudgingly) to customer requests. To this company integration is probably a box to check off to close a sale or keep a customer. It's not part of strategic conversations.

It's most common and most appropriate that early software product companies fall into this category. How can you worry about integrating your product if it still doesn't accomplish it's primary purpose, right?

However, being integration agnostic is something that a product team must grow out of to consider scaled, long-term success. It's kind of like training wheels on a bike. Totally appropriate for the right age group and ability, but it won't cut it in the Tour de France.

In summary, integration agnostic companies can be identified with the following:

• Integration and cross-product user experiences are not part of the roadmap
• Heavy focus on product-led strategy
• Common (and even ok) in early stages, but problematic if you don't grow out of it

Getting to the Next Step

Integration agnostic companies are at risk of ignoring the inevitable need to provide an integrated software product. Integration shouldn't dominate the conversation, if you are early in your product journey, but consider the following:

• Map out your ecosystem. Consider competitors, complementary solutions, and unrelated products with a shared customer base.
• Seek to understand how your customer sees this ecosystem.
• Talk to your customers about what cross-product experiences would improve their lives.
• Make plans for providing a proper, externally facing API if you haven't already done so.
• Get your product fundamentals right. A useless, but integrated product won't get you there either.

Integration Aware

Companies become integration aware when they begin to recognize that integration isn't going away--that it's something that must be taken seriously to accomplish their growth goals.

These companies probably have a repeatable enough go-to-market strategy that frictions in the sales process are starting to drive changes to products and services. Integration requests will start to regularly create some of this friction, which means a natural ROI for integration emerges.

The challenge, though, is that these companies aren't built or staffed to solve integration holistically (maybe not at all). Thus, integration aware companies will tend to start throwing approaches against the wall, getting it done however they can.

This haphazard integration approach will probably work for a while, but it'll start to get messy. The mess commonly includes an opportunistic mix of homegrown integrations, referrals to a friendly consultant or iPaaS, politicking tech partners to build the integration, and semi-manual processes based on file transfers or database queries.

These companies know integration is a problem, but they haven't really built the muscle or experience to solve it in a scalable way.

In summary, integration aware companies can be identified with the following:

• Beginning to recognize that integrations aren't just one-off requests that you begrudgingly consider
• Recognizing sales and retention friction caused by lack of connectivity
• Dabbling with ways to provide integration, often haphazardly partnering or building bespoke

Getting to the Next Step

Integration aware companies are starting to get the value integration brings. However, they risk creating a lot of technical debt if their haphazard, experimental approach to integration lasts for too long. They should consider the following:

• Make a point to assess (early and often) the approaches to integration that are taken.
• Even with imperfect information, decide what your chosen approach(es) for integration at scale is/are going to be.
• It's rare that building everything bespoke/custom is an effective way to go. Start to investigate integration technology vendors that align with your approach.
• Start to take your partnership strategy seriously. Dedicate resources to it.

Integration Capable

Companies who are integration capable have an intentional approach for delivering integrations. They may still be experimenting and tweaking that approach, but they aren't reacting to requests or haphazardly trying different ideas anymore. This is where integration starts to really add value to the product.

This integration capability might include product team ownership over integrations. It should for at least ecosystem imperative integrations. But, it likely includes a portfolio approach where both internal and external teams take joint responsibility.

The key to being integration capable isn't that you've settled on one approach to connectivity that you dogmatically force every request through. It's that you approach integration requests through a consistent decision framework, which helps to eliminate variability. Furthermore, integrations also start to be considered within the overall product roadmap, instead of as alternatives to the items on that roadmap.

Additionally, integration capable companies start to see technology partnerships as a strategic competency, too. This is often the business development counterpart to integrations, and at this phase the two begin to overlap more frequently. This is the germ of an ecosystem-focused platform strategy.

In summary, integration capable companies can be identified with the following:

• Defined, but not necessarily mature, consistent approach to providing integration
• Learning how to incorporate integration into the overall product roadmap
• Partnerships are starting to drive more business as a strategic counterpart to integration

Getting to the Next Step

Integration capable companies have the muscle, but haven't built it yet. The risk at this stage is never seeing the maximum return on the investment of time and money put into the integration program, because it stalls progress. They should:

• Focus on building a center of excellence around integration delivery--more predictable, more reliable, faster.
• Expand organizational awareness of integration's importance. Consider basic integration training for team members who won't be directly involved, just to build understanding.
• Ask outside vendors involved with integration delivery to help your team get better at integration. Push them to get better as well, because there's mutual benefit.
• Start to use the integration capability as a force multiplier for the partnership program. Being able to handle integrations really reduces tech partnership friction.

Integration as a Core Competency

Companies who develop integration as a core competency are able to operationalize providing integrations at scale. The list of companies who achieve this level really starts to whittle down, because it takes investment in technology, in team development, and in strategic execution to get here. It's not easy.

Integration as a core competency is mastery of your integration capability. It likely means you provide dozens, perhaps hundreds, of productized integrations to other systems. It also probably means that you can reliably deliver bespoke integrations for enterprise customers (or where it makes financial sense to do so).

By this point, you're usually taking a larger share of responsibility for delivering integrations (less outsourced). Additionally, you've not only established a technology approach, but you've become really good at executing it. Your team has probably started to scale horizontally. Integrations are discussed in ROI terms before anything else.

Few companies reach this point, but even few go farther. Companies with integration as a core competency tend to be quite valuable and can start to find themselves in M&A conversations. It's because many integrations times many now stickier customers tend to generate strong valuations.

Your tech partner strategy has also probably evolved into a full ecosystem-led strategy. Much like how you build integrations, partnerships aren't a reaction to customer requests that remain unfulfilled by your product. Partnerships are objectives in the context of ecosystem positioning.

In summary, companies with integration as a core competency can be identified with the following:

• Full recognition of ecosystem-led strategy combined with at-scale integration program
• Mastery of primary integration approach, multi-faceted with secondary approaches
• Integration a key driver of new and retained revenue

Getting to the Next Step

Once you develop an integration as a core competency, it's time to stop looking exclusively inward and start looking outward. Teams looking to productize their mastered integration capability should:

• Evaluate and begin working on the technical approach that will implement a paradigm change to ecosystem-provided integrations.
• Reorganize your internal integration capability to act as an external stakeholder.
• Integration and ecosystem should be a frequent topic of conversation in the boardroom.
• Build the governance and marketing frameworks to support a democratized, platform approach to integration.

Integration as a Product (i.e. Platforms)

A company's product becomes a platform when they are able to provide the integration capability as part of the product. All the sudden the paradigm flips from mastery of capability to democratization of that same capability.

But, why?

Being a platform means other companies get to build solutions on top of your product. It means you are a foundation to what they offer, and likewise your success is driven by theirs. The notion of "building on your product" is fundamentally integration. Their solution and yours work as a cross-product experience.

It becomes in your best interest to remove any barriers to entry for competent, capable teams to build onto your platform. Providing the integration core competency to your partners and customers as a set of features--usually for free--removes those barriers. It makes it easier for them to "build on your product".

You'll even start to treat your internal integration team as an external stakeholder, even though they literally aren't. They just become customer #1 for the democratized integration capability, and they will build right alongside those teams who are outside your walls.

A shift occurs in the ecosystem strategy as well. Where previously your positioning within the ecosystem was the primary goal, now you become an ecosystem authority--perhaps the ecosystem authority. People building economic engines on your product means you are the central gravity of the ecosystem. It means you are no longer a citizen. You are the mayor.

Companies that reach this level are uncommon and incredibly valuable, both to their customers and partners and in terms of M&A. It's really hard and really expensive to get there. It is, however, achievable.

In summary, companies that transition to treating integration as a product (platforms) can be identified with the following:

• Integration capability is exposed to customers and partners as a feature
• Outside companies build revenue streams on top of and around your service
• Transition from ecosystem-led strategy to acting as an ecosystem authority

The Gold Standard Isn't Easy

It takes time and discipline to build to the gold standard, whereas as an ecosystem authority you are able to democratize how other providers build to your platform. While ideally this is something you consider part of the plan, day one, you can't just make it so.

Understanding the roadmap to evolving your integration capability will help you get there. Understanding how that complements the evolution of your partnership and ecosystem strategy is also critical.

Achieving the gold standard is rarified air, but the companies who get there are the most valuable software companies in the world.