When You Should Buy Technology and How to Do It

If you were to peer into the budget of this e-commerce leader, you’d find that over 60% of my spend goes to licensing third-party technology. Why? I firmly believe that for the majority of your web enhancement projects, it is better to buy than build. If a feature, enhancement, or capability is not unique to your business or experience goals, it’s usually more prudent to vet, purchase, and integrate an external technology.

Your time is precious. And if you’re a developer, there’s a real opportunity cost to how you allocate effort. More often than not, you can get more leverage out of a third party tool, while benefiting from the company’s experience, strategic service, and client community to scale the feature’s success beyond what you might be able to build and maintain internally. A recent report from Gartner underscores this and places enterprise software spend at an +8.8% increase for 2021, and a projected +10.2% increase in 2022, a strong reversal from a -2.4% decline in 2020 as organizations gear up for higher levels of digital transformation instigated by the pandemic.

Managers like myself that work on the commercial side should be a partner in sussing out the buy versus build decision, but we should never own it. Commercial leaders should over-index on ownership of the “what” and never the “how,” which is the purview of technical teams. So before you rush off to build out a solution, take a pause and consider the following. 

The Too Hard Pile, or When to Buy

Charlie Munger, the long-time investment partner of Warren Buffet, was known to have three piles on his desk: in, out, and “too hard.” The too hard pile was a simple designation of those investments that were just too complex to grasp or which Charlie didn’t have the inclination to learn. Of course, “too hard” is relative, but it’s important to know when you and your team should consider tapping out. Here are a few criteria to consider.

Availability

I have a self-prescribed rule of three. If there are three or more vendors that create technology relative to what you’re solving for, you owe it to your team and organization to talk with them. Under three vendors and you might find yourself in vaporware territory, where a technology’s application hasn’t been fully realized or proven. If you’re receiving a pitch, and the company can’t furnish clear developer documentation or a single client reference, end the conversation. There are dozens of ready-made solutions for experiences such as user referral systems or e-mail retargeting platforms. Don’t reinvent the wheel if you don’t have to.

Mission Adjacency

If a piece of technology is core to your business, it’s likely the case that you’ll want to own it. One way to think about this is how adjacent is the technology to your organization’s mission? For example: you operate a subscription, packaged goods e-commerce site that limits waste by reusing bottles, so you endeavor to build robust controls for users to manage their subscription and refills. If the technology isn’t core to your underlying business, and merely facilitates it by incrementally improving it through some means, you might question whether you need to own the tech. 

Team Size and Capability

How large is your team, and what capacity do they have for the type of work involved? You and the folks you work with are super smart, with well-rounded skill sets, but if you’re missing expertise that’s core to the technology, it might be worth buying versus hacking away. Behaviorally triggered experiences that leverage AI or machine learning are a great example here. There are plenty of firms that have worked hard to make AI commercially applicable and accessible to businesses. If you’re not Amazon, Google, IBM, or Facebook, you probably don’t need to own this discipline, just direct it.  

Cost

While it seems nonsensical, it might be cheaper to buy the technology you need. People costs and platform fees will both show up in your OPEX (operational expenditures), but there’s an opportunity cost to how you allocate your human resources, and your intention to build the technology yourself might necessitate hiring for extra capacity or skill sets you don’t currently have. Additionally, most vendors, under an NDA, can make a clear demonstration of the impact they’ll have on your business using your own engagement data, which you can validate with client references or through a proof of concept test.  

Ability to Maintain

Let’s face it, even when we build carefully crafted project plans, our work breakdowns typically fail to extend beyond post-launch support to encompass the most critical item: the amount of capacity you should allocate to steady-state maintenance. Easy to overlook, ongoing maintenance implications are hard to think through. “It took everything in us just to ideate a solution and build our implementation plan that carried us to production!” But if a leader in your organization is challenging you to think about the effort or the “people cost” implications of ongoing support for this new experience, take a pause to tease this out. If your response implicates the need to hire up, assess whether you truly need to own building the solution.

The RFP

