%2520(1)%2520(1).jpeg)
Product managers play a key role in making sure tech partnerships come to life. They often manage and oversee the process of building external APIs and product integrations.
Clement Kao is the co-founder of Product Manager HQ, a community dedicated to providing career advice for both aspiring and experienced product managers. He’s also a product manager at Blend, a fintech startup, and he has extensive experience building and launching multi-million dollar products and integrations.
Clement shared his very detailed advice for product managers who are looking to build product integrations in the most efficient and effective way. He explained the technical questions to ask before you start, how to think about configurations and the integration UI, and why technology partnerships need both strategic alignment and detailed road maps.
For me, the biggest challenge comes before a single line of code is written: ensuring that both integration parties are aligned on the problem they’re solving and on the rewards they’ll reap by working together.
In my experience, I’ve found that the single biggest factor for SaaS product integrations success is an aligned charter. And, the single biggest factor for failure is a misaligned charter.
I’ve seen too many integrations fail because one (or both) parties didn’t clearly understand the purpose of the integration from the user’s perspective.
If the end user doesn’t get any benefit from the integration, then there’s no point building the integration. It doesn’t matter if you believe that you’ll gain market share or you’ll gain more revenue. If the user has nothing to gain from it, then everyone’s time is being wasted.
Another point of failure I regularly see is that one party stands to gain disproportionate value from the integration, and the other party doesn’t gain much at all. Then, the party that won’t gain much will keep deprioritizing the initiative, leading to failure. It has to make sense for both of you, or else you won’t jointly prioritize the work and ensure that the integration happens.
One way to help level the playing field is to set up a revenue-sharing clause in the partnership contract. That way, the party who “wins” the most will share some of those winnings with the other party, so that both sides are ready to act as a single team.
The key is to start from the problem statement. Who is the targeted end user and what pains are they facing? From there, we can identify a set of integration initiatives that will unlock value for both the end user and for the SaaS product company.
From there, evaluate the potential upside for each integration initiative, as well as the potential cost and effort for each. Divide the upside by the cost to come to an ROI evaluation, and then stack-rank the initiatives. The one that provides the highest ROI should be the one that gets done first.
In terms of configurations, those also come from deeply understanding which user personas we’re focused on, what pains they face, and what their day-to-day work looks like.
For example, say your targeted customer is a call center, and their 6-step process for inbound calls is to:
If your proposed integration only covers assigning a customer representative (step 2), taking notes (step 4), and sending an email (step 6), you’re covering non-continuous steps in their flow.
If this call center were to adopt your product, they’d have to complete the other parts of the flow using their existing set of processes, unless your product is so good that it eliminates all of the other steps in between.
Since their existing processes are built around existing tools, your product scope will cause friction in adoption. After all, they have to go back to their old processes and tools to complete their work for steps 1, 3, and 5 - so why wouldn’t they just stick with what they already have?
It depends from integration to integration, honestly. Some integrations have no user experiences and are entirely hidden from the end user - for example, a backend data validation integration might have no end user implications at all.
But, let’s say that both products do have their own front-end UX. In that case, it’s important to consider where the user’s initial entry point was. If they first came in from your product, then your product UX should be the core of the experience. You then have two options when it comes to the integrated feature:
1. Surface the third-party’s UX within your own product
2. Use only the backend APIs of the third-party product, and rebuild the UX within your own product
In cases where your end users don’t expect to run into many different integrated experiences, you’ll want to take the second path so that the user experience looks and feels consistent. It’s more work on your end, but you also have more control over the experience.
The flip side is true too. If the end user is going to have the majority of their experience within your partner’s product, consider whether it really does make sense to enforce your own UX on top of it. Solve for the end user, and not for your own ego or your brand presence.
In my experience, I’ve found that the first two or three integrations for any SaaS company are always the hardest, because that’s where you have the least experience. So, if you try to build a robust abstraction right out of the gate, you’ll likely mess up and have to redo the whole thing.
Therefore, the first two or three integrations should be one-off custom integrations, because that’s where you’re honing your skills and understanding the different patterns of how your product works in an integrated way.
After that, you’ll then want to consider how to abstract the integration so that it’s no longer custom and one-off. After all, if you keep building custom integrations, you’re going to be bottlenecked by your integration development velocity, and you can only scale linearly.
There are ways to increase your scalability, depending on the direction that integrators build.
If you’re typically building your product outwards to integrate with other services, then consider creating an integration interface to transform custom fields to map to your standard fields. This reduces the maintenance cost of having to deal with every single integration as its own beast - now you can properly abstract particular families of integrations.
For example, in certain cases, if you’re integrated to multiple CRMs, you should be able to use a “CRM integration interface” as an abstraction layer, rather than needing to maintain dozens of dedicated integrations (one for each CRM provider). For example, such an interface would provide you with a consistent way to think about standard data elements such as the lead object, the name of the lead, the creation date, etc. That interface then means that your core team can build out the core functionality, whereas you can now bring in 3rd parties (e.g. contractors) to wire up the custom mappings between your core interface and the specifics of the partner product.
If others are typically building integrations into your product, consider creating public APIs and external-facing integration guides. That way, rather than needing to get on the phone repeatedly to guide others on the build, you can offload more of the work to them. And, if you create a public API, that means that others can come up with creative new use cases based off of the functionality that you already have.
In terms of the customer support side, one of the key things to clarify between you and your partners is the support model. If something breaks, which party is responsible? That then informs the level of visibility to the end user, the SLAs involved, and the procedures to take in addressing the problem.
A native integration is particularly powerful when you’re looking to drive very specific behaviors. The challenge with a native integration is that you’re permanently on the hook for maintaining that native integration.
A third party integration tool is great for broadening your reach. The drawback is that you have less control over user flows and user experiences.
First, ensure that you’re thinking strategically about your integrations roadmap. Don’t just automatically agree to the first integration proposal that you get, and don’t agree to integrate against an infinite number of partners.
Integrations are product strategies that come with upsides and tradeoffs, so be thoughtful with the integrations roadmap and strategy. See my answer to the question above on how to prioritize.
Second, document everything that you can. These artifacts will help guide you in your future integrations, so capturing your knowledge now will pay significant dividends later.
Third, ensure that you and your partners are aligned on the charter and the purpose of the integration.
Fourth, do as much upfront planning as you can. With integrations, I’ve found that the devil really is in the details. A minor missed detail upfront can literally cost months of development effort to fix.
Related Content: Marketing Integrations and Tech Partnerships: Everything You Need to Know
Here’s a real life example: I was building an integration alongside one of my customers, so that I could integrate my product into their internal systems. For more than two months, we had issues where neither of us could successfully call each other’s APIs, and we were both mystified. No matter how many emails we sent back and forth, we couldn’t get to an answer. We were both sure that our respective APIs were being called with the right set of parameters and with the right logic. That is… until one particularly astute engineer noticed that our product had case-sensitive parameters, whereas our customer’s system was case-insensitive.
In other words, something like “userName” had to be spelled exactly that way for our system to work, whereas our customer might try to call our functions with “UserName” or “username” and those calls would fail.
It took so long for us to find the problem, and all of that could have been avoided if we had spent time planning upfront and digging into the details! So please, spend disproportionate time upfront on the technical details. Even if you’re not a technical product manager yourself, lean on your engineering team to surface as many assumptions and questions as possible.
Here's what I have found to help:
1. Have your team draw out the proposed architecture diagram and the sequence of network calls (which module is talking to which module, and when?).
2. Walk through this diagram with your integration partner. You’ll frequently find that some modules need to be combined together, and others need to be separated out. Or, you’ll find that some of the calls are sequenced in the wrong way. It’s so crucial to ensure that you’ve got the right foundation in place!
3. Once you have the high-level flows in place, start asking detailed questions.
You don’t want to write a single line of code until you’ve gotten all of these questions answered:
The general principle: during the planning phase, get into the details and document your decisions for posterity. That way, if your integration succeeds (and hopefully it will!), you and your partner can build even more integrations together, and your past work will already be cleanly documented for both of you to work off of.
The KPIs depend on the problem that you’re trying to solve.
If you’re building for a high-value, high-frequency use case, then you want to look at utilization: how often are your users taking advantage of this new integration? And, for the users who do take advantage, are they able to get more value out of your product (and therefore enable you to reap more value)?
Related Content: Building a Support Strategy for Your B2B SaaS Integrations: Key Considerations for Product and Technology Partner Managers
If you’re building for a high-value, low-frequency use case, then utilization isn’t the way to go. Rather, identify which contracts or strategic customer accounts you’ve unblocked by delivering this integration.
And of course, you need to ensure that you have reliability. Be sure to measure the number of bugs, and to track the uptime of the integration. If the integration’s performance is slow or if it breaks too often, you need to invest more heavily in shoring up its technical performance.
Integrations are so powerful because they enable you to specialize and focus on your product’s core capabilities, while relying on others to further extend your product functionality and your audience. But, they’re also really hard to turn into reality. Integrations require intense levels of coordination and trust, and you need to be well-organized to actually bring your integration to life.
By ensuring that you have a clear game plan for driving clarity, alignment, and coordination, you’ll dramatically increase the chances for success for both you and your integration partner. And, by fully leveraging your soft skills, you can make even the toughest, most nuanced technical integrations much easier to bring to life!
