When building a new product integration, especially to an external system that you have limited or no experience with, consider involving customers in the process.
Customers usually know their needs better than anyone else. They can be valuable experts in the systems you need to integrate to. They can help to make sure you build the right integrations and that you build them right.
Involving customers is not without risk though, so in this post we'll discuss why you should involve customers when building product integrations and how to do it effectively.
There are some distinct advantages to building a new product integration along with help from actual customers. These reasons are similar to why you'd generally want to build any product feature with input from customers, but we'll highlight what is uniquely beneficial about involving customers in building an integration.
Reasons to involve customers include:
The goal for your product integration project should be to create a cross-product experience that provides value to your customers. The experience is cross-product, because you jointly provide that value with the to-be-integrated system.
Providing a product integration is a recognition that your product doesn't solve every one of a customer's problems on its own. (No software does, by the way.) It's a technical bridge, so that your product + the connected product can provide a more comprehensive solution for your mutual customers.
Like any feature you might add to your product, that solution has to be defined in order for the integration team to build it.
Requirements definition is an art as much as a science, and most product managers will tell you that it's challenging enough creating effective requirements for typical product features. But, when you are trying to create an experience that traverses two products, one of which is not yours, the challenge is amplified.
How much do you actually know about the other system? You might have some people on your team with experience with it. You might be able to hire for the experience or find a consultant. But, while helpful occasionally, none of these are effective ways to scale an integration program.
Worst yet, if you get it wrong, you might make some really bad design choices that nullify the integration altogether.
Your integration team can't know everything about every system. It has to build a discipline of using common patterns and general business domain expertise to learn a new system on the fly--at least to a point where a proper integration can be specified. It also has to do this at the risk of getting it wrong.
However, involving actual customers in this process can significantly reduce this burden!
If you involve customers who already have experience in the product to which you're integrating, they can be your proxy for expertise. They have a built-in incentive to help, because the extent to which you get the integration right is to their benefit. Ideally those customers also have existing expertise in your product too, but that's somewhat less important.
Customers can help you shape the definition of the cross-product experience. They add real-world narrative to "an integration to X" and help your team understand what they are truly trying to accomplish. Customers are uniquely positioned to do this for integrations, which are like features that leave your four walls.
You can't take a "Field of Dreams" approach to building integrations and expect to be successful--at least, not most of the time. If you build it, it's not necessarilly automatic that customers will come.
When assessing the impact and the ROI of the time and dollars put into an integration, customer adoption numbers are a key part of the calculation. An integration that attracts no users was not time/dollars well spent. Even if it's not your most widely used, your integration must be adopted to some extent to be deemed a success.
If you've enlisted a panel of actual customers to help you build a new product integration, you've also got your early adopters already built in to the arrangement.
Typically the customers who are willing to work with you to build an integration are those who need it the most--so much so that they'll take time out of their days to help you give them what they want. In most cases, these customers will be first in line to try out that new integration, once it's pushed out to the world.
Likewise, these customers are also probablly willing to take on a little bit of risk, volunteering to be the "beta" users for an integration. If you have this opportunity to exercise a new integration with actual customers and their actual data, it's a great way to validate that you built the right thing (and built it well).
Certainly, having customers involved in developing the overall requirements for the integration is valuable. There's also a more specific way customer involvement helps.
Actual customers are equipped to help you design their user experience with the integration. You could argue that user experience design is a subset of the overall requirements, but it's worth discussing as a distinct concern.
Integrations are hard enough for the highly technical product engineers who typically build them. Your customers are probably business users--maybe even consumers--who are far less comfortable with configuring and interacting with an integration.
As part of designing an integration that delivers a valuable cross-product experience, you must also consider how that customer is going to set up the integration to their liking. Is it a simple on/off button? Is there optionality? Maybe it can be really configurable for each customer? All of these are possible correct answers.
The only people who can tell you how well they understand how to set up the integration are the people who will be responsible for setting up the integration. Having this input in the early stages of designing that integration can help you ensure that you provide the right amount of configurability and in a way the customer can understand.
User experience doesn't stop once the integration is configured and turned on. At this point the user experience transitions into more of a "maintenance mode" where any of the following might be required:
All of these are important parts of a user's (your customer's) experience with the integration. Involving customers in designing for these issues early and often will make sure you build something that fully supports those customers' needs.
Your plan for building a new product integration should vary based on the number of customers who have volunteered to be your guinnea pigs. But, how many customers should you involve?
That answer may be somewhat out of your control. If you only have one customer willing to work with you, well, then your choice is one or zero. Assuming you do have the ability to decide how large your customer advisory group for a given integration is, consider how your approach should change with that number.
Note: None of these are a perfect answer for every software team, so decide what you think is right for your team. Then iterate with experience.
Sometimes you just don't have a customer available to help you build an integration. This is quite a common scenario, because you're often building a new integration to enter a new market. If you haven't entered it yet, you probably don't have customers, yet. You may not have any potential new customers, yet, either.
Building any product feature without customer input adds risk that you build the wrong thing. This is what has inspired many software teams to adopt the concept of the "minimum viable product" or the "MVP".
The definition varies and the way people use the term varies even more, but briefly it means building no more than what you need to build in order to validate a hypothesis about your market/customer/technical approach/etc.
You can apply that same mentality to integrations. Buillding the minimum viable integration helps you balance the risk of building the wrong integration with the risk of not building any integration at all. It gets your foot in the door. It gives you the opportuniity to gather real customers, some of whom will hopefully assist with building to a more sophisticated integration.
Finding the "just right" amount that qualifies as "minimum" but still delivers enough value to move forward with the integration is not easy. You'll overdo it and underdo it a whole bunch.
Minimum viable integrations are a topic for an entire post, but the most important principle is to think in terms of building an MVP for the cross-product experience. Don't think in terms of the smallest thing you can build that moves data.
It's also common that you'll have the opportunity to build a new product integration along with (and usually for) customer #1. This can be a big advantage compared to having no customers, but you should understand what working with one customer means.
A customer willing to build an integration with you can be valuable in a few ways. For one, they are probably among the most excited to have the integration--enough so that they are willing to get their hands dirty--so you can create a reallly positive engagement. If you sell into the enterprise, you might also be able to use that customer engagement to partially or completely fund building the integration, which helps reduce ROI risk. Last, and simply, you have an external, paying stakeholder to help you get it right.
On the other hand, you need to watch out for some traps.
One customer does not necessarilly represent many customers. While their input is very useful and should be appreciated, they are still only one customer. Your team will need to be healthily skeptical of what that customer requests to avoid building something specialized to that customer. Your goal is to solve their problem while also producing an integration that can be used by many others.
In fact, you should be sure that you should build the integration at all. It can be tempting to say "yes" to a customer (or potential customer) when revenue is on the table. Sometimes teams convince themselves that "yes" also means there's a broader market opportunity when one doesn't exist. These chickens usually come home to roost.
Additionally, involving a single customer in a product integration project can set an improper tone about the extent to which you are willing build bespoke features for that (or any) customer. You see this more with single-customer invollvement than anything else.
If you produce a SaaS product, you want to be careful not to set an expectation that you'll customize for that customer more so than you would any other. You want to make sure the collaborative integration project is an exception and they don't have the right to invollve themselves in functional requirements for other parts of your product in the same way. It's a delicate balancing act that sometimes requires some artful customer management.
There's no universal universally correct answer, but independent of specifics, building an integration with two to four customers is the Goldilocks, "just right" number.
Building a committee of a few customers has a few distinct advantages, helping you to build the best possible integration.
The biggest drawback to using a few customers is simply that it's hard to reliably enlist multiple customers every time you want to build a new integration. Most software teams are only oppotunistically able to do this, if they are able to at all.
You probably won't snap your fingers and make this possible. Instead, think of this as a long term play with your integration team. Think about how you incorprate this desire into your overall customer management strategy. Invest in building a generally collaborative relationship with your most important and most prototypical customers. Give many times before you ask to get.
Those dividends paid out will pay off when you then try to incorporate those customers into your integration design process.
Depending on the size of your customer base and the nature of your relationship with customers, you may have the opportunity to enlist "more than a few" customers in the integration design process. This is more likely with B2B SaaS companies with lots of scale and B2C SaaS companies. (The former is more our focus for this post, though B2C SaaS companies can still use this advice.)
Certainly, the realities of involving five customers is very different than fifty customers; likewise it's different than 500 customers. However, around five is where the hands-on collaboration starts to become overwhleming. If taking a "more than committee" approach to involving customers in integration development is right for you, it's time to start considering a more automated, asynchronous model. The more customers you want to enlist, the more important this becomes.
Scale can be useful. 500 customers giving you feedback on how an integration should work gives you more statistically significant information to work from. (It's still quitepossible that four customers are four outliers.) The trick is being able to collect and synthesize that data, because you probably can't afford to have intimate engagements with all 500 of those customers.
Starting at around five and scaling up with voracity from there, consider how you'll automate and standaridize these conversations. If you can build that interaction right into the product experience, even better. Just don't feel like you have to involve many customers if you can't do it effectively. You can always pick a small number from the larger interested pool.
There are drawbacks to involving customers in the product integration process. You shouldn't think of these as reasons not to do it. Think of them as "gotchas" to watch for and manage through. Drawbacks to including customers include:
Customers are not always clear when they try to describe what they want. This especially true when they communicate their needs related to an integration, because integration is just hard to talk about.
This means customers may give your team too much information or too little.
Customers that are too chatty about their needs may overwhelm your team. There's likely good information in the brain dump they provide, but it's difficult for your team to parse the relevant information from the noise. That slows the processes and increases the risk of chasing requirements you shouldn't chase.
There may be a number of reasons a customer is too chatty about their needs from an integration. They may not know what's important, so they simply can't filter. They may also be taking the opportunity to vent their frustrations or difficulties that are only adjacently related to the integration. They may just be passionate about working with you, which is a great thing if you can manage their enthusiasm.
On the other hand, some customers aren't chatty enough. This can happen when customers react with silence to their inexperience articulating integration needs. It can also happen if they're just culturally not great communicators. This is also a manageable situation, but your team will need to learn to pull good information out, rather than filter good from irrelevant.
Your project managers are probably already struggling to stay above water. There's always more work to be done than there are people to do it. There are priority shifts, internal politics, and all the other things that make software projects hard. Integration projects are no different.
Now, add one or more external parties to the mix--companies that have their own motivations, ways of operating, cultures, and expertise. You've amplified the challenge your project managers have to deal with.
Involving customers in the integration creation process is part project management, part product management, part customer or account management, and part customer support. It's not likely that one person (or group) in your company covers all of those areas. Effectively involving customers is a group effort and it requires really good internal coordination.
If you have internal challenges that make this difficult, you should consider how they'll impact your ability to involve customers in integration projects. There may be justification to limit customer involvement until you resolve those internal challenges.
"The customer is always right," looks nice written on the office wall, but it simply isn't true. <Insert overused reference to Henry Ford and a "faster horse".> Integrations are complicated. Software is complicated! Put simply, many customers just aren't equipped to give you good advice about these topics.
Again, this doesn't mean you shut your customer out, nor certainly should you look down on them. It means you should profile your customer to understand how effectively they can provide input. Then weigh how you use that advice with that profile in mind.
If you sell into IT organizations in the enterprise, your customer is probably going to be able to articulate their needs about an integration reasonably well. If you sell to SMB shopkeepers, you'll find fewer who can talk integration with you. These are only examples and probably stereotypes.
The customer is right, until they aren't. Your team must master delineating when they are and aren't.
If you're now convinced that you should involve customers when building product integrations, here's some advice for working well with customers.
For your customers' and your sakes, you'll want to structure your engagement with your customer with a regular cadence of conversations. Open-ended, whenever-either-party-wants ways of organizing increase the risk that your customer gets burned out on helping or that your team gets too in the weeds with them.
Depending on how your team operates, something like once weekly checkins, perhaps even a few times a week, help to balance a constant flow of input and time limits on collaboration.
This also gives the customer(s) regular snapshots of progress. Demonstrating that you are able to use their advice productively and for their benefit increases their engagement.
Likewise, try to structure your conversations. Casual, open-ended conversations are sometimes useful, but agenda-based conversations with intended outcomes should be the majority of how you engage with your involved customers.
Learn to master customer interviews and other strategies for customer-led product management. Consider reading up on the Lean Startup movement as well, so you learn to do it in a way that respects the idea of the "MVP".
Again, this helps keep your customer active and enthusiastic, and it avoids overwhelming them. It also keeps your team on the rails.
Product integrations are well described using a modified version of the Pareto Principle, also known as the 80-20 rule.
80% of the requirements for a product integration are universal to its users. These are the easiest ones to understand. They are usually the most obvious, so they rarely require input from a customer to identify.
20% of the requirements are where the integration needs to vary from customer to customer. These are the configuration points. This is where you understand how different customizations, configurations, and versions of the other product will impact the integration. This is the hard part of the integration, and it's likely where you'll also spend 80% of your time building and 80% of your time supporting the integration.
Don't bother with much involvement (if any) from your customers when defining and building the 80%. The potential value of their involvement is too limited. Use your customers to resolve the 20%...the hard part. Look to them to help you understand the nuance of that 20% so you address it correctly.
The 20% is where an integration is likely to succeed or fail. If you are fortunate enough to have qualified customers helping you build the integration, the 20% should be your collective focus.
Building software and especially integrating that software is full of "inside baseball" language. We talk API throttling limits, data transformation, cloud computing environments, and authentication. We talk tech, but those technical particulars are probably of little concern to your customer.
Your customers focus is the job to be done, which underlies the cross-product experience you're trying to create. You'll have a more effective conversation with your customer disussing requirements in those terms first.
Not every conversation has to be lofty. You'll get into specifics about how fields map to one another, which data objects are necessary, and how to transform X to Y. But, if the conversation doesn't start with how all of those things impact the cross-product experience, the customer will struggle to connect the conversation to what's important for them.
It's your team's job to translate how the customer sees the world with what the internal engineering team requires to build the integration. Shield your customer from that as much as is possible.
Lastly, you may want to consider providing incentives for your customers' involvement in building an integration. It may even help to encourage more qualified customers to get involved.
You can certainly provide financial incentives. Those can include everything from credits on future invoices to Amazon gift cards. The customer is taking time out of their day to help you improve your product. The customer benefits too, but time is money. Reimbrusing them somewhat for their time might be justified, especially if the customer was very involved.
Non-monetary incentives are also a good idea, and sometimes they are even more valuable. Your customer, or specifically the people you work directly with, might get a lot of value out of helping you market the integration--presenting at conferences, providing content, etc. It may help them learn technical skills that they otherwise wouldn't have learned as well.
Finding ways to provide non-financial value to the people you work with only increases your engagement and builds the relationship (while you build the integration, of course).
Mastering the product integration process is not easy. It takes time. It takes failure. It takes a dedicated focus.
Good relationships with customers are a valuable asset in many ways. One is that you can leverage their understanding of their needs to build integrations that truly address those needs. While there are certainly risks to doing so, they are manageable.
Bottom line, your integration program should include some level of customer involvement. If you're not doing it yet, start now.