For obvious reasons, product demonstrations focus on features. The company has to show you what's new in the software, and what benefit those features will have. That's what they're selling, after all.

But there's a lot a product rollout leaves out. A demo is very here-and-now, and has little room for over-arching goals or long-term effects. At the recent VS Live conference in San Francisco, I had the opportunity to ask Ian Knox, Microsoft's Lead Product Manager for Visual Studio Team System, a few of the non-obvious questions.

For instance, I wanted to know what was left out. In every significant project, from software development to home decorating, you start with a wish-list of what you'd like to include. At some point, the realities of financial budget, time constraints, technical feasibility, or (let's be real) office politics cause you to scratch items off the list — in other words, "Something's got to go, if we're to meet our ship date."

When it comes to Visual Studio Team System — due to ship in the next month or so — what one feature does Knox wish could have been included? "I wish we could have put more into solving the problem of requirements," he said. "Nobody has really cracked that problem in a very meaningful way." Developing software requirements involves a lot of components, with both structured and unstructured information, visualization, and the need to adapt over time. "Even if you have telepathy in the beginning," Knox said, "What about when things change?"

I didn't mean to disparage the importance of features, by the way. Any truly innovative product gives you new, useful knobs to twist that enable you to be more efficient. When they're really cool, you might react with a gasp, the way we old-timers did the first time the Millenium Falcon went into hyperspace. With dozens of Team System demos under his belt, Knox is in the best position to know what features generate the heart-thumping reaction. I asked him: what features get the most Ooooh!s in a demo? Which ones take two weeks of actual use to appreciate?

It totally depends on the audience, Knox told me. For CIOs, the initial "oh, cool!" comes from "the fact that Visual Studio gives you insight into your organization." It "bubbles up" what's going on, so that a CIO can determine what's on track and what project is in trouble, so that CIOs feel they can control risk, to some degree. Two weeks later, what they "Oooh!" at is the depth of integration.

Developers respond to a different set of features, particularly the ones that they perceive will save them time. "They love the LINQ stuff, cool stuff that's a jump at an abstract level." The static analysis tools are cool too, as is anything that can automate the dull, repetitive work.

For project managers, the enthusiasm can be boiled down to a single statement. "I can keep using Excel? I love you guys."

You may want to keep those points in mind, if you're ever called upon to explain to the boss why Team System is worth the investment.

If the whole point of Team System is to improve collaboration, and to do a better job at connecting the dots between all the people involved in creating new software, then we should expect social side effects from using it, right? I asked Knox how he thinks Team System will change the dynamics of the way people work together. The biggest change, he thinks, will be in "allowing people to learn about what works and doesn't work." People will be able to understand why something went wrong, he says, and improve the development process around that understanding.

Also, he believes, people will start to look left and right, and learn more about what the people around them are doing. If, today, a developer tries to fix a bug, he'll say, "I think it's this; I'll try it" and send the code off to QA, who send it back. With Team System, Knox says, the developer may be more likely to test the code and see how it works, getting a better appreciation of the QA process.