Enabling Cross-Product User Experiences
Building integrations for your SaaS product isn't really about API integration. It's about enabling cross-product experiences for your users.
Join the DZone community and get the full member experience.Join For Free
If you are part of the product team for a SaaS company, you probably hear the word "integration" a lot--probably far more than you want to.
That's because SaaS integration is important, especially if your users are business users.
Users want integrations. They need them. They demand them! If you can't provide a certain integration that your users want, you can expect your competitor to offer it in short order.
But, there's a paradox with what your users have been demanding of you. Even though they may request an integration--even when they say the words "I need an integration,"--your users don't actually want integration.
The User's Mindset
Put yourself in your user's shoes, specifically as they are starting to evaluate software products for a given set of problems they have. (This is where you already spend a lot of sales and marketing dollars.)
The user's mindset is self-centered. I don't mean that derogatorily; just realistically. The user has a job they need to do. They have a problem or set of problems preventing them from doing that job as well as they'd like. They seek software products that eliminates those problems, so they can do their job better.
Doing their job better means more success at work, accomplishment, praise, pay increases, promotions, and hopefully the financial means to improve their lives overall. It sounds esoteric, but it's important to understand the underlying momentum behind your user's decisions.
We are all these users. We all go through cycles of this mental math.
The rub is that the average business person is a user of at least 8 different software applications. In other words, for someone to do their job, it takes them 8 or more different tools. By the way, "average" implies that roughly half of users require more than 8.
Those products are likely built by different teams and different companies. They have different UIs, different logins, are built with different levels of quality, and use different terms for the same things.
All of this is friction for your user while they do their job. These are all reasons that a user cannot do their job as well as they'd like to.
When your user says to you, "Can you integrate your product to X," they don't actually want an integration to X. They want you to make their job, which involves your product and Product X, more seamless.
They want a cross-product user experience.
Integration = Technology + Experience
Yes, software integration is a technical domain. It's a challenging one, and it requires years of doing it to get good at it.
Integration typically ends up an engineer's job. It's about APIs, web services, data transformations, authentication, handing data volumes, dealing with data exceptions, and the list goes on. These are engineering terms for engineering problems, but there are many ways to address those technical problems.
All of these are critical parts of understanding software integration, but they are insufficient on their own. Possessing the technology and the technology know-how to deal with APIs and data are table stakes. They are absolutely required to deliver integrations and they are absolutely incomplete.
SaaS product teams set themselves up for more successful outcomes when they recognize that 1) integrations are a critical part of empowering their users to do jobs that partially take place outside of their own product and 2) you must reliably deliver the integrations to your users to enable that to happen.
If you develop the artful skill of understanding the cross-product experiences your users seek--the ones that help them do their jobs better--you design and deliver powerful product integrations. You can solve problems for your user that have tentacles going into different software products created by different teams than your own.
To adopt this mindset, consider the following about how your currently deliver product integrations:
- Design integrations experience first, API second, integration technology last. Use cases should the guiding principles for any given integration project. The technology should be sufficient, but it isn't the solution itself.
- Build integration delivery teams with more than just engineers. You must include product- and user-focused team members who can contribute the non-engineering perspective.
- Articulate in marketing deliverables and measure success in adoption of integrations in terms of business value to users. Users don't care much about data counts or transactions volumes. Measure in what they measure. Talk about that.
- Take the tech out of integration--until you need to put it back on. Understand the different personas who use or interact with your product and/or team. Adjust your language and the context of your conversations accordingly. Yes, eventually translate that back to technology, where it ultimately gets implemented.
- Product integrations are for your users above all else. Resist the urge to treat integration as a box-checking activity that will satisfy investors or industry analysts or a CEO. Everyone knows when they are using a "going through the motions" integration. No one is happy about it.
Remember, your users don't want integrations, even when they say they do. Your users want you to enable cross-product experiences that help them do their jobs better.
If you deliver, it will make your users appreciate you more and stick around longer.
Opinions expressed by DZone contributors are their own.