How to leverage customer feedback to build great products

My name is Daniel Shimoni, and this article is a step-by-step guide for leveraging customer feedback in order to create great products. Obviously, this is a pretty loaded subject, but don’t worry! I’m going to break it down into a few easy-to-digest talking points.

The main talking points include:

But before we dig into the main subjects of this article, let me give you a little bit more background info on me and my journey to product!

About me & Lusha

I lead Lusha's customer-facing products as Head of Product. Lusha is a B2B sales insights and intelligence company.

We're a product-led company, which means so many of the challenges we deal with require close communication with our customers. We're constantly learning from our customers by paying attention to their evolving needs!

Before working with Lusha, I worked as a product marketing manager at the hospitality startup Selena. At Selena, I ran the company's websites and apps backlog and was in charge of their conversion rate optimization efforts.

Before working at Selen, I co-founded my own startup in the field of content management. Working on my own startup has definitely been one of the most significant experiences for me when it comes to learning to build new products. It's helped me experience many different aspects of building products.

To be and what not to be!

Hopefully, you’re reading this because you want to learn how to build great products. I’m sure as product experts you understand that maintaining a continuous feedback loop with users is a crucial part of building great products.

If there’s one crucial thing you take away from this article, I hope it’s this: don’t be that person. 👇

In the search bar, it says, ”what I want to be true.” I've noticed that many people who conduct calls with customers tend to be so convinced of what they want to build that they distort what people tell them. They do this to fit a certain narrative in their mind.

This leads to making poor business decisions, and just isn’t an effective way to engage with customers!

In this case, the calls with the customers are almost a formality. The customers are not collaborators in the making of the product. If anything, they’re treated as obstacles because they’re telling the researcher stuff he doesn’t want to hear.

Okay, so I’ll hold my hand up. I’ve been guilty of this too. The reality is, we’ve probably all been guilty of this. That’s ok as long as we’re able to confront past mistakes, challenge ideas, and do better in the future.

Fundamental truths

Throughout my journey in product, I've learned that there are fundamental truths.

Talking with users is the single most important thing

This is the single most important thing to do when you're building a product. With every great product, customer feedback is at the root of it. You simply can't build a product without gaining insight into your users’ pain points:

Is this something that they need?
Does it address a problem that they have?
Does it fit in with your customer’s life?

In many ways, customer feedback is product discovery. This has been a bit of a buzzphrase in recent years.

You must be willing to go deep

It's not just about speaking with customers, it's about being really thorough when you're validating your ideas. If you arrive at a customer call with a list of generic questions that you're just trying to check off the list, you end up building uninspiring products.

We want to get to the point where we’re building a two-way relationship with customers. Think of them as collaborators. Any relationship is a discovery process. You’re getting them on board as your design partners who can give you live feedback as you're working on your product.

Speaking with users is a skill every PM must master

There really is no other way around it. If you're not confident in your ability to speak with users, you really should work on that skill. It's essential for building great products. You're missing out on a lot of opportunities to learn what your users truly need!

Another important distinction is that it's not simply about talking with users, it's about talking with the right users. But how do you find the right users?

Find the right users to speak with

I think that there are three really accessible sources or ways that you can find these users.

Usage data

This is essentially looking at how your existing users are engaging with your product. Those users are absolutely crucial for what you’re trying to learn and you should be scheduling calls and sending emails back and forth with them.

Not everyone will be able to jump on a call with you, but even if you reach out to 100 users and you have 20 people schedule a call with you, this can make a world of difference.

Product triggers

You want to think about creating triggers within the product that will prompt people to jump on a call t whenever they're engaging with your product. This could be as simple as creating a chat prompt whenever anyone presses a certain button. It could be a calendar link that allows them to schedule a call with you instantly.

All of this should be very focused on what you’re trying to learn specifically.

Sales/CS

Many product people don't really think sales have anything to do with them. Big mistake! Sales can direct relevant users to you. Sales and Customer Success teams are always on the front line, speaking with customers and interacting with them.

Another thing to think about is:

What is the purpose of me speaking to CS or Sales?
What am I trying to learn?
What are the products that I’m trying to gather more info on?
Are looking to build features?

These kinds of questions are essential to ask, especially when you’re dealing with bigger accounts that might have many users. Now, customers are not always going to want to jump on a call from the kindness of their heart, you might need to provide users with an incentive to jump on a call with you.

But you'll be amazed by how many people will still jump on a call simply because they are interested in what you're trying to do. Believe it or not, there are a lot of genuinely helpful people out there. And these are the kind of people you want to be evangelists for your product.

Arriving prepared for a feedback call

Okay, so you’ve highlighted the right users, but you’ve still got to prepare for that call! Firstly, it’s really important to understand that this is a process of continuous refinement, and you should start off by examining user data.

Examining user data

If you're trying to build a product, you want to be really specific in what you’re asking users about. In any circumstance, it starts with data.

This might be something you've learned from your competitors, a feature request, for example. Or, it might be something you’re just curious about and you're trying to gather data to see if It’s worth pursuing.

Or, this could be data for something that already exists in your product. In any event, the next step is to…

Develop a hypothesis, but be prepared to challenge it

Everything that you do needs to be based on this hypothesis. And it needs to be a discovery! Every time you’re speaking with users, you're learning more things, you're getting more data. Also, you need to be prepared to adapt. What you’re learning might not necessarily square with your origins hypothesis.

That’s why it’s essential to refine your learning. Make sure that when you're speaking with more users, you’re staying open to new insight. Rember, the key part of this is to challenge your preconceived ideas.

You might learn, for example, that this new feature request you were exploring is not relevant to user needs at all. In which case, that’s when you need to be prepared to revise your original request.

When you’re gathering your new information, are you doing the following?

Challenging your original question. Often your hypothesis comes in the form of a question
Refine your question. Are you taking your new data into account?
Are you adapting your question to users based on what you’re learning?
Make sure that the next call you make is much more in tune with what you've learned previously.

Conducting the call

This Is a very challenging process, but once you master it, it’s something you’re really going to enjoy doing. But don’t enter into it lightly! There are several steps you need to make before you enter into a call.

Never go solo

Remember Han Solo? The lone rebel who sweeps in and saves the day! Well, in this instance, yeah, don’t be like him. Have at least one person joining you on the call. My ideal setup would be:

Product manager
Designer
Engineering team leader
Product analyst

One reason is that it gives you a very broad perspective on the different things that you might want to learn about the product.

It gives you different viewpoints and angles about how easy or challenging it might be to develop a solution for this. What resources do you have available to you already? Just make sure you don’t jump on a call by yourself.

Set a container

By setting containers you are setting guidelines and coming to agreements with the person you're talking with and making sure that you're on the same page. There are some key steps to make when it comes to setting a container.

Tell the person who you are, and who your team members are.
Share with the user what you're aiming to learn.
Be clear with the user how long this call is going to take.
Ask the user if you think the call will take longer
Ask for permission to record the call. It’s just a respectful thing to do.
Finally, ask them for permission to stay in touch after you've conducted a call with them.

This is all part of the container. Each step is essential.

Ask open-ended questions

The thing is if you just ask yes and no questions, you will get very flat answers in response. So you need to ask them questions that allow them to express themselves very vividly. You shouldn't focus on asking users to explain to you how they're trying to do something, and why something isn't clear to them.

It’s all about making sure that you focus on allowing them to be as vivid as possible. This is a huge factor in finding things that can be helpful for you when you're building a product.

How do they do it today?

Ask them to share the screen. Take advantage of modern tech. You don’t just have to take their word for it, you can actively see what they’re struggling with and be a guiding hand to them along the path.

Maybe they're using your product in a completely old-fashioned way. This could provide real insight into how you can build great products for the future.

Build a relationship

This is more something you should aim for when you’ve done everything right so far. You’re aiming to build a relationship with your users.

