The Customer is Not Always Right: A SAAS NORTH Story

Hannah Chaplin, previously CEO & co-founder at Receptive (acquired by Pendo) presented a talk at SaaS North 2018. Below is a transcript of the talk. You can see Hannah and Eric Boduch (Pendo co-founder) on the main stage at this year’s SAAS NORTH in Ottawa.

In all the years I’ve been involved in producing software and SaaS products, customer feedback is still a really hot topic and one on which you still see lot of conflicting advice – some people are real advocates for the VoC in product development while others prefer to really own the product roadmap and keep customers well out of the way.

So we are going to explore the topic of customer and the feedback they give you on your SaaS product under the heading “The Customer is NOT always right”.

First, a bit of background for you. Customer feedback really became important for me in my first SaaS business.

Previous to that I’d run a development agency shipping technical projects for major brands. We’d take a project on, spec it, then deliver it to the customer so there was never that ongoing dialogue and feedback loop that you have when you are building a Software-as-a-Service business.

Even further back, I’d be staying up late, shipping CD-ROMs with the latest version of whatever software we were building at the time. But when I started a SaaS business, the way we interacted with customers and responded to their product feedback had to change and this is the story for a lot of technology businesses operating today.

A lot of companies now ship weekly. Even large, Enterprise organizations are able to do that and are generally much more agile on the whole. Customers demand to be heard and if you’re a serious SaaS company, you HAVE to be listening – it’s what users now expect. Product feedback has become an important part of the experience we are giving to our users.

Needless to say, when my first SaaS business came along, an awful lot of lessons were learned. There are a couple of situations that really stuck with me.

We were selling to SMEs and receiving a large amount of feature requests so could very often end up building the features that we had heard the most – which didn’t always work well.

It took a little while to recognise that a free triallers, small accounts ,and large accounts, all have very different demands on your product so you can’t look at customer feature requests in one big lump / all muddled together.

The other major lessons gave us the saying “Watch out for whales”.

I have no idea if that’s a common saying or if it’s something we just made up. We landed a large customer – a Canadian company actually! – and they were our biggest account by a long way.

As a result we started to get pulled around by their feature requests and eventually we lost them. The product was set up for SMEs and they were a stretch too far, we simply weren’t ready to resource a customer of that size and we weren’t charging them enough to give them what they needed.

From that experience I learned that.

1. That the customer is NOT always right and that you shouldn’t jump on every request you receive, and
2. That, despite that, the Voice of the Customer is, in fact, intrinsic to the success of every good SaaS business.

The Voice of the Customer can be tricky to incorporate into your product development so I’m going to talk you through how to set-up your business to welcome customer feedback and dispel some of the common fears around taking feedback on board. I’ll also explain why saying “yes” to feature requests doesn’t actually make anyone happy.

And all the way through I’ll bring some real examples in and best practices. I’d love for you to take something practical away from this and put it to good use in your own businesses. And I want to hear from you too – I’ll talk these things through for the next 15/20 minutes then I would love to hear your experience and answer any questions that you might have for me too.

Do customers hamper innovation? This is a real fear that a lot of us have.

Some people believe they do. You meet a lot of founders and product managers who have this vision and have already dreamed up how they think a piece of software should work and they just get building.

And that’s great, you need a vision and a reason for being and you know that better than anybody. That’s very motivational for anyone you work with and customers too… but it can be dangerous too because you’re not validating market demand as you go.

The best thing me and my co-founder, Dan Dukeson, did when we started Receptive was to spend 4-6 months purely on customer development. We’d built a prototype to solve an issue we had in our business but we had also learned that we aren’t the market.

A great book called The Mom Test helped us to design great, open-ended questions to ask. And through this process we learned whether there was a market for our product, which personas and size of company we could sell to, and, most importantly, we came out of the other side of the customer development with a much bigger and more exciting vision for out business than we had at the start.

We could only learn that through interacting with others and this is the same with customer feedback. You can be a great team and bring the VoC into your development without hampering innovation – more on this shortly!

The take-away is that it’s really important to recognize where the Voice of the Customer fits in to your process and what is brings to your SaaS product but also that…

…listening to customer demand absolutely does not mean building everything they ask for!

I’m sure there will be some Simpsons fans in the room and I think Homer’s car is a great example of this.

There’s an episode where he (as an ideal customer – “the average American man”) is left to create a car and it ends up completely mad and very impractical. He pitches it as “powerful like a gorilla yet soft and yielding like a Nerf ball” but when the car is revealed everyone thinks it’s an overpriced monstrosity.

And that’s what a lot of us fear with our software product – that listening to users means we can end up with Homer’s car or one that’s just a copycat of every other product in your market.

