Creating Cross-Product Experiences: A Hierarchy of Needs

Nobody actually wants software integration.

That might sound like a self-destructive statement coming from a group of people who are dedicated to helping software companies with integration, but it's true. The word "integration" is a shorthand term describing something else a stakeholder really wants.

As a software company, your key stakeholder is typically your user. You will prioritize and invest in integrations for them. They will say the words, "We need an integration to <insert other software here>." But, they don't mean it.

What your user actually wants is a cross-product experience.

What is a Cross-product experience?

Your user doesn't primarily think in APIs or data flows or IFrames. They think in terms of workflows. They think in terms of jobs to be done to accomplish what they need to get that bonus, that promotion, that big sale, or whatever it is they seek.

[If they are thinking in APIs or data flows then a) they are an integration company or b) they've been forced to think in these terms, because they have no other option.]

There is no such thing as a user of only one software product that completes every aspect of their job. This is true despite the number of software vendors that claim they are the end-all-be-all platform for their users.

Users will float between tools throughout their day, often without even realizing it. They build rhythms of shuffling through browser tabs, mastering the copy-paste, and if all else fails, dumping everything into Excel for some VLOOKUP wizardry.

Each of your user's jobs to be done is potentially and probably a cross-product experience--to get the job done, they'll need to use multiple tools together.

When your user asks you for an integration, they are actually asking you to provide a more seamless cross-product experience.

Some examples:

• A direct-to-consumer eCommerce operations manager who needs all their orders to automatically flow into their warehouse management system so the warehouse can fulfill them ASAP
• A CFO who needs sales from a CRM to flow directly into the ERP, so that she can report on actual sales data without re-entering every quote from every sales rep
• A call center representative who needs to be able to pull up an on demand, 360-degree history of the customer, so he can quickly and easily inform himself of the customer's needs

In all of these cases, a single person performs a single job that includes multiple software systems. The more seamless this cross-product experience, the more effectively the person does the job.

Creating Cross-Product Experiences

Creating effective cross-product experiences is no easy task, but it can be massively differentiating and value-additive when accomplished.

You shouldn't eat the apple in one bite. Designing a fully-sophisticated cross-product experience is prohibitively difficult, because:

• Learning exactly what your user needs takes time, trial, and error
• Sophisticated cross-product experiences are a collaboration across two software companies, and it takes time to build that kind of partnership
• Building cross-product relationships takes a lot of effort and money

There's also a lot of value to be added (and money to be made) along the way, by taking a gradual approach to your cross-product experiences. Starting small gets small amounts of value out to your user sooner. This begets more learning about your user, which results in giving them more value, and so on.

But, you don't want to go at this gradual approach without a framework for where to start and where to end!

The Cross-Product Experience Hierarchy of Needs

The following describes a hierarchy of needs that can be used as such a framework. It helps to guide what you need to do when as you mature a cross-product experience from a mere request to a fully sophisticated, value add user experience.

The hierarchy contains four layers. And, while you never stop investing in any of them, you are encouraged not to move up to the next layer without a sound foundation on the layer below. (Don't start wallpapering your second-floor bedroom if the first-floor walls aren't even up.)

The four layers, in order from bottom to top are:

• Data integration
• User interface integration
• Team & culture integration
• Brand integration

Workflow Integration

The first two layers of the hierarchy are about "workflow" integration. These are the tangible, technical deliverables that when assembled together affect the user's workflow directly. These end up literally being the things that the user clicks to accomplish their job.

Data Integration

Data integration is the most common, most discussed kind of cross-product experience--which is good because it's the foundation on which all cross-product experiences ultimately sit.

Data exists in system A. Different data exists in system B. For the user to get their job done, those two datasets must be aligned in some way, shape, or form. Usually that means data from one system must be synchronized into the other. Sometimes that needs to happen in both directions.

The demand for this type of cross-product experience is a big driver in the growth of API standards, technology, and design principles. It's also the fundamental demand engine for solution integrators, integration platform-as-a-service (iPaaS) vendors, and the like.

Data integration saves clicks. It saves data entry errors. It saves copy-pasting. It saves monotonous, mistake-prone work. It also affords opportunities for more thorough data analysis, more accurate reporting, and ultimately better business decision-making.

Data integration is far from the end-all-be-all of cross-product experiences, but it gets the majority of the attention.

Data Integration Example

We use Hubspot for a CRM, Zoom for online meetings and presentations, Calendly for scheduling, and Google Calendar for (duh) calendar. This is a very common combination of tools for very common workflow.

Those four products pass data between them to create a seamless cross-product experience. The flow of data goes something like this:

1. Someone clicks a Calendly link to schedule time with a user with a Blended Edge team member.
2. That person sees exactly which slots are open, because Calendly pulled the available team from the B.E. team member's Google calendar.
3. The person selects a time.
4. Calendly calls out to Zoom to create a meeting.
5. Calendly adds that event (with those Zoom details) to the B.E. team member's calendar.
6. Then that person is pushed into our Hubspot CRM as a new (or updated) contact to be categorized appropriately.

Each one of those steps, where data is passed from one system to another, replaces a set of manual clicks or copy-pastes that take a bunch of time and introduce opportunity for mistakes.

In this case, four products operate as one to satisfy the job of "scheduling a meeting".

User Interface Integration

User interface integrations go a step further by embedding a version of the UI from one product into another. These integrations are valuable for high-click users where efficiency and accuracy are important.

