Why SaaS Product Integrations Aren't Like Normal Features

Most SaaS product teams treat product integrations just like any other feature in the backlog. And, while there are many similarities, integrations are fundamentally different in a few important ways.

In this post, we dive into what those similarities and differences are, emphasis on the latter.

How Product Teams Manage Features

SaaS product management is a dynamic and challenging domain. As a product manager, or as a team that builds a product, your job is to synthesize a lot of unstructured information to make the best possible decision about what to build next.

It's typically somewhat unclear what the right order to build features is. Likewise, you rarely get directly correlated feedback from the market about whether you made the right decision.

Product management is the discipline of navigating this challenge, which is an order of magnitude faster and higher impact in venture-backed SaaS businesses.

All product teams operate differently, but there are some general approaches that are shared by most. A basic product management process looks something like this:

1. Source potential features for the roadmap
2. Assign value to those features to establish a priority, which is regularly reviewed and reshuffled
3. Build and deploy features as the engineering team has capacity to do so
4. Measure adoption and collect feedback
5. Rinse and repeat

This is definitely a hand-waving abstraction of what a product management process will actually look like within a software team. But, it's a good enough framework to call out some important considerations.

Sourcing Features for the Roadmap

Product teams source ideas for the next product features from a lot of places. In fact, its in a product team's interest to have a diverse set of sources that include both direct and indirect feature requests.

Common sources for product features include:

• Formal requests via a customer "feature request" portal or informal requests made to the support or customer success teams
• Analysis of support tickets, bug backlogs, and other customer feedback on using your product
• Measuring activity, usage, and success metrics within your product
• Suggestions or direct requests from the business development team, sales, partnerships, and/or other market facing teams
• The CEO's or founders' vision

These product features come in all shapes and sizes. Some are simple UI updates, others are massive, new sets of functionality. Some are great ideas. Some are bad ideas. Some would work really well for one customer, but not many more.

The product team's job is to sort through those features, assessing which are viable and assigning value to them, so they can be prioritized.

Assigning Value to Features

You can't build everything, so it's important to set a priority. This ensures that what you do build has a high probability of positively affecting the business.

Value assignment is as much art as science, but consistency is important. Trying to measure value on a sliding scale makes it hard to make appropriate comparisons of the features you could build.

This post does a good job talking through some of the most common ways product managers and their product teams navigate deciding what you should build and when.

These exercises get you to a reasonably educated stack rank of features, allowing the engineering team to work down the list.

Building and Deploying Features

With a prioritized list of features, the engineering team (typically considered partner to if not part of the product team) will build features in the order they are prioritized based on their available capacity.

Today, most engineering teams execute using an Agile methodology, where they work in two week sprints, with the ability to reset and reprioritize after each sprint. They will estimate effort to deliver in "story points", which are an abstraction of effort. They'll also estimate their capacity based on how many story points they can usually deliver.

There's more to Agile and how an engineering team delivers features than this post will get into.

It's most important to understand that you will always (and should) have far more features in your backlog than the engineering team can deliver. Then, it's a collaborative effort to make sure you use that limited capacity to deliver the most possible value.

Measure Adoption & Collect Feedback

Once features are in the wild and (ideally) users have begun to adopt them, it's important to complete the loop by collecting feedback and measuring how/if users are adopting those features.

How people are or aren't using current features is a huge source of "next" features. Users will often provide direct feedback about what's working, what's not, and what they want. It's only one source of info, but it is an important one.

Users also provide indirect feedback that you can solicit by measuring or observing what users do and don't do. Do they click on that new button? Why?

This feedback loop makes your product better, and it makes your team better at delivering product.

Why Integrations Are The Same

In many ways, product integrations are no different than any other product feature. Thus, many of the same principles applied to standard SaaS product management should be rightfully applied to integrations.

Consider the following ways integrations are much like normal product features.

First and maybe obviously, product features represent value for a user. It's something that makes their life easier, better, more efficient, or whatever. That may be in a small way. It may be in a fundamental way, but that value must be present. Integrations are no different in this regard.

You will have many sources for potential integrations, including direct requests from customers or potential customers. You'll also use market information, analytics about your own users, and other external sources of information to include integrations that customers haven't directly asked for.

In this way, the challenge of knowing what integrations to build in what order is very like other features.

Your engineering team has limited capacity, and if they are the team delivering integrations (along with other features), you necessarily have to size product integrations apples-to-apples with other features.

Likewise, your engineering team's capacity to deliver integrations can be extended by third party help.

Finally, you should be able to assess how valuable an integration is to your business, once in the market. You tend to see an 80-20 rule (maybe even 90-10) where 80% of integration users only use 20% of the integrations. That means there are many integrations that go underutilized and probably haven't paid back the investment that went into them.

Measuring these inefficiencies will help you make better integration priority decisions in the future, just as you would a typical feature.

But, talking about why integrations are like normal product features isn't that compelling or interesting. Let's get into why integrations are different, and why that's important.

Why Integrations Are Different

Despite all the ways product integrations are like any other product feature, there are some ways they are fundamentally different. This is where the bodies are buried.

Understanding what makes product integrations particularly unique in the landscape of overall features will help you mitigate risk. It'll help you make sure that your integration program is a strategic value-add and not a burden.

Here are the main ways integrations are different:

