Technical experts from ShipBob and Pandium shared their framework and processes for designing, scoping, and prioritizing multi-purpose, high volume SaaS integrations.
From user research, to design, to prioritizing MVP features, they provide a practical guide you can implement in your next integration project.
In this context, a "multi-purpose, high volume SaaS integration" is an integration that handles a large volume of data or transactions between two or more software applications. This is typically used by businesses that needs to move large amounts of data between different systems or applications on a regular basis.
Read a summary of the event or watch the video below.
When building multi-purpose integrations aimed at serving many users, the user research process aims to answer the following questions:
Before starting user research, it is important to talk to three groups of people.
The first group is your stakeholders, who are typically internal and include people such as sales representatives, account executives, and heads of different departments and strategies.
The goal here is to gain alignment and gather feedback, as they are usually the closest touch-points to the end users and can provide insight into their needs.
Once you have talked to some stakeholders and have gained alignment on the direction and strategy, they can recommend the next group of people to talk to, who are the users.
%2520(1).jpeg)
Users are the most important group to talk to, as they are the ones you are building for. It is essential to get users involved early and actively in the development process, as their feedback can help validate direction and build relationships for potential beta users.
The main objective is to involve users early and actively in the development process to ensure that what is being built is for them. The feedback gathered from users can help validate the direction and build relationships for potential beta users.
The beta testing phase is a delicate process that requires careful selection of participants.
You can't just approach anyone and ask them to be a beta user, as it requires a significant amount of time and effort on their part.
Beta testing is like a dance, and you need to be selective when choosing beta users.
The product may not be in its final state during the beta phase, so you want to ensure that you're working with individuals who are willing to provide constructive feedback and engage in the process.
The third group of people to consider, especially for integrations, is the partner manager. While it may be difficult to connect with a partner manager, they can be a valuable resource as they have extensive knowledge of the tech stack on which you are building.
All in all, you want to have access to someone who can be a source of knowledge and truth for the other SaaS system you're building with.
For example, a Shopify partner manager would know the Shopify documentation inside and out, providing support throughout the entire development process.
When you start talking to users, especially with integrations that involve a B2B play, you need to talk to specific individuals within that company who will be using this integration.
They will be the ones toggling settings, testing the UI, and so on.
Therefore, it's best to conduct as many user interviews as possible. All in all, questions asked during the user research phase are for gaining insight into end users, including their current work behaviors, constraints, and potential workarounds to achieve their goals.
This allows you to identify user personas, needs, limitations, and suggestions that can help improve your product beyond what your competitors offer.
This also provides valuable insights into what they really need and want.
User interviews and feature request reviews - are the most immediate ways to gather feedback, and the more you do, the better your understanding of user needs will become.
Designing an integration requires breaking it down into core components to effectively analyze each piece individually. This process is essential for prioritizing certain features and understanding what can and cannot be done.
Related content: How to Integrate Systems Like a CTO: 10 Best Practices
The first step to designing an integration is to begin at a high level with the business case.
What problem are you trying to solve with the integration? For example, if a significant portion of your user base is using a specific platform, building an integration for that platform may be necessary to support your core users or attract new prospects.
%2520(5).png)
By breaking down the integration into smaller pieces and analyzing each one, you can effectively prioritize features and ensure the success of the integration.
Once you have established the business case for your integration, the next step is to break it down into specific use cases.
A use case could involve automating a flow from one platform to another when a user triggers a specific action. Once you have defined these use cases, you can then break them down further into specific data flows.
a data flow shows the movement of data between systems or components within a system. It illustrates the path that data takes from its source to its destination, including any transformations or processing that occurs along the way.
Related content: A Guide to Integrating With NetSuite's API
A data map is a document or a diagram that shows how data elements in one system relate to data elements in another system. It describes the transformation that needs to happen to the data to enable it to be transferred between the two systems.
A data map typically includes the source and target systems, the data elements being transferred, the transformation rules, and any business rules that apply.
Let's say you have an e-commerce website that is integrated with a shipping company. When a customer places an order on your website, the order details are sent to the shipping company, and when the order is shipped, the tracking information is sent back to your website.
The data flow may be written in a Spec Doc like:
The first flow represents the flow of new order data from the e-commerce website to the shipping company, while the second represents the flow of tracking information from the shipping company back to the website.
The very simplified version of a data mapping for this from one system to the other could look like:
Mapping data fields involves identifying the data elements in the source system and matching them with the corresponding data elements in the target system.
The very simplified version of a data field mapping for this from one system to the other could look like:
Where the data data fields represent how data should be transformed and transferred between the systems, ensuring that the target system can process and make use of the data.
Note that in some cases there might be some required fields for your integration that might need transformation of data. This would require an additional step of mapping where the platform you're integrating with has a certain set of values that you have to hit when making calls to the API.
This might require som sub mapping to make sure requirements are met.
After the data mapping exercise you can begin to notice requirements like this or fields that don't align at all. Analyze these gaps to figure out if there is a workaround or another endpoint that could be used or if there is a product change required.
If an integration involves an API, consider the system limitations on both sides. Examine the API documentation, understand how to authenticate with the other system, and identify any other relevant considerations.
When designing an integration, one common limitation is rate limits, such as the number of requests per second or minute that can be sent to a target system.
Share documentation including the data flows, data map and gap analysis with the technical teams that will be building this integration. Review it with them and provide level of effort for each data flow.
This will allow the product and engineering team to prioritize what will be included in the MVP and phase 1 of the integration and what will be included in future iterations.
A great integration not only connects two different software applications, but also provides a seamless user experience for customers.
Related content: How In-App Marketplaces Create a Competitive Advantage for B2B SaaS
Integration UX is critical to customer adoption and retention. Customers expect integrations that work seamlessly with their software and fit into their workflows.
In-app marketplaces offer a centralized location for customers to discover, evaluate, and purchase integrations that are pre-vetted by the application provider.
This ensures a certain level of quality and reliability, which boosts customer confidence in the product ecosystem.
By offering integrations through an in-app marketplace, you can provide a better user experience and make it easier for customers to find and adopt the integrations they need.
To access a sample spec doc, as well as more guidance on designing, developing, launching, supporting, and iterating on SaaS integrations for your users, download our end-to-end guide here.
