27 days until #mtpcon London, the world’s best product conference
Book now
Third-Party Software Integration: Best Practice, Perils and Pitfalls "Product people - Product managers, product designers, UX designers, UX researchers, Business analysts, developers, makers & entrepreneurs 12 April 2017 True Andre Piazza, Carol Sun, Christina Trampota, Competitive Advantage, Daniel Elizalde, Grace Hu-Morley, Janna Bastow, Jeremy Glassenberg, Mike Knoop, Product Management Best Practices, Product Roadmap, Product Roadmapping, Product Strategy, Software Integration, Strategic Partnerships, Third-Party Integrations, Zapier, Mind the Product Mind the Product Ltd 2857 Product Management 11.428
· 14 minute read

Third-Party Software Integration: Best Practice, Perils and Pitfalls


Product management teams often ask themselves if third-party integration is right for their software product roadmap. The thinking is that you should integrate with products such as Salesforce and Slack, because you never would want to try to build those sorts of products by yourselves.

Because of this, look through product management job descriptions and you’ll find many that mention third-party software integration, APIs, strategic partnerships, and so on. Senior/director integration positions are usually expected to own a product roadmap strategy. If they are not senior/director positions, then the product manager is usually tasked with the efficiency, quality, and speed to market of the integration.

Most product managers will at some point be tasked with a third-party integration; sometimes by choice and sometimes not. For this reason, I decided to talk to product managers with the most third-party software integration experience and set out to discover their best practices, both strategic and tactical. Some of these product managers are working for companies you’ve heard of, some are consultants, but all have valuable tips on doing integrations the right way.

Here is what the experts told me.


Janna Bastow

CEO & Co-founder, ProdPad

Connect on LinkedIn | @simplybastow

Q: How does the competitive landscape drive an integration strategy?

JB: As you get more into really competitive spaces (like if you’re building a CRM or marketing automation tool), you’ll find that people have the luxury of simply selecting or disqualifying products based on integration options alone. This raises the bar for entry for companies who are trying to enter crowded markets, as even today, building third-party integrations takes a concerted effort and tons of testing and fixing for edge cases.

But don’t just assume that because your competitor has an integration that you definitely have to as well. Treat it like building any new feature – find out whether your customers have a real need for it, and whether building it actually attracts the right sort of customers. No point in spending all your time bloating your product for no good reason.

Q: How has the team at ProdPad used its product roadmap to communicate integrations to customers and prospects?

JB: We’ve had a number of times we’ve done this – for example, when we were thinking about providing single sign-on (SSO) options within our app, we added an initiative around it on our roadmap.

We put it on the roadmap to see if anyone cared, sort of as a test to see if anyone would be interested before we actually started building anything. In line with good roadmapping practices, we kept it generic enough: we said SSO, not specifying exactly what providers or functionality would be supported, and we didn’t include any promises of dates that might have trapped us.

Sure enough, there was interest. Having it on our roadmap helped us gauge and compare interest in various SSO providers and prove that it was worth having. We received enough requests from customers that when we launched, we had a list of customers to ask for feedback and insights. We knew what they needed right off the bat. Plus, we had a bunch of people to go sell the upgrade to when it was available.

Q: At ProdPad, how do you manage a product that has a ton of integrations?

JB: Just because you’ve built for one integration, doesn’t mean it’ll be straightforward to build for the next. We integrate with a bunch of tools that are very similar in concept, though with different terminology: Trello has cards, Github has issues, JIRA has tickets. The integration requirements from the user are pretty similar – but the implementation requires careful planning around how each system works.  And because each API is handled by a different company, we’ve got to keep on top and make sure to fix our integration whenever the third-party provider changes their system.

We have to maintain a matrix chart to outline all of our integrations and functionality, so we can organise our list of known limitations or peculiarities with each provider, or else we’d never be able to keep on top of them. It’s best to outline these as you go. If your product supports multiple integrations, you’ll thank yourself for the good documentation down the line.


Mike Knoop

CPO, Zapier

mikeknoop.com | Connect on LinkedIn | @mikeknoop

Q: How should startups position integration planning to maximise growth and retention?

MK: Integrations retain users, nearly 50% better in fact. I always look at integration as a retention strategy versus a growth strategy, since that’s mostly how users value it.

Q: When your team (like Zapier) has a knack for efficient integration projects, when does it still make sense to build the functionality from scratch in-house?

MK: I usually suggest owning the top few use cases internally, since they have a maintenance overhead but it’s usually worth it. And outsource the rest.

Q: What sort of staffing model with product managers has yielded the most success for you?

MK: In my experience, the best integrations with Zapier have been led by a PM and an engineer together. If we only have contact with one or the other, balls get dropped.

Q: What are some complications to avoid in a third-party software integration arrangement?

MK: Revenue sharing and being charged for access. Almost never worth it.


Grace Hu-Morley

Director of Product Management, Prysm

Connect on LinkedIn | @gracehm

