How to select software products

Selecting a software product is like choosing a house for your business to live in, except it’s more expensive and the risks are higher.

Dave/Debbie/Darren set it up before they left

At San Digital we’re fortunate enough to speak to a lot of people about the way that their businesses work. A lot of the time that involves software of some sort, no great surprise there. Frequently there are industry specific systems in place, so we ask why that thing was chosen, the most common answer is “person in department x set it up”. There comes a point when it’s a very bad idea for companies to continue to use this method of choosing tools.

The cost of change isn’t linear with the size of the company, but the cost of consideration is, change is the hardest thing for large companies to do. Above about 30 people selecting products deliberately is essential. A little bit of consideration can save a whole lot of cost of change.

What is product selection?

A very common question is “can you recommend a CRM?” or can you “recommend a CMS?”. The obvious response is “what do you need it for”, and then things get interesting.

We frequently talk about people, process and tools – specifically in that order. The choice of tool is totally dependent on the persons goals and the task at hand. Pretty much anything looks like a nail if you have a hammer, and I’ve got several screwdrivers that do double duty as a chisel.

The process of selecting a product (tool) is much more a process of gathering requirements from a set of stakeholders who are engaged in the process. This is especially important for anyone who works with technology day to day to understand, it may be blindingly obvious that the what the company needs and will end up being chosen is HubSpot. But that’s how IT projects that get foisted on the rest of the company happen (even if it was a business ask “we need a CRM”) and these projects fail, not because of the tool but through lack of use.

“We need a CRM” – “here is a CRM” is not a good path to go down. This principle is true of any requirement.

Products should be selected by and for the business, and facilitated by anybody dealing with the tech.

Requirements

Getting decent requirements consists of two activities, one concerned with depth and the other with breadth.

Getting past the inital request to an actual requirement is the process of repeatedly saying “why” or “what for” until you reach a KPI. The KPI is important for two reasons, firstly it lets you know if you need to care about the requirement and secondly it makes it a hell of a lot easier to get budget signed off. This is a little flippant, but if a requirement has no impact on a KPI then it may take a little justifying.

The next challenge is speaking to enough people, this is a combination of asking “does anyone else do anything like this” until you’ve covered everyone.

The key to keeping this simple is to do it quickly, speak to individuals not groups and once the requirements have been gathered publish it widely and invite a much wider group to poke holes in what has been written. Do not mention the kind of product that might be associated with requirements. An “increase conversion to hit targets” project will get more traction than a “CRM Project”.

At the same time as talking to people it’s also a good ideal to ask about any super important spread sheets that they have or shared inboxes that are used by the team. The answers might not be relevant, but they may also stop you totally missing the underlying requirement.

Just browsing

Given some requirements it’s much more possible to see the things that might meet them. The space for products evolves very quickly and so do the categories of product and their capabilities.

The simplest course of action at this point is to start searching for what is in each requirement. For the results that come back look and see what category of product comes back, are you seeing CRM, CDP, ERP, Marketing automation or a raft of other options over and over then that’s something to take forward. It’s best to avoid looking at the individual products in too much detail at this point.

Armed with a category name it’s wise to understand the capabilities that the market leaders offer and how they compare to the requirements that have been gathered. Sites like G2 Crowd are great for this, pick out the top three and see which of the requirements are met. If they do, then great it’s on to the next step.

If the market leaders aren’t meeting requirements, then it may be that there is a more specialised version of that tool that is more appropriate e.g. appointment booking software and dental appointment booking software are very different. Searching for industry specific versions of products may help flesh out the runners and riders.

Playing nicely with others

It’s rare that software systems operate in isolation, the CRM is unlikely to manage your books, but it would be nice if systems could work together.

Listing stems that are already in place may need to interoperate can help thin the crowd of potential solutions or at a minimum heavily influence the scoring. The ideal is out of the box integrations with existing systems. Interoperability is one of the main reasons to be biased towards market leaders.

Making the choice

Given a short that meets the stated requirements it’s time to get the stakeholders as involved as possible for all the demos and trials. It’s important that everyone reminds themselves of the requirements before all the process. Everyone involved should score against all the requirements.

After that it’s a simple process of adding up all the scores and having the CFO pick the cheapest.

Gaming the system

The reality is that large software manufacturers and not just the huge ones, understand the process of selecting software as well as anyone else. The result is anything machines that can be configured to potentially meet any requirement. The danger with a process such as Requests for Procurement is that the manufacturer can answer against requirements with a yes when the reality doesn’t quite meet expectations. “Yes, it can do that” translates to “Yes, it can do that with 15 clicks then wait a day”.

The onus should very much be on the procuring team to understand the requirements of the company and ensure that any system meets them in a usable way.

Looking to the future

Ideally software systems should be procured in line with a business technology roadmap. The reality is that a really clear understanding of what a company needs right now is probably more valuable than a guess about the future.