Tank You For Making Innovation Work

In the tech industry, the earlier in the innovation process a developer works, the greater the prestige. Lower in the status hierarchy are developers who work on performance and scalability issues, build integrations with other systems, handle security issues, and (heaven forfend!) help the QA team set up test environments.
Of course, the customer has a much different set of priorities. Sure, new products and features are interesting, but their value is moot if the technology doesn't work. How many concurrent users can the system bear before it keels over? Are the big security holes plugged? Has anyone else run version 7.0.1.3 on Ubuntu 10.04? These questions determine whether a customer buys your product and how likely they are to remain a customer after they've tried to deploy it.
Remember The D In R&D
Some of the larger technology companies have decided to make a serious investment in fixing the problem. While sensitivity training might help some development teams better appreciate the contributions of some of their members ("Looks like the performance guy needs a hug!"), there's no replacement for a well-staffed, well-equipped, dedicated effort to ensuring that the technology works as advertised. Or, just as importantly, doesn't work as advertised, so that the customer knows what sort of configurations and use cases to avoid.
In the organization chart of companies like Intel and Hitachi, you'll find divisions called "labs." The term is technically accurate, but it's a little misleading in the subculture of the technology industry. We usually think of an entity like IBM's research arm as "labs," small groups of Very Smart People working on Very Big Ideas.  However, "labs" can focus on the later phases of innovation, stressing the technology in real-world configurations and developing best practices for deployment and then communicating this information inside and outside the company. When the potential customer wants to be reassured about the risk of making an investment, the salesperson can credibly provide this reassurance.
It takes a dedicated, sustained, and substantial investment of people and resources to perform this service. Nevertheless, the business benefits are considerable. So why don't we hear about them more often? Part of the answer lies in our disproportionate interest in the early phases of innovation, where we create potential capabilities, and the later phases, when we make the technology work.
A Tale Of Two Tanks
When I used to have more office space, and I could clutter it with no end of gewgaws, I had two models of WWII-era tanks on my bookshelf. One was an American M4, more famously known as the Sherman. The other was a German Panzerkampfwagen VI, a.k.a. the Tiger tank. These two armored fighting vehicles represent different approaches to the technology design that are relevant to our discussion.
The Sherman was almost stereotypically American: simple, practical, and produced in enormous quantities. It was far from the best tank on the WWII battlefield, but it was a yeoman-like piece of hardware.
The Tiger was a far more powerful tank. Its 88mm gun outranged and outpunched the Sherman's 75mm gun. The Tiger was far more heavily armored, with predictable results: shells fired from the Sherman's inferior gun usually bounced off the Tiger's armor; the Tiger's beastly weapon punched holes through the Sherman's armor as if it were wet Kleenex. A one-on-one matchup between the Sherman and the Tiger was no contest at all.
However, real clashes between these weapons were rarely as simple as a one-on-one matchup. Sherman tank commanders learned how to swarm the Tiger, so that at least one American tank could get a shot at the Tiger's rear armor. (Of course, many Sherman crews died in these clashes, sacrificing themselves so that their brothers in arms could get behind the Tiger for the killing blow.)
Long before the two tanks reached the battlefield, the Sherman had already won many potential engagements, simply because the Tiger didn't show up. The Sherman had its weaknesses and even a few notable design flaws. It also had an enormous advantage: reliability. The United States produced hundreds of Sherman tanks every month, and when they reached the European theater, they quickly rolled off the container ships into battle. In contrast, the Tiger was a finicky beast, prone to breakdowns, requiring constant attention from its crews. From D-Day to the end of the war, Americans faced half of the Tigers in the German arsenal, due to the Tiger's constant mechanical problems.
Looking at the potential capabilities, the Tiger was a superior tank. Fortunately for the Allies, potential capabilities don't win battles.
We can make roughly the same observation about software and hardware: the vendor that "wins" is usually the one with technology that's both highly capable and reliable. If you want to increase your win/loss ratio, you might consider investing in the kind of lab that makes sure that the technology works and that the customer understands what to expect from it.