You can absolutely innovate but you can do it in a way that brings the voice of the right customers along with you.

These are the ways you can use the customer voice:

1. Improvements to what you already have. You can involve the customers during development but also AFTERWARDS too. Customers are exceptional at knowing how to color in the circle. You can’t be every user and they bring a lot to the situation for you.
2. Asking for use cases and pain points when you already have an item on your roadmap. Even if you have a product roadmap in place for the next 2 years, remember to bring the customer along with you. It keeps them excited and involved in what you are doing and it empowers your teams to build good solutions to customer problems. Feedback doesn’t end when a suggestion is made. It’s the starting point and the beginning of a conversation.
3. And remember that customer feedback is a huge opportunity for you. Staying close to the customer is a big competitive advantage especially since customers will be familiar with other software in your space – understanding what the competition is doing helps a lot in the sales and the marketing and helps you to know where you fit. Being close to your ideal customer allows you to tell a very compelling story – even if you have a very similar feature set. You can be a market leader by offering a great customer experience and product feedback is part of that.

In summary of the first section…

The best companies really do LISTEN to their customers because they have a unique view of the product. They can bring so much to you so start treating them like they are on the same team because you are!

You can (and should!) have a strong vision, you should design the solutions, BUT at the same time, make sure you understand your customers too.

There’s 3 simple steps you can take to help your organisation make the most of the product feedback you receive from your users. And setting your feedback process up in this way also helps you say “no” to requests that don’t align with your business strategy.

There are 3 things you can do today which will help you a great deal and they don’t take much time or effort to put in place.

1. Give people a central place to submit requests so you are building a feedback library.
2. Get the information you need, when the request is made (pain points).
3. Ensure the product team reviews the information regularly so you can communicate back to customers and team members easily.

First up, build a feedback library and not a backlog of feature requests.

Traditionally in SaaS development, we have a concept of a feature request or ideas backlog which sounds pretty miserable to be honest.

In fact the very definition of a backlog is “An accumulation, especially of unfinished work or unfilled orders.” This suggests you are constantly battling a growing list of features and ideas that need to be done but that you haven’t yet.

We need to change that mindset to develop the best possible SaaS product. I think the product management community need to ditch this idea completely. It’s a horrible concept and not very helpful for you OR your customers.

Instead of a backlog of unfinished work and tasks to be done, see your product feedback as a library.

You can build a library, share what you are working on and then go and access the right information at the time that you need it. Make sure all of your product feedback is going into this library to that your customer success and product teams know where to access the information and where to store it when they receive it – which they inevitably do…probably every day.

For example, if you are working on a redesign project, the feedback you will have received over time will be relevant regardless of when it was submitted. We regularly come back to requests in Receptive when a project lands on our product roadmap – we look at what use cases we have for customers, from our teams and from prospects too. This helps us understand what we need to improve then we are empowered to designed a great solution that works for our customers and our business too.

Step 2 – make sure you are filling your product library with helpful information.

I was recently talking to a friend about this and their experience is a great story for how we should be approaching building SaaS too.

Ian runs a company called 3edges who specialize in workplace performance – so how where you work impact the performance of a business.

They were finding that when you talk to people about what they need in their workplace to be successful and productive, everyone would talk about physical things – essentially the equivalent of software feature requests.

They would say “I want my own office”, “we need 10 chairs”, “I want a coffee machine”. Ian and his team created this really cool briefcase that they use to facilitate discussions. They found that by moving the conversation away from physical items needed in an office to a conversation around needs, and pain points, they were able to design really effective workspaces that work for every persona.

The architects and experts were empowered to design great solutions when they truly understood their customer needs.

We need to do the same with our SaaS products. You might have a separate channel where customers can give you feedback ongoing, or you might reach out for feedback to enhance what you are already building or to get more ideas of how you can help your existing users.

The key is to ask the right questions just as Ian and his team do. Instead of “What feature do you want?”, ask things like “What are you trying to achieve?”, “What is your workaround?”, “How often do you need this and what’s the impact?”.

This gives you a really powerful data set and most importantly it actually empowers your product teams. Instead of saying here’s a backlog of features, you are saying here’s a library of use cases you can use to design solutions that not only work for your customers, but work for the business too. This is really cool stuff especially when you start assigning other relevant value metrics to the feedback too like MRR, location, job role, and priority.

We have a feedback channel separate from support that our customers use to give us feedback and our form allows us to ask these sorts of questions. Just recently we’ve had 2 examples of how useful this is. Our Intercom integration sounds like a simple feature on the surface but when we looked at the use cases, we couldn’t believe how different they were. So, now we are taking the use cases, involving customers, and designing iteration 1 of the integration in a way that makes the most sense.

