post

Footer About

Footer Contribute

Footer Get Involved

Footer Links

Mind the Product

Guest Post

How to build a companion product and win user trust

mission statement

Deep dive: Crafting your product vision and mission

B2B product management

Artificial Intelligence (AI) & Machine Learning (ML)

Building Product Teams

Business Strategy

Data Driven Product Management

Digital Transformation

Diversity and Inclusion

Minimum Viable Product

OKRs

Prioritisation

Product Design

Product Research

Product Development Process

Product Ethics

Product Discovery

Product Leadership

Product Management Career

Product Strategy

Stakeholder Management

🌎 <a href="https://www.mindtheproduct.com/world-product-day/" style="color:#FFFFFF;text-decoration:underline;">Happy World Product Day!</a> Be sure to celebrate product, yourself, and your peers today! 🎉

Join us at #mtpcon London in 2025 – mark your calendars

How Google makes AI work at Enterprise scale – Miku Jha (Director, AI/ML and Generative AI, Google Cloud)

5 ways to invent and simplify as an AI/ML product manager

Why teams often struggle with OKRs: A conversation with Jeff Gothelf

Building your own user experience and software stack: This week’s product news

Ryan is the cofounder and CEO of Blended Edge, a software company that helps SaaS product teams deliver more integrations, faster. He’s formerly the COO and head of product for an eCommerce integration company and a solution consultant for enterprise marketing tech. He’s on Twitter at @ryanlunka and LinkedIn at ryanlunka.

Ryan Lunka