You’ve resolved to buy, or perhaps you’re undecided. Regardless, chatting with vendors will help you accelerate your learning and inch you closer to a decision. But before you start pecking away e-mails or responding to lead capture forms on company websites, pause for a beat and consider a formal request for proposal process, or RFP. This doesn’t need to be onerous. Preparing to audit vendors is a lot like your approach to hiring. The amount of time you put into screening, interview rounds, and onboarding can help to generate a valuable and collaborative relationship. Here’s a light framework for running a successful RFP.

Assemble the team

Cue the 80s montage music, and pull together a ragtag crew of peers that will help you assess vendors. Ensure that critical functions responsible for implementation are represented. For most organizations, this might include a business lead, UX or brand design, and a tech lead. If you have a procurement function in your org, pull them in. They can play “bad cop”, helping you to negotiate so that you can make the best decision for your business without souring a new and important relationship. If you don’t have a procurement lead, consider pulling in someone from Legal, or your boss, to wear this hat. 

The Request

You know your way around a design brief or an architecture brief, so apply this to the RFP. Frame up an invitation to engage by defining some background information, your goals, requirements, what you’re looking for in a vendor, specific information you want to see in a response, timeline, budget, and next steps. 

Pitch backs

Give each vendor an opportunity to formally respond in a meeting format. Ensure they’re prepared by making yourself available to field questions or clarify details. Pitch backs might need to span multiple meetings. The size, complexity, and risk of the decision you’re making should dictate how deep you’ll need to go with vendors. You might find it’s helpful to run multiple rounds that cover different topics and to cull the list of vendors along the way. 

Scoring

My typical approach with scoring is to create a simple Google sheet that allows your team to rank the company along a number of criteria that are important to the stakeholders represented in your process. During a recent augmented reality platform assessment, we looked at client roster, commercial application, integration timeline, quality of AR assets, and ability to support our long term roadmap. For a recurring billing platform RFP, we looked at subscription and account management, billing and payment features, finance and revenue recognition, reporting and analytics, and solution architecture. On the other end of the spectrum, a recent audit of UX design firms had us focused on design acumen, presentation preparedness, data literacy, team energy, diversity within the agency, and collaborative process. 

Client references

You’re tired of sitting through pitches, and you’re ready to get a second opinion. Set the expectation upfront that you would like client references, and get at least two. This will help you understand how the vendor shows up as a collaborative partner, and what their current clients experienced during implementation. If relevant, ask the referee about the results they observed. No need to get absolute figures, just validate that their KPIs were impacted positively. If you have a bad reference call that doesn’t yield insightful information, that can actually say a lot about the vendor’s understanding, or lack thereof, of what you’re looking for.

Negotiating contracts

Deep breaths. This can often feel confrontational, but it need not be if you’re transparent about what your needs are. Vendors often start out with generic, off-the-shelf pricing, so think through what your negotiating points are. Where do you have leverage? Dig into how their costs are structured, and always ask if they’re willing to do a POC (proof of concept) for free. If they stand behind the lift their product can generate, ask them to prove it. And be sure to look out for nonsensical filler fees. With a little coaxing, you can often remove yearly recurring platform fees,  implementation costs, or service fees. 

Onboarding

You’ve awarded a vendor your business, and you’re marching towards implementation. Don’t undermine the powerful importance of onboarding them. Like a new employee, they need to know a bit more about ways of working with your organization. Put together a care package that details your tech stack and system architecture, design systems and brand guidelines, introductions to key leads and their area of ownership in the project, and any insights or research that might inform their work.

Back to Build

Perhaps you ran a comprehensive RFP process, but none of the companies stacked up against your criteria. That’s okay! Maybe it is worth it to own the technology yourself; just be sure you’ve carefully weighed the costs versus the business impacts of either decision. This doesn’t mean you should use the RFP as a ruse to take a peek under the hood and go full-on Amazon Basics, courting a relationship with a vendor just to turn around and rip them off. But after careful assessment, if you find that your team can afford to ideate, build, and maintain a new experience better than the companies you surveyed, more power to you! You will have reached a sound conclusion, devoid of emotion and bias, and based on careful assessment. You and your leadership team can rest easy knowing you put the decision through its paces.