Remember that I said we needed to create a continuous feedback loop? You want to make long-term collaborators out of your users. You want them to be design partners, an integral part of your organization.

If they care about what you're trying to do, they might even reach out to you by themselves, which is not an obvious thing. Customers want to feel they’re a valued part of your company.

The correct mindset

The correct mindset is really accepting the evidence that might suggest you're wrong. I know this might seem counterintuitive at first. But if you're looking for evidence that you're wrong, and instead what you're finding is evidence that you're right, it’s really gonna give you a big confidence boost. 💪

Building a direct product helps you prevent a situation where you are wasting time building things nobody cares for. Adopting this mindset is something that I think I picked up when I was building my own product.

It served me very well. It really helped me avoid some big mistakes. And I still do it today. It's just a great, great tool. If there's one thing I really hope any of you will take out of this is to adopt this mindset.

Use customer feedback

User feedback is leveraged throughout the entire process. You need to make sure that your approach is tuned in such a way that you can make the most of the customers that you're speaking with.

Before you build the product

Your focus is on validating your idea. But before you even validate your idea, you need to ask yourself:

Are you solving a problem that people care about?
Is this a problem worth solving?
Are we heading towards the correct solution?
Are we solving this problem in the correct way?

There are many great resources about how to validate an idea. But the biggest thing to learn to do is to make sure that the problem is worth solving. The biggest cue for you when you're trying to learn if a problem is worth solving is to listen to what users really hate.

A strong signal that there's a problem worth solving is the language people use to describe it. This is not something they will necessarily tell you about specifically, it's something you can infer from the language that they use about the process or an action that they take.

This is something that dramatically increases your chances of having a successful relationship in the future.

During the process

During the development stage of a product, your focus should be on course correction. If you find out you’re headed in the right direction, will you be able to right the ship and pivot into the right direction immediately? The simple question that we still want to answer is, are we building the right product?

At this point, you probably have a very functional version of your product. If you've successfully developed a community of design partners, then you have people who can give you very valuable feedback that will give you the reassurance that you're headed in the right direction and that you are getting close to a point where you can launch it.

It will also allow you to see things you might have missed and let you fix issues before you show the product to the entire user base. You don't want to launch a product that your entire user base thinks is completely off the mark.

After the process

Once you are done developing the product and you've launched it, your focus should be on optimizing it. You really need to ask yourself some tough questions, such as, is this product meeting its business objectives? And if not, what can you do to improve it?

At this stage, you need to be very pragmatic and honest about whether or not your product is meeting its objectives. Obviously, there's some gray area here. There isn’t really an objective set of criteria for how well your product is doing.

But the reality is, it typically goes in two different ways.

Scenario 1: you’re on course to meet your KPIs. This doesn’t necessarily mean it’s a huge hit from day one. Okay, so you’ve launched it, and it looks good. All done? Not quite. You need to make sure things are staying positive.

Scenario 2: You’ve launched a product but there's just no engagement from some users There's not as many as you thought. And now you sort of need to figure out what's happening. This can really be thought of as a damage control step.

After you've launched, you need to go into researcher mode to figure out why it maybe isn’t performing as you’d hoped. Speak with as many users as possible to figure out why people aren't going all the way with it. What's missing? What can be improved?

Maybe people are not even aware of the product. In that case, you need to understand why there is a lack of awareness in your product. What’s going wrong with the positioning of your product?

User feedback = source of truth

Okay, so we’ve come full circle. I’m going to leave you with this final nugget of wisdom. In my opinion, this is the root of every great product. Speaking with customers simply brings the data to life. It completes the story.

Our customers are the hero in this story, and what’s a great adventure story without a hero? We're not building products for our computers, we're not building products for ourselves. We’re not the protagonist of this story. The users are.

Use the data you speak with a customer in detail about what your product makes them feel. This is really not a new concept, this is something that is at the root of every great product I mentioned.

The better you become at speaking with users, the better you will become at solving problems.