The most successful product managers in this fragmented, SaaSified world will be the ones who understand how to define <a href="https://www.blendededge.com/blog/creating-cross-product-experiences">cross-product user experiences</a> and to deliver the integrations that implement those experiences.
Here are some ways you can effectively incorporate this into your product strategy.
The product manager’s job is to refine actual problems for actual users into software requirements that, when turned into software, solves those problems.
Adoption of SaaS products has exploded as business users look to “build their own tech stacks” instead of investing in huge platforms that claim to solve all of their problems.
That means if you’re a product manager who is building one of those products, your scope of problems to be solved now stretches beyond the bounds of your product.
<h2>Define product experiences as user stories</h2>
Most product managers articulate what a product needs to do through user or job stories. This format is great for managing what gets done when. However, most product managers only focus internally on these user stories—what needs to happen within the product.
Your product doesn’t live in a vacuum. Your user adopts your product to solve a problem that exists within a broader context of problems. You might be a huge piece of the puzzle. You might be a small piece. However, you are not the only piece.
To create a more effective product for your user, product managers should understand where users fit in the broader problem context. What is your role in your user’s big picture?
After understanding this, you can inject user stories into your backlog that define cross-product experiences. Doing so will help you assess value to your customer, prioritize, and execute right within the same process you use for building product features.
Here’s an example of what this could look like for a product manager for a CRM product:
As a salesperson, I want to automatically create quotes in our accounting system, so I don’t have to manually enter the same information a second time into a system I’m less comfortable with.
This is not a user story that can be solely implemented within the CRM. It’s a user experience that crosses into another product (the accounting system). Defining it with the same user story format you define internal features allows you to compare apples to apples when deciding what your team delivers next.
<a href="https://www.mindtheproduct.com/you-are-not-your-user/" target="_blank" rel="noopener">Read You are not your user </a>
<h2>Treat integration as a capability</h2>
There is no such thing as a successful software product that doesn’t exchange data with other software products. Integration is inevitable and absolutely necessary. Given this, you have two choices:
<ul>
<li>React to it as it comes</li>
<li>Build the muscle to get good at it</li>
</ul>
(Hint: Just reacting to integration needs is not an effective strategy.)
In the same way your team should develop and probably is developing capabilities for things like DevOps, content marketing, and customer service, you should be thinking about how your team develops as well as integration capability.
But, what exactly does that mean?
An integration capability will look different to everyone, but generally speaking, you should consider the following:
<ul>
<li>What is your portfolio of approaches for providing integration, both internal and external?</li>
<li>How are we accomplishing the internally handled integrations? Are we building from scratch or <a href="https://www.blendededge.com/product">adopting a toolset</a> to help? Who will help us with the ones we want to handle externally?</li>
<li>Who’s in charge of deciding what integrations to build? Who prioritizes them? How does that priority jibe with the rest of our product roadmap?</li>
<li>Who will have executive ownership of integration? Is this an engineering function, a product function, or something else?</li>
<li>What parts of the organization does this touch? Where do sales, partnerships, customer support, or marketing play roles in our integration approach?</li>
</ul>
Integration is not simply a matter of saying, “Okay, we’ll pass some data to that API for you.” To deliver and maintain connectivity with other products (and do it at scale), you should start developing a capability early. The longer you let your integration approach simply happen, the harder it will be to get in order.
<a href="https://www.mindtheproduct.com/a-product-managers-approach-to-building-integrations-for-saas-software/" target="_blank" rel="noopener">Read A Product Manager’s Approach to Building Integrations for SaaS Software</a>
<h2>Prioritize integrations with intention</h2>
Many product teams struggle with understanding what value to assign a potential integration, a responsibility that usually falls on the product manager.
A really common way an integration gets built, especially early in the product’s life, is to simply react to a customer request. The conversation often goes like this:
Salesperson: “I can close this great deal if we just commit to having an integration to X!”
Product Manager: “Do you know if this is something we can use again or is this a one-off?”
CEO: “We definitely need this. Build it for them, and get the sale. We’ll reuse it.”
Inevitably the integration is built with too many things that are specific to that first customer. It creates an ongoing problem when that salesperson sells it the second, third, and fiftieth time. Or, worse yet, you’ve invested time and money into an integration, committed to maintaining it, and no one after that first customer ends up using it.
This scenario and ones like it are quite common and are generally avoidable. Had this hypothetical team gone into the conversation with a pre-existing understanding of how they prioritize various integration opportunities, it might have gone differently.
Here are some simple steps you can take to define that understanding.
<h3>Brainstorm</h3>
Brainstorm what all the possible integrations you might build can be. Remember, think in terms of cross-product experiences that might be valuable for your customer. This can be as simple as getting a cross-functional team in a room and throwing them onto a whiteboard.
<h3>Categorize</h3>
Categorize them relative to where you want to fit in your respective software ecosystem.
<ul>
<li>“Imperative” integrations are ones that your user expects you to have–not having it will prevent you from growing.</li>
<li>“Important” integrations are expected to have many users, but aren’t fundamental blockers for your success.</li>
<li>“Adjacent” integrations are the longer tail of integrations that might be valuable for your users, but wouldn’t really prevent success in absence.</li>
<li>“Agnostic” integrations are conceivable in thought, but not expected to be useful or requested often.</li>
</ul>
This doesn’t have to be perfect. Do your best to put them all in one of these buckets.
<h3>Assess</h3>
Use consistent and generally easy to find information to plot the relative impact to your organization and the relative difficulty in achieving the integration.
An easy, consistent way to define “impact” is with a basic ROI model. How many customers would the integration add and retain? What’s the revenue impact of that?
To define “difficulty”, look for things like the existence of a well-documented API, any known barriers to entry (like partner fees and approvals), and how custom-per-user the system is. Try to use the same criteria for each integration.
Place them in nine boxes on “Effort” and “Impact” axes, with “Low”, “Medium”, and “High”. Consider priority accordingly:
<ul>
<li>Low Effort, Any Impact (Obviously start high impact and work down.)</li>
<li>Medium-High Effort, High Impact</li>
<li>Medium-High Effort, Medium Impact</li>
</ul>
The danger zone is Medium-High Effort, but Low Impact. Those are to generally be avoided unless there’s a compelling reason otherwise.
Again, this is not perfect science — it’s for general comparison purposes. Don’t overthink it. Don’t overanalyze it. “Pretty good” is good enough.
<h3>Inform</h3>
What you’ve created is a list of integration opportunities that you’ve pre-assessed in terms of what they mean to your business. You’ve also done so without trying to boil the ocean, doing a deep dive into every possible integration you can imagine.
Now, when that salesperson comes to the product manager (and/or CEO) to ask about a potential integration, the conversation about whether to build the integration can be informed by this assessment. You may still decide to override the priority and build anyway, but you’re at least making an informed decision to do so.
This certainly assumes the requested integration is on your list already. If it’s not, this also gives you a fast way to have the conversation. Run it through the same framework.
<h2>The worst thing to do is nothing</h2>
These are strategies that we’ve found to be helpful for product managers who struggle to understand how or where integration fits into their roadmap. They may be right for you, they may not, or you may take them and make them your own somehow.
But, the worst thing you can do about integration is nothing.
If you are a software product manager, integration is inevitable. It is important. It is unavoidable. Your choice is to play whack-a-mole, reacting to integration requests on the fly, or to go into those conversations with intention and thought.
The former is likely to be a drag on your product’s growth, user-effectiveness, and ultimately your success as a product manager.
<a href="https://www.mindtheproduct.com/category/product-strategy/" target="_blank" rel="noopener">Discover more insights on Product Strategy. </a>

core/freeform

Common transformation pitfalls by Marty Cagan

Using principles to make better decisions faster by Martin Eriksson

How to build for creators by Peter Yang

How to navigate tricky work relationships

Organizing around complex products at the intersection of physical and digital by Matthew Cornford

Incorporating integration into your product strategy

Ryan Lunka

Read more

Comments