Often, especially in BTB offerings, it makes a lot of sense to differentiate "customer" from "user." Take for example: the decision-maker who signs the deal and writes the check never actually uses the product, instead has staff which does so. Differentiating the customer from the user is very important in this context: you have to make and keep both happy. The customer will consider net impact to bottom line, high-level capabilities generally present in the market place, and the general temperature of the users before buying. They will expect that you have a certain list of capabilities which everyone else is selling them, even if their users will hardly, if ever, use that feature. The day-to-day users of the product, however, will have less abstract problems - they have real tasks to achieve every day, and will care much more about the specific capabilities and how they're implemented.
Sure, we could call them "decision-making" customer and "product-using" customer, but semantics driving psychology work the other way around as well : sales is customer-driven, and development and support are user-driven. Same end result is achieved, while using natural language for the target audience.
Sure, we could call them "decision-making" customer and "product-using" customer, but semantics driving psychology work the other way around as well : sales is customer-driven, and development and support are user-driven. Same end result is achieved, while using natural language for the target audience.