Buying new software is fun! I know a few of you just shuddered at that statement, but trust me, when done right, it really can be. Read on to see how.

Whether it is to solving a challenging problem for your team, enabling scale, or just freeing up your team members’ time to drive more value-add tasks, the benefits of a new system can really impact your team and the business.

However, the current process of vendor and tool selection is painful.

You typically start this process with the general business challenges you are facing – “my reporting is all manual and it takes a day to create,” or “I would like to capture and report on our customers’ health and risk scores based on their activity and input from our team.”

From there, you move into the often lengthy internal “discovery” phase where team members, team leadership and other impacted department personnel meet to share their expected requirements and needs. This can take days – if not weeks or even months!! – to get everyone in a room, document the requirements and obtain buy-in.

After all that, the infamous “Request For Proposal” (RFP) is created and sent to potential vendors. Everyone eagerly awaits their response.

Unfortunately, that response is often underwhelming. Typically, you get back a generic, canned response from each vendor that may or may not answer your questions such riveting questions like “Describe your GDPR policies and certifications.”  Your team needs to sift through the response, try to make sense of it and connect the dots of your requirements and the vendor’s capabilities – usually done through a set of additional meetings and demos with each of the vendors. It is a pretty inefficient, time-intensive and challenging way to do things.

The good news is there is a better way!

Agile software development has been around for 15+ years now, and after having some internal conversations at Toast for an RFP we were recently working through, we started to explore using the idea of Agile User Stories as a way to determine our requirements for the software purchase.

User Stories follow this framework – “As a _____________, I would like to do ________________, so that I can _______________.” Fill in the blanks.

“User stories are part of an agile approach that helps shift the focus from writing about requirements to talking about them. All agile user stories include a written sentence or two and, more importantly, a series of conversations about the desired functionality” 
– Mike Cohn, a main contributor to the invention of
Scrum software development methodology

As we started to work in this method, it became apparent that this was a much cleaner and faster way to get to the user requirements – mainly because we could just send out this simple framework to all potential users and have them – in straightforward English – tell us what they wanted to do with the tool. No jargon, no vendor specific terminology, just what the users wanted.

“As a Restaurant General Manager that owns Toast, I would like to view short videos, so that I can learn more about the Toast POS and solve my own hardware issues,” was a much more specific version of “I want to watch videos.”

Additionally, by capturing these user stories, we were able to share them with our potential vendors to have them tailor their technical demos for us.

This was one of the biggest benefits of this approach since it puts the demo on the path to what is important to your organization rather than what the vendor wants to show you. And, it becomes more readily apparent if there are gaps in the vendor’s technology if they can’t demonstrate their ability to address each one of your user stories.

This paradigm shift was a game changer for us throughout this software selection process – it was faster, cleaner and easier. Going forward, this is definitely how I will buy software.