The practical guide to building the perfect tech stack for revenue operations

Learn how to build a best-in-breed tech stack by joining our partner webinar with Segment on February 5. Brandon Purcell, Forrester’s Principal Analyst and Peter Reinhardt, Segment’s CEO will discuss the new MarTech landscape and how your company can build the customer data technology stack that matches the reality of today’s multi-channel, digital era.

This article covers how to buy apps for your revenue tech stack to provide you the best solutions to your everyday operations challenges and provide your team the highest ROI. It’s part of a series on best practices for professionals in revenue operations, marketing operations, sales operations, and customer operations. Learn more about best practices for operations in “The professional guide to revenue operations.”

What goes into the perfect tech stack for revenue operations

This article will discuss the best way to buy the best technology to build out your tech stack - your marketing stack, sales stack, customer operations stack, or overall revenue stack. We’ll include insights into managing technical gaps in your tech stack as well as a full walkthrough of best practices on how to procure new technology. What is a tech stack? It’s the combination of business applications you use to execute essential revenue processes - from capturing leads for marketing, processing deals for sales, and managing renewals for customer success. So what’s the best way to go about building one?

A good place to start is to forget the idea of a single, objective “perfect tech stack” because, not surprisingly, there’s no such thing. But you already knew that. For example, consider the task of building a MarTech stack. Marketing operations professionals must choose from more than 7,000 different applications for email automation, metrics, website analytics, content management, social media, and many, many more. What’s important is to not only pick the best possible choice for individual apps to suit your organization’s unique needs but also to design a working ecosystem of apps that will collectively provide the solutions you need.

There’s no “perfect” tech stack hiding among these 7,000 marketing applications. Image courtesy ChiefMarTech

The challenges in building your tech stack

You may have heard the statistic about how 50% of all IT projects fail. One of the most common causes of these failures is a lack of alignment between software projects and business goals. Sound familiar? Unfortunately, it’s common for decision-makers to acquire new technology (or stick with suboptimal existing apps) based on reasons that have little to do with solving business pain, which include (but aren’t limited to):

• Cost - Cost is obviously a concern for acquiring new technology (or sticking with existing solutions), especially as revenue operations professionals find themselves more responsible for managing software budgets. For finance and procurement teams, it’s usually the top concern. However, savvy operations professionals know there can be painful consequences for choosing the cheapest option, rather than the solution that will genuinely address their pain.
• Most exciting/largest number of features - Bells and whistles seem appealing at a glance, but as we’ll discuss shortly, having too many features can lead to unforeseen problems downstream with adoption, ROI, and outright proficiency.
• Improper scoping - Not properly scoping a project in terms of scale, cost, use case, and stakeholders can lead to acquiring a solution that doesn’t solve the real problem, isn’t powerful enough, or that no one uses. Sometimes, organizations acquire new technology for the sake of it, or based on hearsay, rather than as the result of a deliberate, strategic process of first, determining a business problem/opportunity; second, determining the solution exists outside the current tech stack; and finally, beginning the search for vendors.
• Institutional inertia - Many operations professionals have a story about how their team continued to stick with a suboptimal tech solution “because that’s how we’ve always done it.”
• Executive decision (“regime change”) - Another familiar story among ops professionals is how executives with budget authority made sweeping decisions that affected their tech stacks. These changes are commonly part of management transitions, in which new executives decree radical tech stack changes (which don’t always work out well for the operations teams who end up stuck with them).

“Can’t I just get everything I need from a [publisher suite] portfolio? Sadly, no. Your [technology] of choice does indeed make an excellent starting point for assembling your unique...ecosystem, but no single vendor offers a 100% complete solution.” -Forrester Research, Making Sense Of Enterprise Marketing Technology

Publisher platform suite vs. best-of-breed

We should also discuss some of the critical dilemmas in building a tech stack. A common decision when acquiring new technology is whether to build out a tech stack using apps from the same publisher suite, as opposed to picking individual applications. There are differing opinions on the topic, though analysts such as Forrester Research believe that “no single vendor offers a 100% complete solution.”

Because every organization’s unique needs are different, it’s difficult to give a single, objectively correct answer to this question. It is, however, worth considering these additional factors in your decision:

• Ease of use - While apps that belong to a single publisher’s suite are more likely to have standardized user interfaces, best-of-breed apps often tend to distinguish themselves in terms of user-friendliness.
• Functionality - Best-of-breed apps tend to win over suite applications in terms of functionality - their more-robust features make them best-in-class. That said, some apps may have a vast quantity of less-than-useful or not fully-developed features that may make the app itself less valuable overall.
• Flexibility - Flexibility is another area in which best-of-breed apps tend to win. One of the hallmarks of best-of-breed software is frequent updates that continually improve and expand on functionality to give users more options and better interoperability with other applications.
• Current and future fit - The ultimate arbiter of why you should go with software A versus software B should be fit to your use case, today and in the future. It’s worth paying attention to the way your apps handle considerations such as data (collection, storage, transfer) and security (authentications, permissioning, and data protection). Both issues will only become more important as your business scales, and you find yourself with more and more customer data under management.
• Open API - It's becoming increasingly important for business software to have an open API. APIs are the level of software at which one application "talks to another." Having an open API gives users more flexibility to pass data between different pieces of software. Not having an open API means less flexibility and more potential roadblocks.

Lack of capacity is the #1 pain point for engineering organizations - making it challenging to justify internal integration projects. Image courtesy CodingSans

Build vs. Buy

