The distinction is largely irrelevant from an agile perspective, but may have other drivers that require you to evaluate and adapt your process. If you must do so, involve the entire agile team.
Analysis and Recommendations
- Is something a feature only if it's customer facing?
- Does a non-customer facing internal update count as a feature too?
A "feature" is simply some functionality or behavior of a product or system. From a marketing perspective, features are often differentiators that are only called out when they reach a meaningful threshold of significance to the user or differentiation from competitors. From a project management perspective, though, a feature is simply a shippable increment of functionality.
So, it doesn't matter if an increment is customer-facing or not. All sorts of development work takes place "under the hood," and most customers don't care about internal implementation details. However, that doesn't mean implementation details don't add value, affect system behavior, or improve the product!
With all that in mind, it sounds like your project team is struggling to differentiate between functional and non-functional requirements. In an agile sense, both are features, but the priority and business value of the features may vary based on how the Product Owner views the return-on-investment of project resources (especially time, money, and labor) for each feature.
Your best bet is to work with the Product Owner to understand if you need to make this distinction for the project. If not, forget about it! If you do need to distinguish between these concepts for contractual, political, or other business reasons, then involve the whole agile team to discuss the best way to incorporate that into your process.