Product | 5 mintutes | 30/11/2018

Customer Informed Development

How seriously should software companies treat customer feedback?

Opinions can vary wildly in this regard, but simplistically there are two ends of the spectrum. There are those who claim to take feedback incredibly seriously and put it at the centre of everything they do. At the other end, you have those who feel the customer cannot possibly know what they want until they see it.

There is obviously something in both arguments but just like the opposing extremes of political opinion, neither are perfect and perhaps neither are entirely truthful.

“we are not spying from the bushes or dressing to look like you”

So where do we sit? Well, we definitely believe feedback to be really important, however, I am a bit uncomfortable with some of the labels that are banded around at this end of the spectrum, labels such as “Customer Driven” or “Customer Obsessed”.

In my opinion, “Customer-driven” sounds to me like the customer is in charge of the ship and we have no clear direction, we are just reactionary. As for “Customer Obsessed”, this just quite frankly sounds creepy (we are not spying from the bushes or dressing to look like you).

How we work

Labels aside, we like to think our actions prove that we take our customer’s opinions seriously. In our recent releases, we have added a number of functions to help our customer’s do more for themselves, especially around dealing with customer service issues. All of these changes we made were heavily influenced by customer feedback.

In case you missed it, here are the highlights of what we have released:

  • Query orders to get more detail on the order and status
  • Ability to check each code’s current balance
  • Links to Retailer’s support details
  • Setting your own reporting emails
  • Cancel orders from within the Hub

What we didn’t do though, is blindly implement exactly what was requested. That may have been easier in the short-term of course but would not have provided the same value. Had we done this, we would have done a disservice to the person giving the feedback. When they took time out of their busy day to give this feedback they would certainly not have been under the impression that they were now responsible for designing a solution that would affect all our users. They were just trying to help out by highlighting their own needs and observations.

Instead, we took the feedback and delved much deeper to try and get to the real problem that needed addressing.

A real life example

Balance checking is a great example of our problem-solving process. We were getting a huge amount of feedback from our Partners asking for us to display the actual card numbers in our Hub. Now we have always steered away from this for security reasons but with so much feedback we had to give this issue some consideration. We assumed that this must be for reporting or reconciliation purposes. The assumption seemed sound and the simple fix would have been to take these requests at face value and simply add the card numbers to the Hub.

Had we done this we could have sat back happy in the knowledge that we had done exactly what our customers had asked for. This is what I think of with the label of “Customer Driven”, the customer defines the solution and that is what gets built (this is just my opinion of course and I’m sure many companies that describe themselves this way don’t work like this).

“Our assumptions were completely wrong”

Our approach is less presumptuous! We went back to each customer and delved a little deeper into their requests. To our surprise, the conversations all played out pretty much like this:

Our assumptions were completely wrong. If we had just implemented card numbers in reporting we would have not solved the real problem or even got close to uncovering what it was. On top of that we would have compromised on security. The real problem was that our Partners needed to get the balance of a card.

In reviewing this feedback, we quickly came to the conclusion that if what is ultimately needed is to get the balance of a code, just providing the card number is not enough. We would still be sending them off to a retailer's website, just as they do today. This does not provide much-added value and is not a great experience either. A better experience would be to do the entire task for our users. So we came up with a solution to implement, on each transaction, a “check balance” button. We reduced a multi-step process down to a click of a button. An added bonus is that we still have not had to change our security approach of not showing the card number in the Hub!

Conclusion and Labels

In conclusion, if we had to give a label to our approach, I would use the term; “Customer informed”. This says to me that feedback is taken seriously and has an influence on what we put on our roadmap but we are still going to put in the hard work to understand the real issue. Only after having that understanding will we have a good chance of designing a solution that will really help our customers.

A big thank you to all our customers who regularly feedback their thoughts and suggestions to us, keep it coming!