3 Principles to Achieve a Zen State Between Business and Engineering

Posted by Josh Weissburg on Dec 10, 2015


When a company is interested in Outbound, the first person I usually talk to is either a member of the growth team or the product team. Let’s call this person Alex. Alex typically knows exactly what the problem areas are in activating and retaining users, and he zeroes in on the experiments he wants to run. Alex sees the business case clearly, and he is impatient to get started.

Then Alex has to climb the engineering wall (see jagged rocks above).

It turns out that the hardest part of getting going with a new tool is not the actual work; it’s the painstaking process of finding a path that works for the business team (which is often focused on the benefits) and the technical team (which needs to protect against drawbacks and make the system work reliably).

If you’re in Alex’s position, I want to help you step back and understand the engineering perspective. Let’s call this person Whitney.

Once Whitney is comfortable, it’s just a matter of getting the work done. So what bothers Whitney most about integrating new tools? Here are the three objections I see over and over while helping our customers get started—and what the best business teams do to address them:

#1 Concern: Do I really get a say in this decision?

Since Outbound operates in the marketing automation / customer engagement space, I’ll start with the first and most important objection these tools face. Most of the time, marketing automation systems are sold top-down: managers decide it’s time to add new functionality, so they do a bunch of demos looking for the features they want, then pick a tool. Now Whitney is stuck with a big integration project that was more or less decided by the time she got a chance to weigh in, creating an adversarial dynamic.

The solution is to involve Whitney early in a small implementation that explores the functionality of the tool before a decision is made to invest a lot of time. This takes the discussion out of the theoretical; now both Alex and Whitney have the real world experience with the tool to draw on in their evaluation, and Whitney can actually test drive her concerns during this pilot phase.

#2 Concern: What will it take to maintain this integration?

If this process is all about Alex trying to convince Whitney, it’s going to be a tough road for Alex. So let’s back up a step: if a new tool requires a technical integration, there is probably engineering work to do regardless. The choice is between building and maintaining an in-house solution versus finding a tool that can replace this engineering work. The question is: how much work will the tool actually save Whitney?

The solution is for Alex and Whitney to explore the range of work that the tool could actually replace. For Alex: what are the different use cases that he could self-serve with the tool and how much time does Whitney spend helping him with these now? For Whitney: what is the ratio of inputs to outputs? For every hour of setup time she invests, how much payoff is there in addressing a range of current and future use cases? Now the integration work has become an investment, shifting workload away from Whitney.

#3 Concern: Does this tool scale?

Whitney is responsible for making sure that tools still work as the company grows. The tighter the integration with the product, the more scaling becomes important; as usage scales, the tool must keep up or the product experience suffers. Customer segmentation is a classic scaling problem: as Alex's customer base grows and his segmentation criteria become more complex, segments take longer to calculate, leading to an always out-of-date system that Whitney has to fix.

The solution is to identify where your business will exert the most stress on a system and select a tool that scales elegantly in those ways. For example, if Alex needs to send a lot of time-sensitive messages, then he should spell that use case out clearly so that Whitney can help select a system that updates the status on users quickly.


Be the zen master

The number of SaaS tools is growing faster now than ever before. That’s a good thing because business and engineering teams can get more functionality more quickly—but it also means that there’s a lot of potential for conflict about which tools are a good fit.

The next time your company discusses a new tool, watch to see the concerns above playing out. If you can address them early on, you’ll find that conflict is not inevitable. What a relief!

Topics: Best practices