Another critical dilemma in purchasing new technology is the question of building versus buying, particularly on the issue of integrations - the software connections that link different applications to each other to let them share data. If you’ve ever had to flow marketing campaign leads from a marketing automation platform (MAP) to a CRM, or copy in-depth account details from your support helpdesk into an enterprise resource planning (ERP) tool to confirm payment status, you know this pain.

While there are firms that opt to request internal builds on integrations, such projects require valuable IT resources. Unsurprisingly, engineering organizations report their #1 pain remains capacity, which is just one of many essential points to consider:

• IT resources - As mentioned, IT organizations struggle to staff every project on their list. It’s frequently a challenge for companies to justify sending engineering teams to work on integrations for internal business software when those same engineers could be working on developing a better product.
• Long-term maintenance - Sadly, internal integrations aren’t one-and-done projects. While your team may finally get IT to build a functioning integration between your CRM and ERP today, future version updates to either application will often break the integration, bringing you back to square one. Internally-built integrations tend to create significant overhead for engineering teams over time.
• Permissioning - Operations professionals understand there are day-to-day challenges with authentications and account permissions. Some team members absolutely need administrator-level access to certain apps; others can get by with read-only. Sharing data across different applications to only the appropriate parties with specific access can become a headache in itself.

It may make sense to include a statement of work as part of your procurement + implementation process.

Tech stack buying cycle checklist

Now that we’ve covered the potential pitfalls involved with acquiring new technology, we can dive into a step-by-step checklist to help you acquire new technology in the most expedient and painless way possible.

Pre-purchase prep:

• Scope out a tech stack roadmap - In an ideal world, revenue operations professionals have the time to scope out a strategic roadmap that maps out their current and future tech stack in aggregate, accounting for current and future use cases. Roadmapping new tech stack components can be both a functional and creative exercise. The idea is to map your tech stack against future projects and any customer experience (CX) initiatives for your team. For examples of inspiring tech stack roadmaps, take a look at the annual Stackies awards.
• Scope out a requirements map - In the real world, it’s a good idea to at least create a requirements map, even in the form of a simple spreadsheet. You can fill it out with features, pricing, integrations, security, and other factors that are important to your use case, now and in the future. It may also be worthwhile to include prompts for things like peer feedback, referral feedback, assessments from leading analyst firms such as Gartner or Forrester, or even reviews from sources like G2Crowd and TrustRadius. Just filling out a spreadsheet and placing potential solutions side by side can give you more of a strategic overview of your options when the time comes to choose.
• Make friends - Having a strong working relationship with relevant parties is an extremely effective way to set yourself up for success.Friends in the IT procurement department can provide speedy processing of new technology orders. Friends on the executive team can provide responsive budget approval and help enforce adoption and enablement once you’ve brought your new tech in-house. Friends in legal and security can help you ensure you’re following every guideline and whisk you through security and legal reviews. Friends who will be end users, whom you can lead to training and enablement so they actually use the new apps and provide ROI on your purchase. Even friends in customer experience (CX) who can help you map eventual CX goals to items in your tech stack.

Buying cycle process:

1. Scope out implementation - Even if you haven’t created a full requirements map, at a minimum, you’ll need to scope out specific needs in the context of your use case, as well as costs and implementation timeframes.
2. Identify key stakeholders - Once you have a fully scoped-out plan to acquire your next piece of software, it’s a good idea to immediately identify everyone who will be involved in the process and begin clearly communicating expectations and timeframes. Stakeholder involvement might include, but not be limited to, consulting on product usage scope, actively participating in the evaluation process, or actively participating in enablement. Some larger organizations utilize a cross-functional product council consisting of members throughout the organization to give more stakeholders “skin in the game” and drive active participation in the process. And of course, where applicable, executive sponsorship can be especially important to not only push through procurement but also drive adoption.
3. Technical evaluation - The process operations professionals know all too well. Again, to minimize painful delays or buying something the business doesn’t truly need, it’s a good idea to have your use case and objectives fully scoped, including the technical, process-related, and people-related limitations that are causing your pain. Communicating these needs upfront will also enable vendors to provide the most relevant example materials and provide the most relevant product demo to help your decision. (Your evaluation should also include factors such as information security and any legal restrictions you’ve identified with your security and legal teams.) 3a. Integration assessments - An integral part of your evaluation process should be checking the status and availability of integrations between any new apps and your existing tech stack. API integrations are now fundamental to successful implementations of new technology. Your exciting new app may provide significant value against your use case, but could lead to logistical headaches if it doesn’t play well with the other apps in your stack.
4. Scope implementation with business champion - A significant step in the process is to finalize implementation details and expectations with your business champion. This step should definitively answer questions about who will need access to the new application, who will use it regularly, for what purpose, what data will need to be accessed, what deliverables will be involved, and when. It’s also important to account for implementation and training in your schedule, ideally at times that are minimally disruptive for end-users and don’t conflict with other major business initiatives. Some organizations opt to use a full statement of work to document this process.
5. Purchase cycle - After making that fateful decision, there’s always going to be a wait of some kind when making a purchase. As mentioned, operations professionals minimize the wait by scoping out project size, budgets, and partners in advance.
6. Enablement - Beyond asking executive sponsors to enforce the adoption of your new app, a significant driver of adoption is internal enablement. One best practice is preparing enablement materials in advance of implementation, including training and additional collateral.

Takeaways

Hopefully, you should now have some additional perspective about the challenges in acquiring new technology. More importantly, you should now have some actionable ideas on how to plan and execute current and future technology acquisitions. For more practical advice on how to successfully manage people, processes, and technology for revenue operations, please see the following:

• The professional guide to revenue operations
• How to align your tech stack with your organization
• Build a revenue operations team as a revenue ops leader