Buying Software? Avoid the Candy Store Trap and Choose the Right System

When we go to buy software it becomes really easy to get caught up in a lot of hype. We see a fancy demo and get really excited. I liken it to being a kid in the candy store. We walk in, see a bunch of sweet and shiny things and immediately want to buy them all.

Software vendors know this and are really good at creating this sort of highly curated experience that is designed to get you to buy. They will say they want to evaluate whether you are a good fit and want to get to know your needs. This is definitely true, but they also want you to buy. Unless you are really a bad fit for their product, they probably are not going to tell you there is a lot missing.

At the same time, you may not have a sophisticated method to work through the buying process. In particular, very few companies go through the process of rigorously defining their functional needs before attending demos. They know they want a new system of some sort, search the internet for a list of vendors that generally have a system that fits this need and immediately start booking demos.

After this, you might talk with colleagues about your impressions, but it is much less likely that someone will put together an analytic report that objectively analyzes the extent to which each option fits their needs. Without this, there are a lot of pitfalls we can fall into.

Does any of this sound familiar?

1. We will forget about the items we did not see or ask about
2. We will miss some detail on how a function actually performs
3. We will not think about what our new workflow will look like and if it will be better than the old one
4. We will not identify potential sacrifices, things we like now and take for granted will be the same or better.

I can guarantee that you will eventually figure this out, but not until long after you have begun using the selected system. I have seen this time and time again, where a client tells me about a system they selected and put into place, but after a couple of years and many sessions with support, they still struggle to make it feel seamless and natural. Users have frequently told me about their lack of understanding of how to use the system. Sometimes they don’t explicitly state their lack of comfort, but I can see it when I get them to describe how they use it.

Even more concerning is that once this situation has been created, it tends to stay as it has become ‘the way we do it.’ Until someone shows up with the gusto to challenge the status quo, everyone just kind of follows. In many case, I have seen poor or odd configurations that were designed by an employee that does not even work at the company anymore and whoever took over never thought to question it.

I can’t really blame anyone for not trying to fix it as everyone is busy with their day to day workload. They are deep in the day to day chaos and may not have the emotional energy to put towards changing how things are done.

I can go on and on about this, but I think at this point you probably know what I am talking about. Instead of continuing this tirade, what should we do different to deliver better outcomes.

Thank-you so much for asking me. Here are some easy things you can do to take your company on a path to better:

1. Once you decide you need a new system, avoid the temptation to jump right into demos.
2. Write out a list of features and functions you need, and break it down by categories
3. Expect this list to grow and evolve as you talk to more people, and even as you go through demos. It is not possible to think of everything in advance and you may learn of new things as you see your options
4. Make sure you answer every question on your grid. If you did not get something answered, or it is ambiguous, write that down and go back to the vendor to get clarification
5. Do at least 2-3 demos with your vendor shortlist. If you are in a large organization with complex needs, don’t be surprised if you have 15-20 sessions with a vendor across all stakeholder groups
6. Perform comparative analyses on various functional elements within your set of needs to see how different vendors perform for specific areas of focus
7. Make sure to identify who the winner is for each focus area, or identify if there is not one.
8. Make sure you further identify how important this focus area is relative to the others
9. Summarize the costs of each option. Break this down by Implementation cost, annual costs and provide detail on whether there should be additional budgeting for custom development that relates to building reports, integrations, or other custom elements

If you are still not sure how to set this up, click the link below to download my free template. If you feel you still need help working through the process, I am here to help.

Click the image to download a copy of my free template