• An integration is a feature that overlaps with another software company's functionality. You don't have full control of the outcome.
• Unlike most features, users don't really want integrations. They want the cross-product users experience that the integration enables.
• Users don't tend to understand integrations as intuitively as they understand other more standard product features.
• That's because integrations are like icebergs. You don't see the vast majority of what's going on.
• Finally, unlike most product features, integrations live outside your API.

Let's dive into each of these in more detail...

Shared Responsibility With A Tech Partner

One significant difference about integrations, compared to typical product features, is that delivering value to your user is a shared responsibility. When it comes to integration, you can't do alone, because the value is derived out of making your product work well with someone else's product.

This really changes the dynamic when it comes to understanding a user need and executing on product to satisfy it. Now it's a collaborative effort.

To build a useful integration requires a relationship with the other software product's team--the technology partner.

Sometimes your relationship with a technology partner will be at arm's length: they provide an API, reasonable documentation, and ideally a support channel, but you're otherwise going at it alone. Sometimes, the partnership will require coordinated software development schedules, new feature releases to support the cross-product user experience, and co-marketing effort.

This also means that integration features extend beyond the product/engineering teams who prioritize and build them. There's a role for the business development team, especially those who manage partners. There's also a different role for the customer success and support teams, who now have to understand where your product fits in context with someone else's.

The nature of every tech partnership is a little different, but the fact remains that building integrations means you have to place nice with others. And, that fact means you have to organize a little differently to be successful.

Users don't want integrations.

We say this all the time. Users don't want integrations.

This may sound counterintuitive, especially from a company built around providing integrations, but it's true. Users don't care about data flows or APIs or JSON or object models. They care about a cross-product user experience that helps them get their job done faster, easier, more effectively, or whatever their goal.

Users do say, "I want this to integrate to that," but they are not really asking for an integration.

Articulating a cross-product user experience that achieves a business goal isn't easy. It requires some creativity, especially if you are trying to describe one that doesn't exist. If you aren't experienced or comfortable doing this, you're not going to put a bunch of brainwaves forward figuring out how to.

And, why would, you? It isn't your job.

That's why users just say, "make X talk to Y". It's easier. It's your job to figure out what that means and to collaborate with the technology partner to build a cross-product experience that satisfies their actual need.

To some extent users never say what they really mean. But, this reality is accentuated when it comes to integrations. These are features that are hard to understand, that tend to be an order of magnitude more complicated, and that are under the hood and nerdy. Most of the time, a user will just give you the shorthand--certainly more than they will for other product features.

Integration is less intuitively understood.

We started to touch on this already, but integration features tend to be less intuitively understood by the end user. There are a few reasons for that:

1. Integrations have a heavy back-end component (more on that shortly).
2. Integrations represent the merging of two software products.
3. What the integration literally does and what that means to the user tend to be disarticulated.
4. Few people have direct experience building and working with integrations.

For most users, integrations are kind of an unknown. Most understand them at a fundamental level, but how they work, why they don't, what to do about failures, or how to build them is not in the average user's wheelhouse.

Nothing wrong with this! Most user's don't need or want to build or understand integrations, because they are simply a means to a different end.

However, that increases your responsibility as the SaaS provider to really drill into what your users need. You play a heavier burden in integration feature design than you would in most other product features.

That means, you must understand how to design and build highly effective integrations.

Integrations are like icebergs.

We've all heard the adage "just the tip of the iceberg" alluding to the fact that most of the iceberg is underwater and unseen. The same is very much true of integrations. (This is a huge contributor to why they are less intuitively understood.)

While there are certainly user interface, user facing aspects of an integration, the vast majority of the functionality is server-side, back-end work. It's an engine that moves data in high volumes.

That means understanding what it does and how it does it requires a higher level of technical architecture understanding. You probably can't easily explain to your average user why a microservices approach to integration is important to them (it is, by the way). You can't easily explain to them why you can't transform a data object in the way that they want it, because of limitations in the mapping language.

And, honestly, your user doesn't care.

Users tend to understand what they can see, and for an integration that might be as minimal as an on-off switch. That makes aligning user needs and expectations with an integration feature that is almost alll back-end functionality is a little harder than with your average product feature.

Integration lives outside your API.

If you're a software architect, forgive the simplifcation here, but generally speaking most product features live "inside" the product and not "outside" the API.

Think about an API as the doorway through which data can pass in and out. It makes the internal functions of your product accessible to other consumers (usually other software products). When you build typical product features, they are built inside your house, so to speak.

Integration is a little different. An integration typically reads from and writes to your API to pass data to/from other APIs. While, from a user experience perspective, this may all show up in the same UI, the underlying functions exist outside of your API.

Note: If you custom build product integrations, this may not actually be true. We consider this an anti-pattern that does not set you up for success over the long term.

This externalized nature of integrations as features makes it fundamentally different. It's a feature that is also a consumer of another feature, your API. It makes engineering team coordination a little more challenging.

What It All Means

Integration is a specialized engineering discipline that requires a specialized approach. While in many ways product integrations are similar to other features in your software product, there are some ways that make them very different.

Those differences are where integration adds risk to your businees. They are the reason you should have a proper technology and execution strategy, specifically for integration.

Keep following this blog to learn how to do that. And, of course, we're always happy to chat!

‍