In theory, Build versus Buy decisions should be straightforward: we compare off-the-shelf offerings with the time/cost/expertise to create them ourselves; we run the numbers; then we make an objective financial-technical decision before starting any work. In practice, these decisions sneak up on us after a lot of work has been done.

I often see development teams that have built some side technology that’s not core to their product’s mission, and which could (should!) be replaced by standard, fully available commercial products. But there’s usually resistance from developers when I suggest uprooting their internal work in favor of COTS – Commercial Off-The-Shelf Software – especially since commercial products are never an exact replacement for what the team has already implemented.

Let’s think through how this happens, the mental/emotional barriers to using commercial products in our own solutions, and ideas for how to “sell” the right answers to our developers.

How About An Example?

Imagine that we’re the world SaaS leader in llama/alpaca farm management applications. Modules include animal health records, breeding strategies, wool grading tutorials, and real-time animal locating via GPS/drone. As with any product suite, some parts have grown organically.

Along the way, we’ve built out some functionality that smells vaguely like pieces of commercial products:

1. We need to invite selected customers (llama ranchers) to participate in beta releases, surveys, customer advisory boards, and regional llama-fests. Initially, we knocked together a very simple email list, then created some unique categories (“Llamas | Alpacas | Both”) and tied it to our Tech Support system to get address updates. The interface is from 2002 and only a handful of our employees can operate it, but it contains dozens of pre-written email templates.
2. It’s hard to communicate with llamas (you have to listen very closely!), so we created a fabulous series of training videos. Access to videos is tied to our accounting system (via in-house APIs) so that we can charge for training and track activity.
3. Our smaller customers find standard SaaS financial accounting packages threatening and hard to use.  So we get lots of requests from part-time/amateur alpaca farmers for a stripped-down cost tracking application…

And so it goes. Notice that (1) sounds suspiciously like a small subset of Campaign Monitor, MailChimp, Constant Contact, SendGrid, or a dozen other campaign management systems.  (2) is a tiny sliver of what learning management systems such as SuccessFactors, Saba, Cornerstone, Bridge or SchoolKeep provide to their various market segments.  And (3) leads us into deeply complex accounting apps with scores of competitors and tons of legal/regulatory requirements.  Maybe we should be focusing our very scarce development cycles on llama-specific improvements.

How Did We Get Here?

We didn’t set out to develop our own fraction of a campaign management system. In fact, we didn’t think at all about outside solutions at the time: this was just a quick-and-dirty way of notifying customers about upcoming releases. It’s grown over time and become a burden: accepting unsubscribes, handling duplicates, the need for our content to look good on browser-based email, sidestepping corporate s**m filters…

What looked like a weekend exercise (“how hard could it be?”) has grown into an ongoing engineering investment. Two of our developers each spend 25% of their time doing CPR on this beast. It frequently breaks at inopportune moments, and there’s a stack of obvious improvements that we will never get to.

Our young product manager has estimated internal email development costs at $80,000/year vs. $29/month for Campaign Monitor. More importantly, she has a backlog of unique llama-farmer-friendly features that might deliver $500k/year or more if we could free up engineering cycles to build them. This should be an obvious choice, but she asked our developers to look at a few commercial campaign packages and didn’t get much enthusiasm back.

What’s Going On?

Every developer knows that replacing back-end infrastructure is messy and unpleasant and full of surprises. But deciding to replace some homegrown technology has some additional psychological challenges:

• We’ve been investing in this for a long time, and are emotionally committed to the good work we’ve done. No one wants to admit to wasted effort. (See sunk costs.) And we keep thinking about this as a short-term investment – even after a decade of tinkering. Doing the financial math is upsetting.
• We compare our imagined future version with currently shipping third party products. When faced with SendGrid’s long list of features, we pick a few that will be “easy to get done in the next release.”
• We identify our special need as a first-order requirement. (“They only have yes/no fields, but we need a three-way flag to capture Llamas|Alpacas|Both.”)  It’s certain that a call with the vendor’s presales implementation team would give us several ways of meeting our actual need, since hundreds of thousands of other users have put their solution into production.

Most to the point, it’s a lot of work to compare products: figure out criteria, get test accounts, create fake data, read the “get started” guide, sort through APIs. Our developers signed on to write terrific software, not to do vendor evaluations.  Asking them to manage this as a side project probably means it doesn’t get done.  Replacing home-grown code with a supported commercial product is a big enough opportunity, so our product manager will have to herd everyone through the process:  asking the team about criteria and gotchas; getting buy-in for the decision process; scheduling vendor calls; selling the goodness of our final pick.  She has to provide just enough lightweight process to get this done without trampling on the team’s expertise and preconceptions.

She might reach for some of these motivational tools:

• “Sell” the strategic work we’ll get to do instead – that will drive customer happiness and incremental revenue. Development teams want to work on what matters – what’s visible and important to real customers. (“Our alpaca farmers are worried about a possible crossover of the H7N9 avian flu, and a real-time CDC link to our health records application could save thousands of animals’ lives. This is important and time-critical. Replacing our email back-end process will free us up to be heroes.”)
• Talk about how deep the feature hole really is.  We don’t want to have to build two-step opt-in workflows, mobile browser test suites, email cloud failover strategies, I18N language options… but our customer-email-related backlog is huge.  (Yuge!) Commercial products have dozens/hundreds of developers working on campaign management issues that we haven’t even thought about: email is their strategic application.  Let’s spend our precious time building value-add that our llama and alpacas ranchers will love.
• Celebrate the tons of  free features we get. Restating the above in a positive way, we get the ongoing stream of improvements that our vendor is building for thousands of existing customers.  (“Look: they have reporting APIs and opened-email statistics. Marketing has been asking if anyone reads our stuff, and we don’t have to build anything to give them answers.”)  In other words, we’ll get 50x the features plus support at 1/2000th of the cost.
• Let vendors share their expertise. Rather than having to outthink our developers, our product manager sets up calls with a few vendors’ support teams. She gets the team to ask lots of questions about how the vendors would solve our implementation problems. Our technologists strike an emotional chord with their technologists – and suddenly see that a packaged solution might be possible.

This is classic product management: correctly framing a problem with possible solutions; corralling and motivating smart folks who don’t report to us; focusing on the end goal; getting the group to find a good resolution. Leaving our egos at the door. Listening to the quiet voices in the room.  We need to understand why our teams act the way they do –and become good students of organizational behavior – instead of getting frustrated by a lack of participation.

Sound Byte

Build versus buy seems like it should be a simple spreadsheet exercise. But perceptive managers recognize the emotions, assumptions and biases that are involved – and plan accordingly.  We don’t have direct authority, so substitute motivation and mission.