As a Product Manager, choosing the right embedded iPaaS tool can make or break your project. With so many options, it’s easy to be drawn in by flashy promises that might not align with your actual needs. Here are three pitfalls to avoid when evaluating embedded iPaaS solutions to ensure your integrations are built for scale.
1. Don’t Be Swayed by the “Ease” of No-Code/Low-Code Solutions
No-code/Low-code platforms (sometimes referred to as workflow builders) are tempting because they promise fast deployments and simplified processes; especially if you're a non-technical PM. However, relying too much on these solutions will create more integration challenges as you grow.
For example, imagine you have customers requesting multiple CRM, marketing, and analytics integrations (Salesforce, HubSpot, Mixpanel, etc.). A low-code tool might enable your team to quickly set up basic integrations, but the moment customers need additional customizations, it gets more complicated. More often than not, you’re in trouble and your engineers have to create complex workarounds, making the “ease” of your low-code tool, not so easy.
Here are three questions every product manager needs to ask when evaluating an embedded iPaaS tool.
Question 1: Do I need my integrations to be primarily real-time or trigger-based?
This question is asking if something happens on another platform, do you need to immediately react to it?
Example: When a new comment is left on a deal in HubSpot, do I want to immediately import that data to my platform?
-
If the answer to the above is yes, you’re likely a great fit for a workflow builder like Tray or Paragon - but read question two before deciding.
-
If the answer to the above is no, real-time triggers aren’t as pressing, a unified API or scheduled batch syncs like what hotglue provides would be a great fit.
Question 2: How much data do I need to process?
Do I need my integrations to get just a few records, or do I need to pull a large amount of historical data/write data in bulk?
-
If the answer to the above is a very small volume of data, unified APIs and workflow builders could work well.
-
If the answer to the above is a lot of bulk data, unified APIs and workflow builders are not ideal. A more ETL-based approach like hotglue is going to be a stronger solution..
Example: SaaSGrid - Think of SaaSGrid being the standard for SaaS metrics reporting. They sync your CRM, billing, and expenses data to monitor every part of your SaaS business.
SaaSGrid’s use case for hotglue was simple. They needed a solution that would allow them to build powerful integrations - but also a way to sync large volumes of historical data for reporting purposes. hotglue was the perfect solution for both of those needs.
Question 3: How much effort is required to build, extend, or maintain integrations?
Does the platform allow me to build my own integrations from scratch? Does it provide sufficient tooling and docs to speed up development?
Asking these questions forces you to get into deeper questions like:
- “Will I be able to integrate with niche APIs, or will I be at the whim of the iPaaS vendor’s connector roadmap?”
- “How much freedom do I have to add support for new endpoints and functionality on existing connectors?”
These organizations were building lots of niche/ad-hoc integrations until they became too cumbersome to maintain.
They moved to hotglue to centralize their connectors and avoid wasting valuable engineering resources on integration maintenance. hotglue allowed them to centralize all their integrations and manage them in one platform, complete with API’s, logging/monitoring, job executions, authentication management, etc – thereby saving their teams time and freeing them from integrations-related code debt.
Digging into these questions helps you realize what kind of embedded iPaaS you actually need. Since many iPaaS competitors use the same language and buzzwords, the only way to really know which tool does what is by asking in-depth, integration specific questions.
Important call out - it’s not that no-code/low-code tools are bad or don’t offer any value. They’re great for many reasons, but their ideal fit is for simpler use cases and trigger-based workflows.
Here’s an example of a no-code/low-code workflow based on the HubSpot example given above.
Example: A new comment is left on a deal in HubSpot and you want to immediately push that comment to Slack.
-
Trigger: New comment on HubSpot deal
- Integrations: Connect HubSpot + Slack
- Trigger event: New comment on deal
- Filters: If you want to filter by specific types of deals or choose specific fields within a deal (e.g., comment, commented by), you can add conditions as necessary
-
Action: Post to Slack
- Action event: Send message to Channel
- Message structure: Construct the message that will be sent to Slack
- Channel selection: Choose the Slack channel where the comment will be posted
No-code/low-code solutions are great for these types of trigger based scenarios. They’re simple to build and they get your data from point A to point B pretty easily.
But if you’re a growing company with a need to process large amounts of data, you’ll likely need a solution with more integration depth and customization. That’s what you’ll get with a code-first embedded iPaaS solution like hotglue.
2. Avoid Ambiguity in Project Ownership
Many of the roadblocks PM’s encounter when working on integration projects are centered around unclear ownership. Here’s what we mean…
Conceptually, it makes sense for PM’s to scope out a project with their devs, align on requirements, agree on responsibilities, and create timelines for execution - but reality tells us this doesn’t always happen.
Three things happen when teams are NOT aligned on embedded iPaaS requirements:
- Integrations get delayed - causing setbacks with customers, prospects, and internal teams
- Rushed decision making - due to delays, there’s an increased pressure to make a decision
- You (the PM) are held responsible for the results
When there’s ambiguity around a project, it results in a misguided purchasing decision. To avoid buying a half-baked embedded iPaaS tool, here are seven questions we encourage Product Managers and Devs to discuss when evaluating these solutions.
-
Who will ultimately be the owner of the tool? Product or Engineering?
Defining the owner may limit your decision making to either a low-code/no-code workflow builder or it can give you an advantage by using a code-first approach.
-
What is the complexity of the workflows we need to automate? Are there multi-step, conditional, or asynchronous workflows that low-code tools might not handle well?
-
How do you anticipate scaling these integrations as your user base or data volume grows? Would a low-code solution be able to handle this, or do we need the scalability that comes with a code-first approach?
-
Do you need to implement custom encryption, tokenization, or other security features that a low-code tool might not support?
-
How important is it for the team to use Git or another version control system for these integrations? Would a low-code tool's versioning capabilities suffice?
-
How critical is collaborative development, and would a low-code platform hinder or help in maintaining code quality and consistency?
-
Do you expect the need to integrate with new, emerging technologies or APIs that might require a highly extensible toolset?
Evaluating embedded iPaaS solutions can be difficult - but you’ll save yourself a ton of time and energy when creating as much internal clarity as possible.
3. Don’t Default to the HPPO (Highest Paid Person’s Opinion)
Lastly, avoid this trap. It’s easy to assume that the most senior or well-paid person’s opinion carries the most weight. After all, they’re successful for a reason, right? However, blindly following “HPPO” logic can lead to costly mistakes - especially with embedded iPaaS.
Embedded iPaaS solutions can be vastly different. Many in this space use the same terms and examples, complicating the marketplace and your buying decision. We want you to make the best choice possible for your business. But if you aren’t careful, the words of someone who is paid more or someone whose voice is the loudest in the room can lead to poor decision making. As the project lead, listen, understand, express your thoughts and concerns, but make the decision you believe fits all requirements, rather than a biased opinion.
Once you’re ready to make a decision, commit! The right embedded iPaaS partner can rapidly change how quickly you can make a positive impact in the market. They can be an incredible extension of your dev team, and hopefully, they are equally as excited to work with you as you are to work with them. So, be proud of your purchase decision.
Summary
When evaluating embedded iPaaS tools, it’s easy to fall into traps like prioritizing no/low-code solutions, allowing project ownership to remain unclear, or simply going along with the highest-paid person’s opinion. By avoiding these pitfalls and prioritizing a deep understanding of your team’s needs, you’ll be in a much better position to choose a solution that aligns with both the short and long-term goals of your business.
Remember, it’s not just about finding what’s easiest - it’s about finding what works best for the future of the business. That’s what hotglue’s here to help you accomplish.
