This is part 2 in our series on How to successfully build B2B SaaS marketplace integrations. In part 1 of the series we explored both authentication and authorisation requirements. Now, in part 2 we focus on the key technical challenges in data integration. In particular, we discuss how SaaS platforms can transfer data between one another to help create a seamless customer experience.
There are limited, good quality resources to help SaaS leaders create mental models for successful SaaS marketplace integrations. This series of resources attempts to systemise the mostly ad-hoc analysis, conducted in isolation, by product and technology teams.
We hope to provide a meaningful framework so you can integrate with various marketplaces to grow your SaaS business.
Before we get into some of the technical detail of data integration, we will cover the basics of APIs and product led growth. Then we dive into a discussion about how to conduct your very own marketplace integration analysis.
Note: If you’re unsure about the benefits of connecting to a SaaS marketplace, have a read of Why software marketplaces should be part of your SaaS growth strategy, by our CEO Matt.
SaaS companies, platforms and the rise of SaaS marketplaces
To understand the rise of SaaS marketplaces, you have to understand the consequences of product led growth for SaaS companies. What’s more, it’s important to understand how these consequences have led to SaaS marketplaces becoming a core component of a product offering.
SaaS is a fairly mature industry. Over the past 20 years several unicorns have been born out of the SaaS model; charging a software subscription fee for a product that is delivered via the cloud to your device.
A tried and tested approach, popularised by Paul Graham, is to build a product for a niche group of users and then expand from there. Perhaps the most famous example of a successful company taking this approach is Amazon. Amazon focused on selling books online in its early days and has now expanded to millions of products and services.
Once SaaS companies dominate a niche they need to expand beyond their initial set of users to continue growing. SaaS software is, by design, easily updated and changed. So as part of their product roadmap, software companies typically start integrating with other complementary products or providing the ability to integrate. Integration candidate selection is based on improvements to customer experience and product adjacencies in the end customer’s stack.
How APIs can create a SaaS product ecosystem
To enable product integrations, SaaS companies can either start by opening up API level developer access for end (should this read end user?) business customers. This lets customers self-serve the integration and fulfil their needs. Or they can create the integrations themselves and provide it as part of the service.
SaaS companies can create an ecosystem around their product by allowing API integrations, which allows for a 1000 flowers (use-cases) to bloom. This can only be effectively delivered via partnerships. Alternatively, they go deep and build a specialised set of integrations to create a seamless end user experience. In either case, a marketplace is born. A marketplace that also allows partners to show off their product integrations. Hosting and growing a SaaS marketplace is a win-win scenario.
In the next section we look at the process to integrate with a major SaaS marketplace with the intention of being listed on their platform.
SaaS marketplace integration
use-case analysis
Before we jump into the next section, it’s a good idea to get a basic understanding of different types APIs. Please see our overview here.
Now let’s focus on how to prepare and execute a use-case analysis that helps the team identify an end user journey that creates a delightful and seamless user experience.
For our purposes, we will assume that this brainstorm includes three archetypical roles: a product lead, an engineering lead and a commercial lead. Given the stage of your business you might have multiple people representing each role. Or it might just be the founders trying to wear all of those hats themselves.
Like all good projects, the first step is to go wide and learn about all aspects of the business context before getting together for a meeting.
I am a big fan of asynchronously starting work on a collaboration platform such as Slack, Notion, or Teams. Then everyone gets into a room to discuss the work to date. I prefer this approach over having a meeting to “kick-off” the initiative.
The first step is to go wide and learn about all aspects of the business context.
Manish Pahwa, StackGo
For each role, I suggest that you identify the key activities and responsibilities needed. Then share this with the team before the brainstorm.
Using this approach you will ensure everyone is on the same page. Sharing this article with the rest of the team is another good way to get everyone on the same page. 🙂
The role of the Product Lead in data integration projects
In a SaaS organisation, a Product Lead usually sits at the intersection of the engineering, commercial and growth functions. They represent the voice of the customer and are pivotal when running experiments for new features.
For the most effective brainstorm, the Product Lead should take on the facilitator role. They should also be accountable for tracking tasks.
Founders, due to their close relationship with the product, can also make a great addition to the product team. Or use them as a sounding board throughout the process.
Here are the key activities a Product Lead must do:
1. Create the discussion space
Ideally this would include a place to share (or link to) documents that you pull together as part of the research. As well as another place for real-time, directed conversation for the integration team.
Some ideas for how to do this include:
- Creating a dedicated space in your document system (Google Drive, Notion, Dropbox etc.)
- Creating a new, dedicated (and persistent) chat channel that has the right team members invited. Tools such as Slack, Teams, Discord etc. are good options here
2. Collaborate and guide the agenda with other team members
As part of the lead facilitator role, the Product Lead will work with other team members on timelines for their actions. To do this effectively they need a high level plan.
Two weeks is usually ideal for this phase of the data integration project. The first week is used for setting up and researching information. The brainstorm then happens at the end of the second week.
3. Technical areas of focus for data integration
Now that we have discussed some of the hygiene factors for setting up a SaaS marketplace integration project, let’s discuss what else the Product Lead must focus on.
- Align the intention. This could be an email or requirements documents. It needs to be something that the whole team can read and share. Please see here for some templates you can use.
- Understand customer needs. This information often comes from the customer support and customer success teams. Very often the genesis of the SaaS marketplace integration happens from conversations or ideas from these teams.
- Identify lighthouse customers. These are customers of yours and of the platform that you already have a great relationship with. They’re customers you want to work with as you explore the new product integrations. Lighthouse customers will provide honest and useful feedback. Product Leads should initiate conversations with these customers to identify areas of functional overlap between the products.
- Understand the SaaS marketplace platform. What is the profile of their customers? Which segments do they target in their marketing? What is their pricing model? What is their key value proposition? Who are their competitors and do they have marketplaces?
- Reach out to the ecosystem or the partnerships team at the marketplace and start a relationship. These contacts can usually point you to the best resources to share with your team.
- Understand what co-marketing opportunities exist by asking for that information directly from the ecosystem teams. Product Leads should also research guest blog posts on the SaaS marketplace and look through the “Top Picks” section of the marketplace.
- Document the competitive landscape of the SaaS marketplace. Within this they should identify how are you going to carve out a niche and communicate it to your users.
The role of the Commercial Lead in data integration projects
The Commercial Lead needs to understand the deal structure that comes with integration and listing in the SaaS marketplace. They need to understand the leverage points that will help drive revenue through the partnership.
To this end the commercial lead should spend their time investigating and sharing information on the following:
- Reaching out to the partnerships team to understand the commercial terms for marketplace inclusion.
- Understanding the commercial model. Will it be revenue share or single billing? Or will it be something else for sales transacted through the marketplace?
- Creating sales projections based on the new audience that the SaaS marketplace integration will bring.
- Understanding the effect of adding this new channel to your sales pipeline.
The role of the Technical Lead in data integration projects
As the Technical Lead, you will be responsible for the data integration and overall SaaS marketplace integration. It is important to have a mental framework to assess the different types of marketplace integrations.
Here are some of the key items to keep in mind:
- Understand your API capabilities. Depending on your own product you may have already significant data integration expertise. For others, this might be their first time. Either way, it is important to do a review to understand if there are code refactors that can help you through the integration. StackGo’s offerings can reduce months of effort to connect and work with SaaS marketplaces down to weeks.
- Go through our How to successfully build B2B SaaS marketplace integrations resource that walks through the whole process of creating a SaaS marketplace integration and authentication.
- Play with other marketplace integrations. Looking at integrations that have been built by others will help you understand what works and what some of the established patterns are. If you have clear competitors with the same integration, then understanding what they have done is good experience to have.
- Go through the developer and API documentation.
- Sign up for a developer account and join the developer community. This way you can ask questions or get clarifying answers as you do your planning and research.
The main thing that a Technical Lead needs to get clear is an understanding of the data flow between the applications. They need to understand how the data integration and flow can be used to deliver the use case.
Following are some key mental models to keep in mind while thinking through the use cases.
Type of data flow: By direction
One-way sync
A one-way sync can occur in two ways – from marketplace to SaaS application and vice versa. This is a simpler pattern as there is no interdependence between the platforms. It essentially enables data migration from one area to another.
Unfortunately not all of the SaaS marketplaces support REST in its entirety. They are more likely “RESTful” rather than REST. This means that for each “resource” that you want to pull, you will need to ensure that the data relationships for the resources can be pulled as well.
Additionally, for sustained pulling of data you will need to take into consideration (and respect) the API limits. This is an important variable because each platform has its own limits. When pulling data the results are usually paginated. There are two different ways of using paginated API responses – cursor based and limit and offset based.
Two-way sync
A two-way sync is also referred to as a bidirectional sync. With this data integration pattern the SaaS application and the marketplace keep each other in sync about their user’s state. This type of data integration is useful when both systems need different parts of the user’s data for different actions.
A two-way sync helps reduce inconsistencies that a partial view of the data can lead to. This type of data sync is usually justifiable for use cases where there is a central system of record. And where the state is required by other SaaS applications to analyse or improve certain data segments.
Correlational sync is another variant of this pattern. It’s where, instead of syncing data between the two platforms, you want to associate data between the two systems. This means that each platform can have a contextual linkage with the other side and create relationships between the data on both sides. For developers this is analogous to adding a foreign key to two different databases.
Type of data flow: Temporal
The other way to think about data transactions between SaaS platforms is to understand how the order of each data flow is structured.
Batch mode
This is a simple, scheduled job. It is similar to a background job that syncs both systems every ‘x’ time interval. It is the easiest temporal data flow integration to implement and the easiest to visualise. But making the sync frequency higher and implementing naive syncing techniques can lead to unnecessary load generation because of redundant data transfer.
These days due to the increased interconnectedness of apps, this approach rarely delivers the seamless customer experience most consumers expect. However many consumers are prepared to put up with a less than excellent experience, should the need be strong enough.
Aggregation
This pattern is one which is familiar to lots of startups in their own right.
The aim with the aggregation approach is to make the apps and system less confusing. It does this by helping the user pull their data from different source systems into a single aggregated view.
For example, if you are a product management app, there are many different inputs you need to consider, organise and track. You need to ingest data from marketing, engineering, customer success, data science and sales platforms. Using an aggregation pattern will create a configurable tool that allows data to be synced with the right filtering and alterations for the user.
Real time mode
This type of data integration is only live for the user’s session. It allows for an end user in System A to call up data via api – is this word correct? calls from System B in “near real time”. This approach gives the user contextual information without having to open up new sessions.
The real time mode has an added privacy benefit; the user’s data is only persisted for the session. What’s more, it doesn’t create additional overhead by storing items into the app and the associated privacy and storage concerns.
Webhooks
Event based systems and design are pretty popular these days in software architecture.
The basic idea behind webhooks is that System A triggers when certain events happen. For example when a user signs up, a new order is received, a customer abandons a cart, etc. This information is sent over to System B with a pre-defined URL pattern.
System B listens for the URL and completes any actions necessary once it has that information. For example: send an email, pull shipping prices, create an offer etc.
Wrap up
Hopefully this discussion about data integration and SaaS marketplaces gives you a basic understanding of how to identify and rate different types of SaaS integration requirements and their complexity.
In our next instalment, we will move away from an abstract approach and we will analyse real life integrations and integration examples. Make sure to read part 3 of our series on How to successfully build B2B SaaS marketplace integrations to access resources to help SaaS companies build their own marketplace integrations.
