A customer is whoever decides to acquire the product. A user is whoever has to live with it afterwards. In consumer products they are usually the same person. In almost everything else they are not, and a product owner who conflates them will keep being surprised by adoption numbers that do not match sales numbers.
Approaches to segmenting
By job to be done. Group people by the progress they are trying to make, not by who they are. Two people in different industries who both need to reconcile invoices before a month end are in the same segment for your purposes.
By behaviour in the product. Group by what people actually do, such as frequency, depth of use, or which path they take through a workflow. This is observable rather than reported, which is its main advantage.
By role in the buying decision. Economic buyer, technical evaluator, end user, and the person who has to approve the change. Each has a different question and each can stop the purchase.
By context of use. Same job, different environment. A field engineer with intermittent signal and an office user on a fixed desk need different things from the same feature.
Whichever approach is used, a segment is only useful if it changes a decision. If two segments would produce the same ordered backlog, they are one segment.
Handling conflicting needs
Conflict between segments is the normal case, not an exception, and the useful technique has three moves.
First, state the conflict in terms of the underlying need rather than the requested solution. Two requests that look incompatible often turn out to be one need with two guesses attached.
Second, check the conflict against the Product Goal. The goal already says who the product is currently for. If the goal cannot settle it, the goal is too vague, and that is the more valuable thing to have found out.
Third, decide and record the decision where the losing segment can see it. A visible ordered backlog does this by itself. The point is not that everyone agrees, it is that nobody has to guess.
Connecting developers to customers and users
The objectives ask for at least three approaches, and these are the ones that survive contact with a real schedule.
Developers attend the interviews. Not as note takers, as a second listener. The questions a developer asks are different from the questions a product owner asks, and cheaper to answer in the room than in a ticket.
Direct observation of real work. Watching someone use the product, or use the spreadsheet the product is supposed to replace, produces detail that no written requirement carries.
Developers at the sprint review. Stakeholders and users inspecting the increment with the people who built it removes one layer of translation.
Support and usage data made available, not summarised. Raw tickets and session recordings are more useful than a monthly digest, because the developer notices things the summariser filtered out.
The product owner is accountable for value, not for being the only channel to the market. A product owner who becomes the single point of contact with users has created a bottleneck and a game of telephone at the same time.