Integrations are a part of many product managers’ lives. Let’s talk about how to think about integrations, and how to choose vendors.

When I say third-party integration I mean three types of things:

1. You integrate with a library to build a product or a feature on top of it
2. You integrate with a product, maybe you white label it, maybe not, to provide an extended functionality as a part of your solution;
3. You provide integration or connector to the third-party system so your customer can have an ecosystem with a unified workflow where there is an ability to pass data/triggers from one application to another and your software is a part of that workflow.

In this article, we will talk about points 1 and 2.

Why do you need integrations?

Let’s talk about integrating third-party libraries and make them an invisible part of your solution all while integrating products and making it a part of your solution.

Why do you need those kinds of things? When you evaluate the solution space you think about different paths:

• Building it from scratch
• To partner
• Integration

If it is a core part of your product or business, then it is important to build the solution to have full control of it. Alternatively, it’s important to acquire a company if you don’t have time to build it from scratch.

If this part of your product is not a core part, then it makes sense to consider integrating with third-party systems. For example, instead of creating your library, you can integrate a third-party library to get extended functionality. A great example is integrating a machine learning library and using it in your application.

It can be something bigger than just the library, it can be a product that you can white label and make a part of your application. It makes sense to do that if it’s not a core part of your solution. Extending your product will attract wider market segments or a new customer segment.

Sometimes particular features are part of the buying checklist. If you don’t have it, your product is excluded from the consideration from the start. The funny thing is that a particular feature can be out of scope for a company, but having the feature can be a sign of serious software for a users’ checklist. If you don’t have it, you are not good enough.

As an example, I can imagine archiving software that you, as a PM would want to add to your product in a regulated vertical like law or banking, where it is required to store all the data for several years. In this case, an ability to archive data can be a part of a buying checklist. At the same time, archiving can be out of your product focus.

You can do the integration by yourself — if you have resources — or can alternatively hire a contractor as it is not a critical part of your product. In other words, you have more options and more flexibility here.

Vendors research

If you decide to integrate something into your product you need to start with research.

What companies are in the market space and who can you use for your software?

You need to understand the target company profile. It should be something that you can trust and partner with. By making it a part of your application you add additional risks associated with the third-party system. If the third-party system fails it will impact your product — your customers don’t care whether it’s some kind of third-party library or something in your product — the customers will think that your product failed.

Log the research experience from the beginning. These notes can be useful to do a post-analysis and create a process to evaluate vendors in future.

There could be tiny red flags — don’t miss them. Be careful when you research vendors. I had a poor experience where the company created an expectation of a big company, but in reality, it appeared to be two or three developers. I found this out after we signed the contract and started the development. It was pretty frustrating.

Another reason why you want to know about the company size and funding stage is the upcoming future. You don’t want to partner with a company that can be acquired by your competitor.

Scoring

Create your own list with scores to evaluate alternatives. Highlight the items that are important for you and then score the vendor based on your scoring system.

You can create a questionnaire based on your scoring table and provide the document to companies to get all the answers.

For example:

Scoring:

0- there is no such a feature

1 – Poor

2 – Good (enough for us at this point)

3 – Has outstanding or unexpected features

	Vendor 1	Vendor 1
Features….	2	3
Pricing	3	1
Languages supported	3	1
SLA	2	0
24/7 support	0	2
Response time	1	2
Data Centers in counties of our presence	3	3

What is the sales process?

Pay attention to the sales process. How fast does the company respond? (If they respond at all). I experienced many cases where the companies asked me to fill out a long-form before talking to a salesperson and they never contacted me even if I followed up.

Notice how they work with your questionnaire. Does the salesperson adjust their presentation based on your questionnaire to cover the topics you are interested in? Or just following the script regardless?

The sales team is the first group that greets you at the very beginning of your partnership. It can give you an insight into the company’s culture. For me, it is important to work with vendors who share my values and the values of my company. It means that we can find common ground.

Check reviews

Check reviews. Try to find the ones to help you understand what the pros and cons of working with that particular company are. This can provide information and give you the right questions to ask during your research phase.

Check the “our clients” section and recommendations. Ask questions. How big is the company?

I’ll ask questions like how big the company is and how many people work in the outsourced resources team.

It’s important to understand how stable the company is because if you build your product on top of that solution and then the company stops operating, issues arise when trying to find a replacement.

Company and data centers structure

If you have an international product, understand where the data will be stored and where it will be transferred. It is a sensitive area, which is why you must understand the law of the countries where your product has a presence to make sure that your vendor supports all the legal requirements.

It applies not only to the data storage but also to the support centers as support engineers access data during the case resolution.

SLA (Service Level Agreement)

SLA – Service Level Agreement – is a commitment between a service provider and a client. Particular aspects of the service – quality, availability, responsibilities – are agreed upon between the service provider and the service user.

Does the company provide an SLA agreement? You need to understand what guarantees they provide. It is also helpful if your product has an SLA. Make sure that integration will not lower your SLA as a result.

Response time

Imagine you found a bug or have a question. What is the guaranteed response time?

Don’t get me wrong, I’m not a pessimist, but knowing the risks and ways to mitigate the risks is what you need to do with your product.

When something goes wrong you need to understand:

• What will be your escalation path?
• Whom should you contact?
• What will be the response time?

Bugs

How would you act if a bug that is critical for you is a low-priority bug for your vendor? What mechanisms do you have to increase the priority and expedite the fix? What would be the prioritization workflow?

If you don’t have any mechanisms, then you may be in trouble. I had a case where we waited for a fix for around six months. During that time the bug failed one of the scenarios and we constantly received negative feedback. We couldn’t change the vendor without rebuilding the product. Feels like a trap, right?

Plan B

Ideally, you need a plan B in case the quality of the vendor is not good enough. It will minimize your risks. Everybody hopes that Plan B is something they will never need, however it increases your confidence and provides the way out. Third-party systems can ruin your product’s reputation. This is why it is so important to take care of all aspects of the potential integrations.

Security

If you do regular security checks or audits, you need to understand how to proceed with the third-party system. Will you do one audit, or will you audit the third-party system separately?

Will the third-party company be open for the security audit?

Error handling

Think about error messages you provide to your customers in case something is wrong with the third-party system.

There are cases where you can tell more and explain what went wrong. For example, if you use an external service to validate the address, then you can say that the address service validation is not available at the moment. If you can do so, do it. It will provide additional information and decrease the level of frustration.

Summary

After all, you may think that integrating with a third-party system is painful and not worth it. That’s not true. Integration with a low-quality vendor is painful, however, integration with a high-quality vendor allows you to expand the solution quickly to the new market segments and keep your focus on the core part of your product.

After all, if you see a lot of demand, you can replace the integration with your own solution.

Discover more content on Product management skills. Explore our Content A-Z to discover more product insights.