Companies that buy a tool, see zero impact from it, and then churn after wasting tons of money often have one thing in common:

They think the tool alone will save them.

They rush implementation with too little forethought into why they need it, what it should be able to do, and how it will be used.

Then they wonder why the tool isn’t “adding value.” It all comes down to a lack of strategy.

A strategy-driven tech stack is a tech stack that:

• Supports your sales process and methodology
• Reflects the needs of user stories
• Can handle future growing pains

This isn’t just the best way to build a successful tech stack. It’s the only way.

Support Your Sales Process and Methodology

Integrating tools into your revenue tech stack starts with:

• A sales process
• And a sales methodology to go with it

A sales methodology is like a philosophy that you follow to a degree, such as MEDDICC. Your salespeople are trained to follow a certain way of positioning your product, asking certain types of questions, following up in a certain way, etc.

The sales process is aligned with that methodology, but it’s the functional steps that you need to check off throughout the sales cycle.

You don’t need any one specific methodology, but you can’t have a strategy-driven tech stack without a solid sales process. It’s crucial that these two things are baked into your systems.

For example, the sales stages that you build in your CRM have to align with your sales process. This becomes a checklist that your salespeople follow.

• Did they validate that the prospect had a need?
• Did they validate if they had a timeline?
• Are they talking to the right person?
• Do they have the right budget?
• Do they want to move forward?

This way, you don’t just have a piece of software. You have a tool that’s making sure that everybody is marching in the same direction. Otherwise, poor habits like opportunities only being entered only when they’re a sure thing can creep into your business. Then you can’t forecast — and you can’t run a business without visibility into what’s happening in your pipeline.

Or the opposite problem happens and reps just enter any old thing into your CRM as an opportunity, and it never goes anywhere. That’s how you end up with a zombie pipeline problem.

In both cases, you’re getting absolutely no value out of your tools.

Your tools need to be a reflection of what you’re actually doing on a day-to-day basis.

Determine What’s Needed with a User Story Format

The format of a user story will vary from one person to another, depending on who you ask. But generally, it will look like this:

“As a [functional role], I would like to be able to [capability], so that I or the business can [benefit or end result].”

For example:

“As a sales rep, I would like to be able to keep track of where my accounts are in the sales cycle, so that I can see if an opportunity is stuck in a stage and notify my sales manager.”

You shouldn’t be looking at a piece of software trying to generate ideas for what you could do with it. Instead, start with the needs of your organization, then find a solution for them. Whether that solution is another piece of software or a modification to whatever already exists in your tech stack.

Remember that simplicity wins. It’s not about getting the trendiest or most complicated tool, but getting the tool that solves your problem specifically.

Having fewer, simpler tools also means your system is more stable because it has fewer breakpoints. It’s easier to learn, easier to implement, requires fewer resources to support, etc.

Think with the Future in Mind

What is your vision for the trajectory of your company? Does this tool have a shortcoming that will hamstring you in the future? Then that tool might not be the right choice.

In this case, it’s probably worthwhile to invest in the thing that has some futureproofing so that you’re not searching for a more robust solution in a quarter or two.

Don’t go overboard with this.

There will always be an infinite number of things that you might run into in the future without knowing about it now. But if you CAN foresee and pinpoint limitations down the road, consider looking elsewhere.

It’s Better to Buy, Not Build

Don’t try to reinvent the wheel. If you have a strong vision of a system that does something in a very specific way, remember that in most cases it’s better to buy, not build. 

Even if you find a way to do it temptingly cheap, building a custom platform for running your revenue organization can come back to bite you in several ways:

• You’re only serving the functionality of the needs you’re presently aware of
• You constantly have to pay a dev team to make revisions or fix bugs
• You lose out on best practices baked into every mass-market tool

There’s a discipline that’s involved with following best practices of solutions that are developed for mass audiences. Because they work, they’re the right way to run a business, and they’ll help you in the long run.

One major exception to “buy, don’t build,” would be a highly customizable CRM like Salesforce. Often we’ll recommend using this customization to build what you need rather than buy a whole new tool.

TL;DR

• Tools alone won’t save you
• To create a tech stack based on strategy, you need to:
  • Bake in your sales process and sales methodology
  • Find tools based on your users needs
  • Keep your future needs in mind
  • Buy, not build (usually)
    • Salesforce is an exception in some scenarios