Is Integration Product Management for you? (Part 3 of 3)
What to expect as an integration Product Manager?
If you prefer listening to this article as a podcast episode:
I’d like to start by saying that I believe every good PM could also be a good integration PM.
You don’t need a Computer Science degree to manage product integrations.
In fact, this was one of my main motivations behind writing this article series. I wanted to display what it takes to deliver a successful product integration and reduce the stigma that PMs with non-technical backgrounds have in this area.
All PMs, regardless of their specialization (integrations, feature, growth, scale etc.) have to do the same overall types of activities.
Nonetheless, the degree to which those tasks are needed for success differ. So your personal experience managing integrations could vary greatly depending on what tasks you enjoy doing.
We’ll cover some of these differences for the rest of this article.
Integration product management is less…
Going from the problem to novel product solutions
Ideation is one of the most amazing and fun parts of a PM’s job.
Whether you’re starting from the customer problem (e.g. I need to pay my bills) or the business problem (e.g. increase conversion by 10%), finding a solution could be extremely fulfilling.
This is true even if there are many constraints and dependencies to pay attention to. Because there’s that moment in the process where you finally manage to break this multi-layered complex issue and realize the best feature/solution for it.
However, integrations have almost none of that!
Because, even if you’re doing a first-of-its-kind integration, the high-level product solution for it is usually obvious. So there’s generally less need for ideation, experimentation or user testing.
To exhibit this, let’s do a quick test! Without Googling them, think about each of these integrations and try to guess how they work:
- HubSpot + Salesforce
- Jira + Slack
- Gmail + SurveyMonkey
- Canva + Facebook
- Zoom + Calendly
- Dropbox + Monday.com
You probably have guessed how each of these integration works even if you haven’t used or heard of them before.
Talking to users
Because the high-level solution for the integration is usually known, less user/customer discovery is needed.
That being said, technical and partnership discovery are still needed. As mentioned in parts 1 and 2, technical research takes much of your bandwidth during the discovery phase.
In a sense, the most significant risks in integrations are feasibility and viability risks. Whereas, in product features, it’s more common for value and usability risk.
Working on “design”
Integrations are full of edge cases (play #5), forcing you to account for many different UX flows.
However, because most of the integration functionality lies in the backend, there’s usually little to build on UI.
Agile
There’s usually a meaningful upfront cost for setting up the foundation (infrastructure, auth flow, pull/push logic etc.) in integration projects.
This will make it harder to deliver integration projects in slices and add incremental value over shorter periods.
Integration product management is more…
Thinking in extra layers of complexity
Unlike features, in integrations, you need to think about your user’s experience beyond just your product. Because you are adding features that change their behaviour in another system.
You will be spending most of your time on the sync/integration between the two products. While you need to constantly think about the indirect effects of each piece of work on the user’s experience.
Managing more types of stakeholders
On top of your internal stakeholders, in integration projects, you manage and influence your partner (more in play #13).
As an integration PM, you need to obsess over frequent and accurate communication.
Diving into technical details
As mentioned in part 1, to effectively make the tradeoffs in integration projects, you need to dive into technical details.
Operations heavy
Integrations can unleash a tremendous amount of user value in your product and make your product much stickier. However, they also involve many more moving pieces, dependencies and types of stakeholders. Therefore longer, more concise project plans are required.
In summary
Feature and growth PMs are like scientists or artists since their work is a lot more iterative, hypothesis-driven and creative.
On the contrary, integration PMs are more similar to engineers because they deal with more tactical and technical tasks.
This article is part of a series on integrations. Please consider reading other parts as well:
