Jeffrey Phillips at Thinking Faster discusses the fact that product developers frequently forget that they are working from an aggregate, generalized, abstract "customer" when developing their products. The problem is that companies will sometimes (or, in my experience, frequently) fabricate this abstract customer out of thin air, making it about as useful for determining if your product will be successful as any other standard of evaluation that could be described as falling in the range of "fantasy" to "wishful thinking".
As an employee, go to your marketing people. Ask them what are the attributes of your customers. Ask them why the customers have the problem you're trying to solve for them, and how important it is for them to have it solved. Don't just ask them about the high-level generalizations, ask about specific items you're adding to the product. Have them show you the hard data. If they can't, better evaluate if your company is producing a solution in search of a problem or unnecessarily spending money to produce something that exceeds the basic requirements. Determine if this information has been conveyed to the management of the product development teams. If not, you're probably working for a company that can not scope down a project to the most effective essentials to solve the problem, opening the door for a more efficient and effective competitor.
One of the commenters mentioned that Unilever in India has a policy that you can't participate in a discussion about customers if you haven't spent some minimum time interacting with customers (and Mr. Phillips made a statement supporting the idea that everyone in the company interact with customers.) I'm not sure what he (the commenter) meant by "discussion about customers" unless he's referring to account managers or marketing people. Everyone else should be talking about problems. And having everyone dealing with problems interact with the customers is a bad idea, because it widens their focus from the targeted problem. If you're working on project X, don't even consider designing solution X' because it happens to address other issues the customers also have. Your architecture should be flexible enough that you can do easy additions, but considering those additions should not be on the product developers' radar at all. They didn't do the cost/effort->value analysis of the project, and are not in a position to accurately evaluate whether it is worth it to the company to do X'. Doing it anyway opens the door for competitors. Cultivating an environment in which scope creep is facilitated is dangerous.
- Do build abstract customers, but based on hard data.
- Validate all assumptions about that abstract customer that aren't directly stated. Identify the person in the company responsible for managing the "customer" definition.
- Don't go overboard with customer interaction ... marketing, business analysts, architects, and project managers to the extent that they need to address specific issues of the specific problem being addressed.
- A product that provides slightly more for a slightly higher price may price itself out of the market if all people want is slightly less at slightly cheaper.
- Ask the questions. Protect yourself.