SaaS Buy Guide - What You Need To Know

Business leaders today are constantly challenged to produce more with less, yet the average tech stack for a company seems to be in a state of exponential growth. Because of this, it has become increasingly more difficult for businesses to make well informed decisions on what software they need to take their business to the next level.In this blog series, starting with this high level overview, we will give you a repeatable process to follow when making a purchasing decision. Follow these steps and you’ll be sure to avoid the endless graveyard of technology your company constantly cycles through.

Start with the Problem

Too often have we seen businesses rush their decision on a new piece of software only to find out months after implementation that the tool they purchased actually doesn’t easily integrate with already existing systems. Or more broadly - doesn’t fit their most basic needs. This common mistake can be avoided way ahead of implementation if you follow a simple rule: start with the problem.

When you start by defining the problem you are trying to solve for, you are able to start your project on the right foot by providing your organization with the following:

• Understanding of the business impact
• Clarity on the root cause of the problem
• Focus on a common goal

There are a number of different strategies and resources out there that can help you with defining your problem(s) but you really don’t have to overthink it. Below are some questions and strategies you can use during problem identification.

• Who is involved?
• What is involved? (think systems & processes)
• What are we trying to solve for?
• Root cause analysis: the five whys

Be concise when it comes to defining the problem and use those closest to the issue to help understand the actual impact the problem has on your business. After all, the decision to purchase will impact your bottom line so you’ll likely be responsible for articulating business value to your colleagues.

SaaS Buying Guide Requirements

If there is one thing we’ve learned from our years of experience helping companies buy and sell software it is that a lot of them are really good at marketing & selling their product, but many fall short post-sale due to unkept promises and embellished feature capabilities. When it comes time to approach vendors and compare solutions, having a list of your needs and wants will be critical. But how do you come up with the list? Follow these steps below to set yourself up for success:

1. Identify the different types of requirements
2. Conduct requirements gathering sessions
3. Compile your requirements list

Types of Requirements

Business Requirements

Business requirements represent the interest of your business/stakeholders. By nature these requirements will be more broad and often read like goals and objectives that would result from the technology. Defining these requirements first will help you align your user & solution requirements to the business.

User Requirements

User requirements represent the interest of the end user of the software. Understanding what end users need and want are critical to ensuring the success of your implementation. If these requirements aren’t met it is likely that they won’t use the software and you will end up with adoption issues.

Solution Requirements

Finally, solution requirements will represent the technical needs of the software. Identifying these will allow you to understand what is needed to successfully implement the technology within your existing tech stack.

Requirements Gathering

Business Requirements Gathering: Meeting with Stakeholders

Your stakeholders should have a basic understanding of the problem at hand and what it would mean to the business to solve it. While the requirements are the main outcome of this session another benefit you will get is stakeholder alignment and buy-in.

User Requirements Gathering: Meeting with End Users

End users are the ones who will ultimately use the software in their day-to-day operations. Gathering these requirements will ensure you purchase a tool that they will actually use.

Solution Requirements Gathering: Meeting with Technical Subject Matter Experts

This final meeting will be a gathering of all the technical experts in your organization. As a collective they should have expertise across your entire tech stack so that you can properly call out technical needs within the various systems. They will also be able to validate the feasibility of delivering on your business and user requirements based on their technical knowledge.

Compiling a Must Have List

Your requirements should be clearly documented and defined and we recommend that you bucket them them into the following categories:

• Must have - Must have requirements are non-negotiable. They represent the list of items you will need in order to achieve your goals.
• Should have - Should have requirements are not vital but would provide significant value. These are items that help you narrow down your vendor list even further to ensure the software you purchase brings value to the organization
• Nice to have - Nice to have requirements are those that, if left out, would have little to no impact on achieving your goal but could help provide additional value to the organization. These requirements should really only be considered if you find yourself between two or more vendors.

Evaluating Saas Vendors

Now that you have your problem identified and your requirements documented, it’s time to see what's out there. Forewarning - there is a lot. The SaaS and martech landscape is larger than ever and isn’t showing many signs of slowing down. So how do you start? (Hint: Don’t start by scheduling ALL the demos)

Assemble the Search Party

This group should represent the interests of stakeholders, users, and technical teams equally so that you are validating against all your requirements.

Research

Have the team put those search engines to work and find out who some of the top vendors are. While they conduct their research make sure they have the requirements list handy so they can compare what they see on the internet to what your organization needs. Have them place their notes in a shared document, this will help you in our next step.

Short List & Schedule Demos

This should be a collaborative effort within the team utilizing your research notes to pair down your initial list of vendors. Once you’ve gotten your targets, have one person on the team be in charge of scheduling demos and maintaining notes from each meeting. It is likely you will need more than a couple of meetings with various vendors before you feel comfortable moving to the next stage.

Contract Negotiation

Lastly, once you’ve done all of your demos and requirements validation you should have a pretty good idea of your top 2-3 options. If required (or offered) you may opt to sign up for a trial of each software. Regardless, your final step in the process is going to be contract negotiation. Sometimes this is how you can separate two competitors, other times it is just how you get the best price, either way we often see this step overlooked and it can lead to long term financial impacts if not handled properly.

Bonus Considerations

Over time, we’ve seen some key considerations overlooked when making a purchasing decision. We’ve listed these below for your benefit:

• Scalability: Will this software scale along with our business and its growth plans?
• Cost of Ownership: Aside from contract and licensing, what is required to maintain and improve upon your implementation?
• Build vs Buy: Is there an existing tool in the tech stack that could solve the problem and save the organization some cash? (even if temporarily)
• Networking: Without being partial to personal relationships, your network can sometimes seriously help you gather info or point you in the right direction.
• Measuring Success: At the end of the day, how will you measure a successful implementation? This often will align directly with your business requirements and the outcomes you are looking to achieve.

‍