A second example was internationalization – Receptive in different languages. Again this sounded simple but it meant very different things to different people. Without the context and voice of the customers, we wouldn’t have been able to develop a solution that was effective.

To make the library work for you and your customers, I highly recommend getting a product feedback policy in place. It’s a bit like a Support Level Agreement (SLA). Can you imagine running a support team without one!?

A Product Feedback Policy is a short document that you put on your help docs or on your website and it explains how you collect and use product feedback and how you communicate back to your customers with updates.

The main thing is that you are setting expectations – you are explaining that you gather product feedback, then use it to help develop the product. It stops teams and customers feeling like everything they send to you should be acted on immediately. Even if you only review new ideas from customers every 6 months, if you tell them, they know. If you add some transparency to the process, expectations are set and you can keep customers excited about what you DO have planned.

And to stress again, it really is easy to do. If you go to productfeedbackpolicy.com there is a free template and loads of examples.

So to recap, collect all your product feedback in one place and ensure you are building a library of use cases and not just a massive backlog of feature requests that have no context to them.

Once you are doing that, you need to use the data you are receiving to make great product decisions and communicate well.

Before you can use your product feedback, you need a strategy!

If you haven’t got a product or company strategy in place…then get one. You need a framework to check your product decisions against and your strategy is just that! It acts as the guiding light when you are looking at which feedback is the most relevant, and that in turn basically aids your teams’ decision-making, and this is vital because…

…not all product feedback is equal, and nor should it be.

Product feedback actually only ever comes from 3 places – customers, internal teams and the market (usually through the sales team). Different feedback from different voices simply becomes relevant at different times which is why seeing feedback as a library is much more productive.

And looking at this pie in more detail, we can see the reality of product feedback and what product and customer success teams are dealing with every day. You get feedback from many places and different user segments.

If you or the product team are saying “yes” to every request you receive, that’s when you get a Homer’s Car scenario with your SaaS product! It doesn’t make you happy, and it certainly doesn’t help your customers either.

So don’t have a knee jerk reaction to every piece of feedback. If you do you actually look out of control and that is not very reassuring for your users.

Have a strategy so you know which pieces of feedback are relevant to you right now and use this to your advantage. For example, if your strategy is to get more free triallers converted to paying users, look at feedback from free triallers.

Or if you are trying to close more Enterprise deals, look at what your current Enterprise customers are demanding from your product and also what prospects are saying too – you will very quickly see where your product and marketing materials can be improved to help you reach your goals.

The final point is that you shouldn’t forget to communicate back to your customers – it’s a big opportunity for you as a business to stand out. Most customer success and product teams are pestered for product updates on a daily basis so a little bit of communication can go a long way in building trust and keeping everyone on the same page.

In reality, a lot of SaaS companies fail at this part in the process. Customers contact you with feedback only to never hear back on where it went, was it used, was it relevant, what now?

There aren’t many opportunities for most of us to directly connect with their users – especially at large scale and experience matters a lot. It really does!

Feedback is your opportunity to give customers a great experience and ignoring them tells them a lot about how much you value them.

For most of us, the number of opportunities we get to directly connect with our customers reduces as we scale. Usually it’s through a support ticket or piece of product feedback and these opportunities are few and far between in a lot of cases – you need to seize this opportunity!!

Inspire confidence with a strong direction on product and communicate well because your customers will love you for it.

Here are some other practical things you can put in place to help add some transparency and communication and improve the experience your customers have with your organization:

1. Share a release log – get everything on there, not just things that customers have requested directly. You’ll always be working on things that your customers did not request, but these strategic projects and other pieces of work are actually something to shout about.
2. Have a roadmap – this can be really scary for a lot of people but it needn’t be. Show the direction and the problems you are working on. There’s no need to go into a ton of detail or even to have timescales on there – just show what you are up to and you will be surprised how well that helps keep the right customers around and good fit leads coming.
3. And finally, bring the voice of the customer into your development. Their experience of your product can be used to enhance your vision, your strategic projects and help you to develop features and product improvements that have a really positive impact.

In summary:

Create a Product Feedback Policy to set expectations and keep everyone aligned. Capture customer feedback in a library, know how your teams review and use the data and always, ALWAYS remember to communicate back to your customers.

To circle right back round to the start…

Of course the customer is not always right. Different voices will be relevant to your organization at different times depending on what you are working on.

And you are not always right either. It’s not being about right or wrong in this scenario in any case.

But if there’s one thing I want you to take away form this it’s that you and your customers are a great team.

You both experience your product differently and bring expertise to the party. You can’t be every customer but you can set up your organization to embrace customer use cases, bring their voice into your strategic projects, and then sit back and watch the magic happen.

Thanks for listening!