Q: What is the right situation for a product manager to consider a third-party integration?

GHM: Integrating a third-party product is necessary when the main added functionality solves a key market problem, is not part of your organisation’s distinctive competence, and reduces the development cycle time and costs significantly. Other key reasons to integrate include when the third-party product is considered a commodity and when the third-party organisation is a dominant player in their market/vertical.

Q: What advice can you offer about the other party’s motivation to complete an integration?

GHM: To move large integration efforts forward quickly, the third-party organisation must be as motivated as your company to integrate. There must be a similar sense of urgency by both sides. This can be created by mutual customers. If the third party is not compelled beyond the licensing revenues and agreement penalties, the integration project can easily stall or fail.

Q: What are some complications to avoid in a third-party software integration arrangement?

GHM: Complications that I have seen repeatedly arise with projects are when: 1) the roles and responsibilities are not well defined on one or both sides of the integration, 2) the third-party organisation says they “can provide” the functionality and what they really mean is they CAN BUILD the functionality which just adds cost and time to your schedule, and 3) accountability is not there when changes and decisions need to be made.

The key complication to avoid is the unbalanced relationship that I brought up earlier, which delays or even worse, stops the integration project from moving forward.


Christina Trampota

Managing Partner, CGM Squared

Connect on LinkedIn | @tektalk

Q: How should product managers evaluate products that could offer a third-party integration?

CT: The primary question should be if the third-party functionality represents a core part of your business or product value in your software/solution? If it does not, feel free to integrate with a third party. If it is closely related – ensure you have the correct partnership agreement in place to protect and promote both sides in the best manner, and don’t forget about IP!

Q: When should you opt to build from scratch instead of attempting an integration with another product?

CT: The “build” decision can occur after a variety of business options have been considered. It might happen if the “buy” option was not successful, or if integrating the two companies and tech environments simply don’t make economic sense. Or you might have made the decision that your business requires complete control over all of the experiences in your solution. This will enable your business to monetise and monitor the data, developments, and deliverables from end to end.

Q: What can product managers do to expedite the process of a software integration?

CT: Understand all of the integration points and dependencies ahead of time. Engage all of the required teams in advance for checkpoints before the development begins, hopefully avoiding or at least mitigating future concerns and/or delays. Also, identify a friendly client willing to test/try this with their environment or setting as an early adopter and one that will be open to sharing their story of success in a public case study or press release.


Andre Piazza

Senior Product Marketing Manager

Connect on LinkedIn | @apiazza

Q: What are the best reasons for a product management team to plan a third-party integration?

AP: Average Product Management will integrate capabilities for internal reasons, usually tied to:

  1. Revenue (upsell, cross-sell),
  2. Marketing (generally, competitive defensive or aggressive plays), or:
  3. Sales (driving parity in specific deals; create a sense of safety when commercialising specific products in certain segments or markets).

Great Product Management will help deliver these internal drivers, but map the entire workstream back to external reasons:

  1. Trends in the marketplace;
  2. Evolution in persona needs, pains, or gains;
  3. Trace the capability (sometimes even the partner) to pervasive, non-anecdotal feedback found in NPS / satisfaction surveys, win/loss analysis, or field visits;
  4. Develop propositions around user experience (UX), loyalty;
  5. Deepen a competitive sense to be reflected in thought leadership, analyst reports.

Q: What is a good way to set up internally for a successful integration project?

AP: When developing capabilities, the decision to partner (versus building in-house) is almost always a sensitive one. Often, it requires buy-in from a variety of cross-functional teams, and there’s always the risk of releasing confidential intellectual property. Also, the inherent risks related to developing the work are not only pushed into a third party – they are also championed by an organisation (usually the people that came up with the idea: engineering, development, or product management).

Advice here is to be thoughtful and thorough in selecting the incremental capabilities to build and the partners to work with. Select a cross-functional team that will get any partner across the finish line, and select and develop elements in the organisation culture that will allow for learning from failure.


Jeremy Glassenberg

Platform Strategy Consultant

Connect on LinkedIn | @jglassenberg

Q: What are some strategic questions to ask when you’re considering building from scratch versus integrating with an existing product?

JG: Overall, think about whether this feature is something you want to maintain long-term:

  1. Do many customers ask for it?
  2. Will you be able to build it once and have it work for many customers?
  3. Does this feature fit as a core competency? Either way, do you know someone else who can build it better? Or, who has a brand (don’t build your own CRM when customers know Salesforce)?
  4. If the partner can build it, will your product roadmap have more bandwidth?

Q: What are some tactical best practices for a third-party software integration arrangement?

