As a product manager, your job is to identify problems to solve, do some prioritization, and ensure that you solve them as fully as possible, given the resources and constraints of your organization. (To be super explicit: the best solutions aren't necessarily delivered as new features.)
In enterprise product management, you often have multiple constituencies that you need to solve for. Attention must be paid to all of them to keep both customers and the team happy. In my mind, when you're choosing problems to work on, you should be explicit about whose problem you're solving. I use the term "beneficiary" to denote for whom or for what I'm solving for. Here are the most common beneficiaries:
* The user.
The user is an individual human. In consumer, the user is the customer and is the only thing that matters. In enterprise, there are often many different kinds of users - some users aren't even end users of your product: they're administrators or finance folks. Even within end users, there can be many different kinds of users. Some delineations are: novice and expert users of your product, end users with different job roles or responsibilities, or folks in different geographies that have different contexts and capabilities (iOS versus Android, slow connections versus fast connections, etc.)
If you have different kinds of end users, the best way to have a quick way to be specific about who you're solving for is to go through a persona exercise. Individual (and team) personas can be incredibly helpful to make sure that you can shorthand a set of motivations, problems, capabilities, and limitations for end users.
* The customer.
Again, in consumer, the user is the customer - the person who pays. In enterprise, the customer can be one of many folks: an IC putting down a credit card, a manager authorizing a purchase, a procurement department that will "right size" the offering to be bought.
At scale, if the person paying isn't the person using the product, you're going to have to do affirmative work to prove to the purse-strings-holder that you're delivering value commensurate with the price being paid. Fun note: this work often helps lead to step-function expansions in deal size.
* The system.
Sometimes you're going to solve a problem that makes your system more reliable, available, resilient, or performant. For example, work that makes it easier to scale (either horizontally or vertically, your choice) or lets you increase placement (standing up an EU region is the most common example for US-based startups targeting EU-based customers) has "the system" as the beneficiary. To draw a line in the sand, this work will have no user-facing changes in the experience of a working application (with the exception of decreasing latency). Solving for the system is also different than solving for...
* The team.
Sometimes you will solve a problem that is borne by your internal team - perhaps your developers, your sales team, your support team, or any collection of groups of folks inside the organization. Solutions often end up automating manual processes or making it easier to make changes to the product. Solutions can include everything from new ticketing systems, string repositories, cron jobs, documentation, full on code reorganizations, and just hiring a bunch more people.
* The business.
Lastly, problems that are borne by the business are generally problems where the outcome is either "increase revenue" or "reduce costs". These are where the value you are creating is almost entirely captured by the business that offers the solution. Being intentional about pricing and packaging helps immensely on the revenue side; sadly, there are often no real alternatives to large infrastructure projects to make reductions on the cost of goods sold (COGS) side.
You may also find that there are other classes of beneficiaries that your organization needs to consider - that's fine! Being clear and up front about which beneficiaries you are serving will allow you to make much better prioritization and sizing decisions as a product lead.