How do you define between a customer(s) want or request and a feature that is actually needed?

If it's something that's truly needed, you will see many customers asking for the same thing. You can validate this by speaking to other customers or running a survey to assess business needs. Sometimes when you dig a bit deeper, you discover that they have a pain point that could be solved a completely different / better way, so I wouldn't always take what they say at face value. Additionally, if it's critical to their business, you will also see customers churning to competitors who do offer it. You would also see sales not win certain deals because of it. It would also be fruitful to start talking to your Sales and CS teams.

I'd say this is a volume game where you have to look for patterns while also thinking about your growth model and ideal customer profile. Given these data points you might find that out of the list of feature requests, a handful are commonly requested and and even smaller subset are commonly requested by your most valuable customers. Focusing on these will not only help your current customers but help you win future deals as well. 

Another valuable thing to consider here is buidling a developer offering for your customer base. At the end of the day, your PM/Eng team only has so much time to create new features; so if you augmented your teams ability to build the most valuable features by enabling your customers to build the long-tail use cases that may be specific to their own orgs via API--then you can end up with the best of both worlds: You take customer feedback, you build high impact features that will support many customers, but for the features that you cant get to on your own, your customers still have a path to solving. 

Of course another dimension if you should build a feature or not would be cost. You'd obviously want to anchor on high impact low cost features to build, while being selective on high impact, high cost and enabling customers themselves to build low impact, low cost and low impact, high cost features themselves. 

Repeatability. 

Customers are asking for a feature because they believe the need it. Nobody has time to invent frivolous features for companies they don't work for. As a result, there's always an element of truth to every request.

The trick to determine whether you should add a capability to your roadmap most frequently comes down to, "how many other companies would benefit from this feature?" If it's a one-off, you still have to value that one-off. But if it's something that's broadly applicable to a segment or industry, it's definitely worth it. 

My first thought is: Have you asked your PM this exact question? ;) In my experience, balancing customer wants and needs is typically handled by the PM, while PMM supports recommendations based on market and customer intelligence.

How we handle this is by answering a handful of questions:

1. What is the customer trying to do?
2. What’s the best way to help the customer achieve this (based on time, money, resources, experience, etc.)?
3. Can we help the customer do it better, faster, and/or cheaper?
4. What are the economics of creating the feature? (This is actually many questions in one. ;) I would start with trying to uncover these questions: How much would it cost us to build it? How much would it cost us to NOT build it? What is the feature worth in future dollars?)
5. Does the feature request align with who we are as a company and the core problem that we set out to solve?

Those questions should be part of a working discussion with your PM.