JG: I have managed thousands of integrations, but some top recommendations:

  1. Know the personality of your partner. I have seen projects with large partners succeed, large partners fail, small companies succeed, and small companies fail. It all came down to the partner’s style and ability to execute.
  2. Have a clear statement of work. You don’t want the partner claiming that you agreed to build something you wouldn’t want to build, or the partner failing to build the integration as planned.
  3. Treat this like a product challenge. Don’t lose focus of the problem, and make sure the integration is a solution to a real problem.
  4. Integrations can be very challenging on a technical level, but they can also be challenging from a usability standpoint. Your service may fundamentally work differently from your partner in important ways. For instance, conflicting user roles and permissions commonly arise. You need to keep a watch on usability as you encounter unexpected technical hurdles.
  5. When something won’t seem to work, find other ways to make it work. Most integrations I have designed required adjustments as we learned more about the partner’s actual offering. I once had to come up with 11 different designs to find something that worked between two services.


Daniel Elizalde

Founder, TechProductManagement

Connect on LinkedIn | @delizalde

Q: When is an idea best built from scratch by your own product team, versus attempting an integration with another product?

DE: Product teams should focus on building differentiated components that are well aligned with the core vision and competencies of their company. The key is: not because you CAN build it, means you SHOULD build it. Engineering teams are often inclined to build new technology because it is interesting or “would be easy to do”.

For example, if you need to add a chat function to your product, should you build it yourself or should you just integrate one of the very robust products out there? If you are not in the business of building chat programs, there will be very little gain in you building your own. You will spend months of engineering and design time and will end up with a solution that is probably not as good as what other companies provide as part of their core offering.

Also remember that nothing “just takes a couple of lines of code.” Everything you build in house will need testing, documentation, support, maintenance, etc. All that cost is something you could have put towards building differentiated value.

Q: Do you have any advice on planning a third-party software integration to be successful for the long haul?

DE: When planning a third-party integration, make sure you consider the whole product lifecycle and not just the technical implementation. Spend time understanding how it will be used and the experience you want to provide to your users. Will your users know it’s a third-party product or will it’ll be completely transparent to them? How will users enable or install the integration? What happens if the third-party service is down?

Also, consider the relationship you want to build with the third-party provider. Answering “what’s in it for them?” is something beyond the technical implementation that PMs need to tackle as well. Work closely with your business development team to define the type of partnership you want, what are the terms, responsibilities, marketing opportunities, and who owns the customer. Finalising all these factors is often more challenging than the actual technical implementation itself. So, make sure you plan for all these before committing to anything in your roadmap.


Carol Sun

Software Product Manager

Connect on LinkedIn

Q: How did you become an expert on third-party integration?

CS: My company started off building product features from scratch. One day, the exec team decided to not invest any more and wanted to work with third parties instead. My job became the integration warrior (not by choice).

Q: What can product managers do to ensure the quality of a third-party integration?

CS: The most challenging part of third-party software integration is the lack of testing. Testing is broken down to four categories – acceptance, systems, integration, and unit. It is very important for the PMs who work on this to map out testing phases along with integration phases so that collectively, reaching the desired outcome/goal/usability of the product will not be a sloppy job.

When there’s lack of testing from the gate, it creates more work and frustration for the teams on both sides. Remember, third-party providers do not belong to your organisation and there will be a limit to their willingness to help out. Additionally, there is the partnership agreement. If possible, include some type of test/quality accountability agreement package.

Another important item (if budget allows) is to include testing with an independent testing company at the integration testing level, so that the third party and the organisation are presented with independent data.

Wrapping up

Having gone through the process of asking these experts about their thoughts on third-party software integration, I’ve noticed a couple of common themes.

First, product managers determine when it is right to integrate. The consensus is that you integrate when the feature is not part of your product’s core competency, and you stand to gain market growth or user loyalty from doing it. Third-party integration is a chance for both parties to do what they do best. If you need something in your product that isn’t your core competency, you absolutely should try to integrate with a specialist. Hopefully, the specialist is as motivated as you are.

Secondly, the agreements between parties, and the staffing and support from both sides are important to ensure success and quality. There needs to be a genuine desire from both sides to nurture the partnership for the good of everyone involved, and it needs to be sustainable long-term.

Thank you to all the participants in this article, and I hope you’ll all consider sharing the post and connecting with the participants on Twitter and LinkedIn.


Comments 2

Here’s the items that jumped at me:

* “Integrations retain users”. Seems like a “well, duh” metric but it’s good to see anyway.
* Carol’s emphasis on testing. A 3rd party’s infrastructure quality is totally out of your control, so having a 24/7 API checker seems like a must-have. The same comment applies to API changes. You can’t test what you don’t know.

This is really good info. I’d give a limb (OK, I get to choose the limb) for a decent API buy/build/partner checklist. Something that I could tack onto a office wall.

Thanks for the feedback @brianpiercy:disqus! I agree, decent API checklist would be really helpful! I am thinking about creating one for general use. I will share it back on this thread and (hopefully – fingers crossed – eyes crossed) will make it to your office wall 🙂 Cheers!

Join the community

Sign up for free to share your thoughts

About the author

#mtpcon LONDON | 20 OCT 2023

Join world-class product experts for a jam-packed day of inspiring talks and interactive sessions

Book now