UI integrations can come in a variety of levels of sophistication.

Sometimes one product will build in a version of the other's UI to mimic the experience with a consistent brand experience. Sometimes product A will provide product B a UI framework so that B can integrate into A. Sometimes B will be embedded into A simply via an IFrame.

There are cost-benefit tradeoffs for all of these approaches, but they all result in one software product being visibly embedded within another.

User Interface Integration Example

Let's go with another example straight out of our workflows!

We use Docusign for execution of legal documents. We use Google Drive for enterprise content management, which is where all of our contracts and other legal documents are stored. (Nothing new here.)

Docusign's integration with Google Drive allows me to seamlessly send out documents for signature that are created and live in Google Drive. I can simply browse and select the document I want, then I'm in Docusign's step two: where do they sign?

The part of the experience, which involves browsing my Google Drive folders in search of the right document, occurs from within Docusign. There was no "other product" in my workflow. It appeared singular. Docusign embedded that Google Drive folder browsing experience into their application.

This is a very simple example, but think about the alternative experience.

I would have to open Google Drive in another browser tab. Go find the document in question. Click to export it as a .doc or .pdf. Go back to my Docusign tab to upload that doc. Browse for it on my computer, and upload.

This integration simplifies my workflow by creating a cross product experience between Docusign and Google Drive. It syncs data (in this case a  document) from Drive to Docusign, after I browsed my Google Drive folders from within Docusign.

Experience Integration

The second two layers of the hierarchy are about "experience" integration. They are where the cross-product experience actually expands beyond the two products that are integrated. This is where partnerships and technical integrations become the yin to the others yang.

(Partnerships have something of a hierarchy too, and it is relevant to this topic.)

Team & Culture Integration

Sometimes products integrate complex workflows that require implementation projects or heavy involvement form support and customer success teams. In these cases integrating the teams that work around two product, ultimately creating a unified culture, can take the inter-product experience to the next level.

The team for product A must be trained to understand and work with product B, and vice versa. Both teams know that success for their shared user relies in working together. The user doesn't care who works for which company. The user has a job to do, and both teams must collaborate to help them accomplish this job.

Integration is not just a technical concern--even though that's where most of the discussion starts and stops. When you start to integrate teams, you introduce training and process design challenges that traverse organizations. You also must begin to invest in the effort of creating a unified, shared culture that embodies that of both teams.

This is not always easy work and it requires a commitment from both partners. But, when done well, it can create really powerful experiences for the shared user that helps them solve complex problems

Team & Culture Integration Example

The Shopify ecosystem of integrations is typically via their "app" marketplace. If you are a software vendor and you want to integrate into Shopify, it usually makes sense to list your app.

Many of the common apps enhance Shopify's functionality, and because of this, Shopify cultivates the community of "app" developers.

Most of these app developers think and talk like Shopify people. Shopify builds a culture around their ecosystem. Many of these app developers (and their teams) are experts in Shopify, and often vice versa when it comes to Shopify's support and implementation experts.

There is no one app that represents this integration example, because Shopify has been able to scale this concept.

Brand Integration

A fully-realized cross-product experience achieves brand integration. This is where the two products (and companies) are presented to the world as one, often packaged and sold as one. This is where the lines are very blurry for the user--maximum seamlessness.

The word "brand" is kind of a marketing term, and it's important to acknowledge that this is something different than co-marketing. Sharing email lists and doing campaigns together is not true brand integration. It's simply co-marketing.

Brand integration is often a step away from M&A activity, but it's definitely possible (even common) that two products/companies remain fully integrated without ever crossing that line.

Brand integration creates exceptional cross-product experiences for the user, because they don't have to think about or feel the integration whatsoever. It just works.

Brand Integration

Let's stick with the Shopify ecosystem...

A large number of Shopify Plus (Shopify's enterprise offering) merchants use a product called Avalara AvaTax for managing sales tax when selling online. Avalara's products have long been considered one of if not the best in this category.

While Shopify and Avalara are two separate companies with two separate products, the Shopify Plus market almost experiences them as one. The Shopify team knows how to support Shopify merchants who use Avalara and vice versa. The integration is seamless and value-additive for both companies, and is basically built in to Shopify Plus. There's even documentation about AvaTax in Shopify's documentation.

Best of all, the synergy between Shopify Plus and AvaTax creates an exceptional experience for the merchant, who has a complex job to do making sure sales taxes are correctly collected on their orders.

Not all cross-product experiences are created equally.

Every cross-product experience is different, and every cross-product experience will not eventually get to a fully-realized "brand" integration. Cross-product experiences only need to be as sophisticated as is required to get the user's job done.

But, pay attention! What you (software vendor) think is getting the user's job done and what the user thinks may differ.

It's also not a straight line that is consistently applied to every case. While generally speaking, you shouldn't try to tackle UI integration before mastering data integration, these aren't hard rules. The extent to which each layer applies to a given case (including whether it does at all) is unique and should be considered as such.

This is merely a framework for how you should think about establishing and maturing cross-product experiences. It's not a recipe.

Creating effective cross-product experiences is an interdisciplinary journey that requires the product team's insight about the user, the engineering team's technical ability, the business development team's ability to build relationships, and support from the rest of the organization.

Software vendors who are able to align those disciplines to maximize the power of their integrations will create differentiated, exceptional experiences for their users. Those users will become fiercely loyal customers.