About product partnerships and integrations
An overview on integrations and how they come into play as a PM
Product partnerships and integrations come in various forms and are tied to different KPIs. Sometimes they can open up a segment of the market that your product currently does not serve. Other times, their purpose is more directly tied to improving functionality for your existing users. In either case, the integrations your product chooses to pursue and actively market are reflective of the product vision.
In this post, I want to share a bit about these partnerships and what aspects are important to think about as a PM.
What is a product integration?
At the end of the day, customer-facing software integrations allow users to benefit from functionality that otherwise would not be possible. Mind the Product adds that integrations “also expose the depth and breadth of an SaaS product that may not be immediately apparent. This gives added incentive for a user to open the product, and use it for a longer period of time.”
Again, integrations come in various forms. A basic example of an integration is from one of my favorite products, Spotify, a company whose initial and sustained growth has a lot to do with leveraging networking effects via social sharing functionality. If you want to share a song or playlist you are listening to, you can do so directly from the Spotify app. This is not accomplished through magic! Engineers made this easy experience a reality so users would not have to take a screenshot of the song on their phones and leave the Spotify app to ultimately share it with friends.
How do product integrations come into play in product management?
Integrations play a larger role at companies that have open APIs. The company I work at has an open API, which essentially means that other products that cater to legal professionals can build functionality that their customers might benefit from (ideally, we have a similar customer base that consists of users who all reap the benefits of the integration). I frequently speak with potential integration partners who want to know the nuances of how our product behaves. From a business standpoint, the integration adds to our feature set and should result in a combination of 1) new sales 2) upgrades and/or 3) enhanced product engagement.
Of course, 2-way product integrations (example: information being displayed to users in both applications) take time and can only be accomplished with active participation from both sides. For that reason, they must be scoped out ahead of time and be slated for the product roadmap. Just like with all other feature development, I’ll ensure that we are performing the proper market and design validation exercises to ensure we 1) actually should be working on the integration (does it provide enough value to our users and business?) and 2) build a great product. One thing to note is that integrations also present great marketing opportunities, and it is important PMs loop in marketing teams ahead of time to plan GTM activities such as blog posts and webinars.
Evaluating integration partners beyond customer needs
Ensuring there is a true customer need and an apparent value to the business overall is the first step, but a deeper dive is required. Here are other aspects of integrations that I will consider:
Pricing / business model — not all integrations involve money changing hands or commercial deals, but for those that do, this is an important consideration. You don’t want to offer great functionality to your existing customers if it’s going to cost them a lot of money (unless it’s perhaps part of a new pricing strategy) or result in your company losing money. However, if you are pursuing a white labeled integration for instance, this will require a deal between products and a unique structure to make it both sensible and scalable for the purchaser.
Ease of implementation — this part requires the engineering team to take the lead on. It’s important that PMs are clear with high level goals/requirements and the central use cases that are important for users. But the successful development of an integration hinges on technical aspects like clear API documentation, a compatible code base and a process for troubleshooting any errors that might occur. It is essential that as many open questions as possible are resolved before a single line of code is written and that back end changes that may be necessary are accounted for.
Potential of future functionality — as the PM, it’s important that you have a good sense of what customers need now and might really love later. This is where versioning comes into play. And if the feature inherently relies on an integration partner’s technology, any limitations of the technology will be passed on to you and your users! This is why it is not only important to consider the partner’s technology in its current state from an implementation point of view, but also to ensure any future functionality that you might have planned will be feasible and have a great UX.