When an organization decides to acquire new software, the task of finding the right solution usually falls to a single individual or a team of employees. It’s common for that group to start by searching for the best-rated, most-used solutions on the market. While this approach isn’t completely off base, it’s not quite the best practice a professional consultant would recommend. Read on to learn why it’s better to prioritize your processes over products when choosing new software.

The Motivator

If you’re looking for software, it’s because you recognize a need that your current infrastructure can’t fulfill. Before you start researching any feature sets or popular products, you must clearly define the problem you’re trying to solve.

Why?

Because this is the true motivator for the solution you’re going to purchase. It’s the main theme that will underpin the product features you’re looking for.

Many products will have similar feature sets, and as you start to look through them, it’s easy to get sucked down a rabbit hole of indecision. Going into that project with a full understanding of how those features relate to your processes helps you pick the solution that best fits your goals. There are a few basic steps to doing that, which I’ll explain next.

Start with the User Stories & Requirements

Let’s say your motivator for buying new software is that you need better automation. What does “better automation” mean?

Which of your current processes aren’t working?

How will those processes need to change?

How do specific types of users want the automation to function for their work?

User stories help you identify the outcomes you’re looking for so you can then translate that to the product features you actually need to improve your processes. Here are some examples of user stories around automation:

• As a sales rep, I want to automatically track leads so I can monitor my progress towards sales goals
• As a marketing manager, I want to automate the MQLs to SQL handoff based on triggers so I won’t have to do it manually
• As a customer service rep, I want to automate ticket routing so tickets are properly prioritized without manual intervention

Teams work together (and a consultant can guide the process, too) to define user stories that matter. It is from these user stories that the requirements for your project are set. Requirements are the business and technical must-haves that guide your product selection. When you know your user stories and requirements, you can start to look at products with features that fit that model.

Weigh Your Requirements

Defining user stories and requirements puts you on the path to selecting the right software, but when it comes time to look at actual product features, things can get messy…

It’s unlikely one solution will have all the features you want out-of-the-box, and some may have a bunch of extra features you don’t even need.

So, what do you do?

List out all your defined requirements, then weigh them numerically (ex: range of 1-5) based on their relevance to your ultimate goal.

What result can we absolutely not live without from this software purchase? What are the most important capabilities we have to come away with to meet our needs?

An experienced consultant will guide you through this process and help you calculate a score for each requirement. The top requirements will inform the top product features you’re looking for.

Your list will distinguish your must-have features from your nice-to-have features, making it faster to narrow down products that excel in those areas and choose which ones you want to demo.

The End Game

With the user stories and requirements clearly defined, you gain ultimate control of your software selection. You know exactly what you must have and what you can live without. Selecting an application this way minimizes risks to your implementation, improves the adoption of the solution, and solidifies the long-term viability of how the solution will evolve your other products and processes. So, as you prioritize processes over products, remember:

1. Go in with a specific definition of the problem you’re trying to solve and relate it to what’s missing in your current processes
2. Get input from users on how those processes must change and use those user stories to define requirements for the solution
3. Rank requirements by importance and use those to guide product features
4. Then—and only then—start looking at products that fit your feature hierarchy
5. Narrow your options and schedule demos ONLY with the solutions that match up