There are three pieces. For most products, you'll need to do all of them:

1. Use the product yourself. For consumer products this is usually easier than for B2B products. But even for products where you're not the customer, invent reasons to use it. You can't get really good product knowledge without, duh, using the product. One good way to use the product is to serve (officially or unofficially) as a support engineer for the product, because you're forced to use the product, if only to understand the problem that the customer is talking about. Even as the VP Product at a software company, I still get multiple "support" issues per week that are escalated to me from large customers or our internal support experts. Chasing down those problems is a great forcing function to learn a lot about the nooks and crannies of our products.

2. Hang out with your product's customers while they're using the product. Watch them use it. Watch how they use it. Ask why they're doing things. And why they're not doing things you'd expect them to be doing. Ask about their daily tasks and how the product fits into those tasks. Really try to see your product through their eyes and in context of their daily habits and practices. Formal usability testing and focus groups are a more structured variation of this technique-- they're more structured ways of watching a customer use the product and/or talk about the product. But don't get intimidated if you don't have the budget or time for those things. Just find yourself some customers and hang out with them!

3. Try to extrapolate #1 and #2 to a representative sample. You can't meet every customer or use every feature like a pro. So lots of product rookies fall into the trap of thinking that the most important customer is the last one you talked with, and the most important feature is the one that they just asked for. So it's important, especially for products with many users, to develop a quantitatively-informed prioritization of both your customers (which customers are more important to your business) and your features (including the use-cases that you don't have features for yet). For an enterprise product with a few hundred customers, you can often build this quantitative sense by visiting a large percentage of your customers. For a consumer product or a very large-scale B2B product, you'll need data beyond simply meeting customers in person. Hopefully your software product has quantitative data available (logs, instrumentation, web/mobile analytics, surveys, UserVoice and other feedback tools, etc.) that can inform your prioritization. Unless you're at Google/Facebook scale, don't get too math-obsessed here-- quantitative data is usually best at validating and prioritizing ideas that you get from real 1:1 contact with the product and/or its users. Don't depend on data to tell you what to do with your product. Instead, depend on the data to validate/invalidate and prioritize your ideas that come from real-world, 1:1 experience with your product and your customers.