More like:
GOOD execution is one of the major problems.
This is why engineers should not be afraid to sell, or at least, not be afraid to be out in front. The power in any organization comes from who sells the product.
Good businesses understand that all their functional areas are important, and don't try to preference one over another. You may need to focus on one at first to make progress with it, though I'd argue that when you first get started, that one area should be none of the above (it should be customer development in the Lean Startup sense: talking to people to get a sense of what they need and how they do things).
The big challenge in enterprise software engineering is that your "customer" is the person who forks over money, not the person who uses the software. Pretty much all engineering effort is devoted to pleasing them. Engineering requirements for enterprise software are often insanely complex and sometimes even conflicting, and most of the engineering effort is devoted to satisfying them.
If you look at product/UX debacles like Taleo or Lotus Notes from the perspective of a department head buying them (rather than from the recruiter, job applicant, or ordinary worker who will be using them), a lot of enterprise software makes sense. There's a lot of effort devoted to reporting requirements, to making sure the buyer has visibility on what all of his department is doing and conversely can make that "productivity" visible to his boss, to covering one's ass with regulatory requirements, and not much effort devoted to making things pretty or productive for the end-users. That's because the end-users are not the buyer of the software.
Indeed, a lot of the investment thesis in consumer/smallbiz Internet is this idea that software should replace middle managers entirely, and so the end-users should be the actual buyer of the software who need it to make money, basically replacing management with markets.