You are correct that many in the industry refer to our Program Manager discipline as "product management" and our Product Manager discipline as "product marketing".
A program manager is a dev team function. They define and manage the product based on the requirements, market data, market analysis, and research that a
product manager (a marketing function) creates.
For example, on Visual Studio 2005, I wrote the Market Requirements Document for the full product line. That MRD consisted of customer types (segmentation), end-to-end use scenarios, and customer research (I also included positioning, messaging, disclosure
plans, strawman media/PR plans, and other information as appendices for the dev team).
Folks like Lori took that data and translated it into more detailed scenarios, prioritized feature lists, feature specs, schedules, and other information that served as a blueprint for developers, testers, user education writers, localization engineers, build
managers, and others in the several thousand person DevDiv (and beyond) org.
While the PMs and dev team worked furiously on delivering the bits, the product managers on my team worked with our worldwide field sales and marketing organization to prepare them to be able to sell, evangelize, and market all aspects of the product locally.
As the product neared completion, the folks on my team also began preparations for our worldwide launch activities, in conjunction with our marketing counterparts in our worldwide subsidiaries.
In the end, it is an extraordinary team effort that requires a great deal of coordination and leadership. From translating our knowledge of our customers into products and business plans, to actually delivering a high quality tools release, to being able to
sell and launch the product worldwide, holding that big box at the end of it all is one of the most exhilirating moments in anyone's career, and one of the biggest reasons why many of us love working at MS.
1. The Team Foundation Server is optional. If you elect to install and use it, you will get all the collaboration benefits of Team System (Work Items, source code control, process guidance, policy enforcement, SharePoint portals, etc).
2. MSDN/U becomes MSDN Premium beginning with this 2005 release. In the past, you bought the subscription first and got a Visual Studio product with it. Beginning in 2005, we're altering our model to be consistent with the rest of Microsoft: meaning, you
now buy a Visual Studio product and attach a subsciption to it. All the subscriber benefits you saw in MSDN/U are now present in MSDN Premium. You may attach an MSDN Premium Subscription to Visual Studio Professional Edition (a pure superset of what used
to be in the old MSDN Universal Subscription, for about $200 less), or you may attach an MSDN Premium SUbscription to any of the Team System client products.
3. There is considerable value in these tools, and they are available at a considerably lower price than competitive products. You'll notice that we lowered the price of the Professional Edition product, we lowered the price of the equivalent to MSDN/U, and
we introduced a series of low cost products with the Express Editions.
Yearly renewals for the VSTS client SKU + MSDN Premium Subscription remain the same as MSDN/U today. In fact, that was a design goal of the pricing.
We should be able to roll out better pricing information very soon:
1. We're prepping a much better Web site than what you see today. I personally apologize for how hard it is to get information now and trust me, we're going to do our best to fix it.
2. The feedback we've received has been tremendous (both pro and con, by the way). Buried within the dialogue have been some extremely fascinating licensing questions. Our current plan addresses most of these already (albeit, with some clarification from
Microsoft) while a handful of these licensing questions has caused us to go back and consider some things that we hadn't thought of.
3. The vast majority of our customers for these tools buy in volume with a dedicated account manager. We optimized our pricing rollout for that audience, for better or worse. Typically, we don't send out the nitpicky pricing details until right before launch,
but this time around we're going to accelerate that as much as we can and get info out quickly.
Again, I apologize for the delay and difficulty in getting information. We're working on fixing it.
RE: what's in the various SKUs. First, for VS overall as an aggregate, consult
this link. For Team System itself, consult
this whitepaper which has a diagram I built to describe what's in what. The whitepaper is a little bit old, and since it was published we've included Team Build (continuous build) in the Team Foundation Server. Everything else should still be accurate.
RE: Price for Universal -> Team Suite will be published shortly.
RE: Universal/Enterprise -> Team Edition for SW Developers. You are correct. As an MSDN/E subscriber, you would automatically transition to VS Team Edition for SW Developers. As an MSDN/U subscriber, you'd get a choice (Architect, Dev, Tester) AND you'd
also likely get a better promotional upgrade price to Suite.
TFS has a pretty robust extensibility model (based on Web services). As such, it will let a bunch of third party products (including ones you can write on your own) connect to it.
Right now, we have a partner building a Unix connector, another building an Eclipse connector, and others looking at building connectors from other products/platforms.
Testers using other products: we have a number of third party testing tools vendors building connectors to TFS.
For the support question, if you built your own product for support engineers, you can modify it to store those support incidents into TFS. If you purchased one off the shelf from another vendor, please encourage them to build connectors to Team System. We're
working with a number of different vendors on this, but I'm not sure we have any commitments in that arena right now.