As a product manager, your responsibility is the current and future state of the product. And that means creating and managing a sane product roadmap. However, by their very nature, integrations seem designed to derail that roadmap and otherwise cause problems.
Let's consider why this is and what you can do to mitigate the risks from incoming integrations and even turn integrations to your advantage.
Integration challenges for product managers
Misaligned priorities
Everyone has opinions about integrations: which ones should be done, how soon, and for whom.
- Customers would like all the integrations as soon as possible.
- Sales would like to sell everything that customers want, and if you don't have an integration, let the customer know it's on the way.
- Customer success wants to sell customers all the integrations they need to stop churning, whatever those may be.
- Executives, looking at the big picture, want to ensure that you have all the integrations your competition does, plus enough whatever you need for a competitive advantage.
Meanwhile, you are attempting to balance core product development with integration development that actually helps move your product forward, provides real value for all your customers, and keeps up with general market expectations. It can be an impossible task.
Insufficient scope management
Many SaaS companies are still using a largely reactive approach to integration development. That is, they work on the squeaky wheels – the integrations that are considered most important because they will make customer X happy (and we need customer X to be happy) or because someone in the company has heard that everybody is doing an integration with Y (so we need to do an integration with Y).
Unfortunately, this reactive approach wreaks havoc with your product strategy and vision. You have limited dev resources; when those resources work on integrations, they aren't available to work on the core product. Yes, integrations are important, but they aren't the core product and aren't usually the reason customers are lining up at your door.
When you must constantly shift your dev team from core product work to handling urgent integration requests, that results in reduced product velocity, a growing number of missed features, mounting tech debt (as the team codes as fast as possible so it can get back to "real" development), and a negative impact on team morale.
If your devs are focused on creating an MVP, the resulting integration will add the use cases provided by a few customers (maybe only one). This means that when the next customer comes to you with a slightly different use case, you are in the position of either needing to modify the existing integration to cover the new functionality (while ensuring that it still works for everyone who is using it today) or building a second integration that is 90% the same as the one you already have. In either case, maintenance and support become more difficult.
Degraded UX
Software purchasers buy apps because of their features, but leave them because of the user experience.
Integrations are frequent offenders for poor UX. Part of this comes from them requiring configurations and flows that don't fit naturally into your core product. In addition, ad-hoc integrations can drive a very inconsistent user experience, where no two customers have the same integration UX. Meanwhile, as the product manager, you are held responsible for the integration UX, even though you have no control over third-party APIs.
In-house integrations often don't include any UI for non-engineering users in the organization to support an integration. Such UI is seen as a waste of time and is not in the scope of a dev team trying to build an MVP. However, integrations lacking support UI are a continuous resource drain on your devs when something goes wrong, often extending the time it takes to resolve customer issues (since everything must go through engineering).
Performance issues tied to the UX can also drive down user trust. If an integration is sluggish, regularly times out, or fails to sync data completely, it will frustrate your customers. Users may see a failure in one area as indicative of problems in another and start wondering how secure this setup is (is your SOC 2 certification up to date, are you GDPR compliant, etc.).
How to address these challenges with Prismatic
Establish a process to prioritize integrations
Using an embedded iPaaS fundamentally changes integration prioritization by shifting integration development from a frustrating free-for-all to a scalable, data-driven approach. The platform enables you to deliver integrations faster, so you can prioritize based on business impact and customer value rather than engineering capacity constraints.
Integration requests often get deprioritized due to disproportionally high engineering overhead, but an embedded iPaaS can help launch powerful product integrations in a fraction of the time it takes you to do it in-house.
Integration projects prior to Prismatic would take on average about two months. And now it takes, on average, under two weeks.
This speed reduction transforms the classic effort vs impact matrix – integrations that were once high effort, high impact become medium effort, high impact, fundamentally changing your prioritization calculus.
In addition, our embedded iPaaS enables productizing your integrations, so you can build an integration once and deploy it to every customer who needs it. This creates a feedback loop that allows you to track the integrations with the highest activation rates and usage patterns across your customer base. Unlike custom in-house integrations, this approach lets you see if your original expectations were accurate and adjust things accordingly.
Create a repeatable integration lifecycle
The traditional integration lifecycle is fragmented across teams and often lacks standardization. Prismatic provides a comprehensive toolset for the complete integration lifecycle (build, deploy, manage), creating consistency and reducing handoff failures.
Setting up a standard build process with all the steps needed to ensure the quality output you need is easy.
Prismatic beautifully supports the model we wanted: technical support staff configure new instances of known integrations; software engineers get involved when there's something new; support staff can monitor what's happening day-to-day. Meanwhile, we can focus engineering cycles on adding value for our customers.
This flexibility means your lifecycle can adapt to different customer segments without forcing you to use separate tools for each segment. All of these options are available via a single platform.
Post-deployment is where many integrations become resource drains. But it doesn't need to be that way. With Prismatic, integrations in production are easily managed and monitored. Reduce your internal workload with customer self-serve support tools. Give customers and CS teams visibility with detailed logs. By moving monitoring and basic troubleshooting away from engineering, you also free up capacity for new development.
Build integrations with appropriate UX
Poor integration UX creates technical debt and customer support burdens that continuously pull resources from roadmap priorities. Prismatic addresses this by helping you turn your integrations into first-class pieces of your product with a user experience that extends your core product.
You can empower customers to self-activate and configure integrations with just a few clicks, giving your integrations a first-class UX. Customize colors, design elements, and branding to ensure embedded functionality matches your product. This native experience means integrations feel like core product features rather than something bolted on after the fact.
Use config variables to design integrations that can behave differently from customer to customer and cleanly handle customer-specific endpoints, credentials, and more. This approach prevents the common scenario where customer-specific development leads to one-off code branches that become maintenance headaches. It also ensures that each customer is only asked for the information they need to provide.
In-house integrations generally require engineering involvement for setup and troubleshooting. With Prismatic, you can shift this to non-devs in your support team. Or, let your customers build their workflows with our embedded workflow builder. This reduces the support burden on your resources while giving customers greater control over their integration UX.
Make a better product roadmap with integrations
By addressing these challenges, you can balance integration needs with roadmap directions while executing a sustainable integration strategy. Your integrations will be products in their own right, with all the oversight, planning, and process needed to build, deploy, and manage them for your customers.
Reactive integration processes lead to much pain and suffering. However, creating a proactive approach ensures that integrations are not removed from the equation but become essential functionality for your product and customers.
Embedded iPaaS platforms like Prismatic transform integrations from roadmap disruptors into predictable, scalable products that can help accelerate your go-to-market strategy.
Sure, you could address B2B SaaS integrations in other ways: build them in-house, get a third-party to develop them, set up an API and turn your customers loose, or "just say no" to integrations. But none of these approaches will provide you with the long-term value of our embedded iPaaS.
Schedule a demo and we'll show you how Prismatic can help you create an integration strategy that supports your roadmap, instead of derailing it.
