How we built the wrong feature

In the early stages of 7shifts, it was just my wife (Andrée) and I. She met with potential clients and provided support to existing ones, while I did all the programming, design, etc. We both had full time jobs, which made it challenging since 7shifts was picking up and becoming more demanding.

Our client base was growing quickly across North America, but we wanted to have more clients in our own backyard. We needed to start meeting with clients face-to-face to get in-depth feedback on our product. So, we started reaching out to local business owners and that’s when we met Rick (well, that’s what we’ll call him). He owned a few restaurants in our city and was interested in trying our software.

Listening to potential clients

When we arrived at Rick’s restaurant for our first meeting, I opened my laptop and began showing him around some of the features and functionality of 7shifts. He seemed unfazed by my excitement and didn’t seem impressed. Evidently, something was lacking in our app.

I asked him for his initial thoughts and without missing a beat he said, “I need a budget tool”. I wasn’t sure what he meant, so I asked more questions about how this would help him. He carefully explained what he needed to project labor costs and after asking a few more questions, Andrée and I both had a good understanding of the problem.

We left there thinking we knew what we needed to add in order for Rick to start using our app. Perfect.

The wrong solution

As soon as we got home, I started the wireframes. I showed the sketches to Andrée and we both thought it was exactly what he had described to us.  I added the feature and emailed Rick to let him know it was ready for him to try out.

We met up with him again a few weeks later to get his thoughts on the new budget tool. It only took a few minutes for us to realize we were the only ones excited about the new feature.

He hadn’t even tried it.

To make things worse, he began asking for more features. We started jotted everything down and it quickly became a never ending list of requirements. It was a “before-I-can-use-this-app-I-need” kind of list. If you’ve done B2B SaaS before, you know how frustrating this can be.

When we walked out of the restaurant this time, we felt defeated. Not only did he want a bunch of features we didn’t have, he hadn’t even started using the software.

Unused feature

A few years past and while Rick never did start using us, the budget tool remained. Nobody said it was good, but nobody said it was bad. So we just left it, thinking that it was fine.

One day, I decided to run some tests to see who was using the budget tool.

Less than 2% of our users were using it.

Why was that number so low?

Asking for feedback

We started talking to a few clients and asked them why they weren’t using it. Their answer was simple – “It just doesn’t work for us”. They showed us how they did their labor calculations – all offline in excel, and not in 7shifts. I was stunned. The problem existed, but our solution didn’t solve it at all. We had it wrong this whole time.

After using ListenLoop to gather more feedback from existing clients, we built the new budget tool. Two days ago, we released it.

The old budget tool let managers punch in the total dollar amount they estimated that they would spend on labor that week. They would then have to do math to break up that 100% labor total and distribute it across the 7 days in percentages. This wasn’t how restaurants estimated labor. Here’s how they do it: they actually don’t know the dollar amount of labor, they just know the approximate percentage of labor they want to allocate based on their weekly or daily sales. The weekly and daily sales are their projections.

The response to the new budget tool

After launching our new budget tool. Here are a few emails I received.

When clients start emailing you with excitement, you’ve done it well.

What we learned

We’ve developed a S.T.U.P.I.D acronym that prevents us from building wrong features down the road. Here’s how it goes:

S… Spot the problem

Talk to a client in your industry about a particular problem that needs solving.

T… Talk to two

Find two other clients in that same industry. Talk to them about that problem. Do they also feel the pain? How are they solving it? If it’s a problem for them as well, proceed to “U”.

U… Understand it

Make sure you truly understand the problem as a whole. Be weary of clients that start drawing out how they would solve it using a particular flow/interface they’ve thought up. Don’t get distracted by their implementation details, clients aren’t typically UX experts. Just listen and understand their problem.

P… Prototype it

Sketch a prototype or wireframe. Walk them through how you imagine it working. Watch for their visual cues. Are they confused? Are they excited? If all 3 of them are confused, head back to the drawing board and come up with a different flow.

I… Inspect them

Build a functioning prototype and watch them use it (hallway testing). Iterations should be small at this point.

D… Deliver it

Build it and launch it to the masses. If it turns out to be a home run, you could be receiving a good amount of praise email!