I have observed a pattern that companies large enough to develop internal tooling institutionalize a vocabulary that evokes the impression of a supplier-customer relationship between the teams building these internal tools and the teams using them. I would argue that saying “the customers request a feature” when talking about internal users does more harm than good by misclassifying the nature of the interaction.
The positive aspect of this wording is that it underlines the seriousness of the request. Just because the person asking is your peer, that does not mean their request is any less important. I acknowledge that there is some value in adopting this vocabulary as it counteracts a we-know-it-better mentality. After all, if a request came from a customer, it must have some merit!
Nevertheless, I think the problems with this language weigh heavier than the benefits as the relationship you have with a colleague in a different part of the company is quite different from that with an external customer. Mislabeling it hides both opportunities and challenges.
Firstly, when interacting with a colleague, you can at any point interact without any formalities required. It suffices to write a message, start a call, or, if you happen to be collocated, dropping by their desk. When interacting with a customer, there are more formalities to respect as the organization tries to keep its external presentation consistent. Furthermore, you might simply not have the same communication channels available, and finding the best person to contact is usually more complicated. External customers may not be able to freely share with you what their business priorities are. With internal teams, this information is more readily available.
All of these are huge advantages that internal product teams have at their disposal: They can much more easily get an understanding of the exact problems that need solving and spot opportunities. Labeling the other party as a customer suggests the same practices used with external parties, causing this benefit to be lost.
Two internal teams can even collaborate on the same code through inner source practices. Using the word “customer” implies that only one party can actively contribute.
Secondly, when dealing with a real external customer, you typically would like them to keep using your product to secure the revenue stream. With internal users, ideally, your incentives should be aligned and if the other team would be better served with a different tool that is not developed in-house, you would want to advise them against the in-house tool.
Using the metaphor of a customer-supplier relationship also suggests the existence of sales activities even if this is not always in the overall interest of the organization.
Thirdly, budgeting does not work the same way. Allocating a budget for an external vendor is a clear line item whereas in the case of an internal team, costs are hidden in all kinds of activities, even if you try to balance it out through internal budget transfers. By using the same word for both you evoke the impression that these transactions are easily comparable on a balance sheet even though they are not.
Lastly, procurement and vendor selection does not work the same way when it comes to in-house tooling. The metaphor evokes the impression that a department could simply select a different vendor that better fits their needs if they wanted to. In practice, rejecting the internal tooling will turn out to be difficult. This is in part because there is a reason why the internal tools were developed in the first place (the alternatives are probably lacking in some dimension), in part because as mentioned above, budgeting works differently (even if a department would select a different vendor, the organization still pays the fixed costs for the internal tools) but also because the political dimension will be more present in this decision.
This is not necessarily a bad thing: Using an internal tool even if it turns out to be technically inferior to available alternatives can also have a strategic value as you amortize an investment which at the same time becomes part of your intellectual property.
In conclusion, a more neutral word like “users” is probably better when referring to the team benefiting from your internal efforts. Though, I would even take it one step further and try to label the teams that use your services by the problem they try to solve with your tool. For example “the e-commerce teams” or “the data analytics teams”. This underlines the role you play in the value stream, something that sometimes get a bit lost with internal services.
The Solution Space 