One of the personality traits that engineers often exhibit, and one that tends to drag projects down, is that they evaluate their projects using features as a benchmark of success. If their priorities were closer to the average customer it would be something like:

1. Core Functionality: does the product do what I need it to do -- or at least what I need it to do 80-90% of the time? Most projects have a very straightforward "critical path from initiation of a task to completion. The well-beaten path should be clear and efficient.
2. Reliability: Customers have zero tolerance for a product that they cannot rely on - especially if they plan to use it to make money. Reliability is usually the result of well-factored code and a competent server technician.
3. Clarity: Customers abhor "clever" design and distracting ornament. Most customers are in motion; every thing in a working design has to keep them in motion, not make them stop and chew through meaningless signals that overblown typography, florid color and "high gloss" design inflicts upon them.
4. Flexibility: Yes, there is a place for additional features. That place is fourth place. If you have a solid platform, you can look into additional features and generalized patterns.

As you add features do not do so slavishly: adding a feature for one customer is not a cash proposition unless you are playing in a very pricey, specialized market. Too many sales people will try and press the developers to swing a feature in that will help them close a single account -- take all feature requests in, but aggregate the feedback to focus on the features that the bulk of your audience will appreciate.

Specialization is your friend

Look for clumpings of features. If a set of features are only used by a well defined audience, consider creating a "custom" product for that subset. Believe it or not, clients are much happier with a product that is tuned and aimed at their specialty than they are with a product that is for a broad market and can be configured to suit their niche needs. From an engineers perspective, a configurable generalized tool is ideal; from your audiences' point of view, it speaks to a product that probably has overhead, features that will distract and slow them down because they don't apply to them, and is designed by a company that is not wholly invested in the needs of their industry.

Consider the HMV "Humvee". It is designed for the military but adapted to civillian use. Is it a better military vehicle than, say, an Abrams tank? I think most soldiers would rather be driving a tank than a HMV. Similarly -- is it an ideal civillian car? Getting past the fact that is makes you look like a douchebag, it gets crappy miles, is hard to park and takes up a lot of lane compared to just about anything, and really doesn't have features to compensate. It might be slightly safer than some vehicles but it offsets its safety value by being easier to wreck (as it clogs the lane and has visibility issues.) 

Now while its true that the HMV was not designed for two markets -- it kind of "fell in" to the civillian market by accident. However, you don't see tanks accidentally falling into the civillian market: they are specialized tools of war that have no place on the street; similarly, you don't see Priuses on the battlefield. The Prius, freed from any pretensions of battle-readiness, is pretty well optimized for civillian use, just as the tank fills its role perfectly.

Similarly, in developing software, you often discover after the fact that your product slips into various specialty markets. While maintaining a single platform may be simpler, if your market is substantial enough in several arenas, consider splitting off into those different arenas with different teams and ultimately, different software. You might share bundles, but your audiences focus are better addressed by specialization.

Consider the gaming platform: the X-box is at its core just a repackaged PC, as is just about every console system now in existence; they have to have some core systems in common with computer because it allows developers to design the games on computer systems. However, transferring gaming from the personal computer has been good for both the computer industry and the gaming industry.

Developing for a focused subset of consoles, all of which have identical configurations, is much easier for game developers. They don't have to worry anymore about cutting off PC owners with older motherboards, dealing with the near-infinite combination of hardware, monitor sizes, and operating systems that typify the computer industry.

Similarly, the pressure is pretty much off the computer owner nowadays when it comes to graphic cards. If you can read the average web page on your computer, you have a good enough graphics cards. In fact, the truth is that now computer manufacturers really don't have any excuse to upsell the typical computer user; for most office and internet related uses, computers have essentially reached a point several years ago where the hardware and memory satisfied the demands the users and software develoepers were making on the  computer. The only thing really driving chip performance and development is industrial computer use (servers, scientiifc computing, etc.) and non-desktop applications such as robotics, vehicular computers, etc.

So if you find yourself in a situation where two substantial groups of users are making consistently contradictory demands, you are probably at the point wherein you need to either branch your product into distinct divisions or let go of the least rewarding group. Even if your division is a facade for the same product with two default configurations, you will be better off nursing the illusion; very few clients will "lift the curtain" and you will be able to convince the masses that you are devoted to their specialty.