<img src="https://ws.zoominfo.com/pixel/Nfk5wflCTIIE2iSoYxah" width="1" height="1" style="display: none;">

How to Put the "Value" into a Tech Stack Evaluation

by Drew Davidoff | Jan 25, 2024 3:38:33 PM

Tech StackRecent research shows that the average SaaS tech stack has 291 tools—and while there’s year-to-year fluctuation, the overall number continues to climb. That makes sense, given that the number of available tools increases exponentially each year.

While that’s great for developers, it means that, if you’ve been charged with evaluating your company’s tech stack, it’s no small undertaking. And the hardest part isn’t even wrapping your head around the hundreds of tools in your stack. 

The biggest challenge is evaluating the business impact of your tech stack. That’s because you’re not just assessing the functionality; you’re examining how it helps or hinders your company.

That can be a daunting responsibility, especially if you aren’t sure how to best approach the evaluation. It’s also easy to get bogged down and overwhelmed, especially if you lack a systemic approach.

In my experience, six key areas will help keep every tech stack assessment on track. Read on to learn more!

Have a clear goal

Why are you conducting this evaluation? There could be a number of reasons:

  • Were you charged with reducing your overall tech spend?
  • Do you need to boost productivity?
  • Are you trying to find tech gaps and/or redundancies?
  • Is your current tech causing some sort of acute pain and/or isn’t working well for you?
  • Are you trying to identify friction?
  • Do you need to understand what your current tech utilization looks like?
  • Do you just need a tech inventory or other routine assessment? 

There can be many reasons to conduct an assessment, but you should know your goal going in.

Choose an appropriate measure of success

Your metrics must be tied to your goal. What is your pain point? What is the best measurement to determine if it is resolved? 

If your pain point is that your tech stack has too many tools, then reducing the overall number, along with subscription costs and licenses would be a valuable measure of success. 

However, if your goal is to improve tech stack utilization, “tech spend eliminated” or “number of tools removed” might not be the best way to measure success. If anything, you might discover that you need to upgrade or find new tools to fill the holes you’ve identified. Perhaps you’ll find that you need an integration to connect data with a couple of tools that seemed redundant, but two teams use the tools to share data. You’ll want to pay attention to activity and results trends in cases like these, but you should also be sure to collect qualitative data from users about how their experience using the stack has changed.

Involve the right people

The key to a successful tech stack evaluation is assembling the right team of people.

If your company has an IT department, they need to be included in these discussions. However, while IT provides a valuable perspective, that department isn’t looking at tools in the tech stack from an end-user perspective. For instance, they might see two reporting tools in the stack and decide that one isn’t necessary, although they might ultimately serve different purposes or one may serve as a backup system. Remember, these decisions about your tech stack are business decisions, not just IT decisions.

That’s why you also need to include employees—preferably power users who create value—who actually use different items in the tech stack. Once you start diving into each tool to find out how it is being used and why, you’ll need their perspective. 

You’ll also need to include someone who understands your company’s business process to oversee the evaluation. This is a crucial role, as this person will pull the plot together to keep objectives in mind. Someone from RevOps is ideal, but if you don’t have a defined RevOps team, you should designate a general technology champion with a good understanding of your company’s business processes.

Note: I want to be clear that RevOps is not a technology management function. As RevOps has become used as a business buzzword, many people have come to believe that they manage go-to-market tech. That’s not their job description! 

RevOps searches for friction, pain points, and problems within processes, works to identify their cause, and “guards the plot” for GTM. That’s why RevOps should be included in tech stack evaluations.

Inventory Your Tech Stack

Make a list of every tool in your stack. That’s it. Don’t overcomplicate it, and don’t act or draw any conclusions until you’ve asked the questions in the next section.

I would advise against trying to categorize each tool at this point because it’s easy to get bogged down in the details of where something fits and why. Simply compile each one and keep moving! 

Tip: Look for subscriptions you may have forgotten you’re paying for. Check for both monthly and annual subscriptions - the one-time annual renewals can get missed, especially if the subscription isn’t consistently utilized. 

Ask the Right Questions

In this stage, dig deep before making any judgments. Remember, you’re not just evaluating your tech stack; you’re evaluating the impact of your tech stack. 

Here are some of the questions I’ve found to be truly valuable:

  • What are the jobs to be done (by the tools)?
  • What features enable those jobs to be done? 
  • Where is the overlap of jobs to be done and those features?
  • Who is using this tool, and how are they using it? 
  • Are there “holes” that are being filled by workarounds? If so, where? 
  • What is the impact of this tool? 
  • What is it being used for, and why? (Don’t overlook the why! It’s important.)
  • What is the “job to be done” by each tool—and is it doing that job?
  • How does it support (or not support) your business processes?
  • How does your tech stack generate value? What are the ways you measure that?
  • Where could value be added? 
  • What are the costs of removal, including monetary cost, business impact, etc?
  • Is the “juice” gained from adding or subtracting a tool worth the squeeze? 
  • Which products have impactful redundancies? (See below)
  • If a redundancy isn’t there for a reason, what are the costs and benefits in terms of monetary and productivity?

Remember that redundancy isn’t necessarily bad

A line in Scott Brinker’s MarTech for 2024 report really stuck with me: “The fire extinguisher in your kitchen hopefully has low utilization. But when you need it, you need it.”

Redundancy might be a particular concern to management right now since the dollar was “light” a while ago. As a result, it’s possible people may have added to the tech stack with abandon. 

That may be a legitimate reason to evaluate your tech stack and look for ways to cut costs—but redundancies aren’t necessarily bad. That’s why you must examine the impact of the redundancy. If the tech isn’t creating double work or friction, the redundancy itself isn’t an issue.

Certainly, there may be cases where redundancies are not warranted—but be sure to ask the questions I recommended before impulsively reducing your tech stack. 

Sometimes, redundancy is a valuable best practice—for example, with database backup. A failure there, coupled with a backup failure, would be disastrous for most businesses.

In other instances, the redundancy may be adding value in other ways. For example, all CRMs have a reporting and dashboard functionality—but your company also likely needs a dedicated reporting tool, like databox, or HubSpot reporting and the very different Google Analytics reporting.

If you’re still feeling overwhelmed—and I hope you’re not!—by the idea of running a tech stack evaluation, look at it as an opportunity. You can increase your company’s efficiency by reducing pain points and supporting business processes. Remember, always examine a tool’s impact!

New call-to-action