<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Development: Leave Us the $Foo Alone!</title>
	<atom:link href="http://www.productbeautiful.com/2008/04/25/development-leave-us-the-f-alone/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.productbeautiful.com/2008/04/25/development-leave-us-the-f-alone/</link>
	<description>Building Product Management from the Ground Up by Paul Young</description>
	<lastBuildDate>Fri, 08 Jan 2010 20:13:16 -0700</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.4</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Scott Ryder</title>
		<link>http://www.productbeautiful.com/2008/04/25/development-leave-us-the-f-alone/comment-page-1/#comment-1375</link>
		<dc:creator>Scott Ryder</dc:creator>
		<pubDate>Fri, 02 May 2008 00:38:40 +0000</pubDate>
		<guid isPermaLink="false">http://www.productbeautiful.com/?p=91#comment-1375</guid>
		<description>Good post. I like the approach of getting the dev leads involved in both the selection of items for a release and the marketing definition of those features. I&#039;ve found that when they get involved at this level a couple of things happen:
- They gain an understanding of the complexity involved with the decisions. This opens their minds to the fact that their view is not comprehensive and they gain appreciation for how much PM is buffering them from all of the information gathering. (note: I would never have Sales and Engineering at the table for a release contents meeting. A primary function of PM is to gather the various inputs and sort through the needs before presenting them)
- Ownership is build out of being part of the decision. I can&#039;t put enough emphasis on this. If a Dev Lead has a view into why something was selected and actively or tacitly participated in the decision, the PMs job is going to be a lot easier.

Scott</description>
		<content:encoded><![CDATA[<p>Good post. I like the approach of getting the dev leads involved in both the selection of items for a release and the marketing definition of those features. I&#8217;ve found that when they get involved at this level a couple of things happen:<br />
- They gain an understanding of the complexity involved with the decisions. This opens their minds to the fact that their view is not comprehensive and they gain appreciation for how much PM is buffering them from all of the information gathering. (note: I would never have Sales and Engineering at the table for a release contents meeting. A primary function of PM is to gather the various inputs and sort through the needs before presenting them)<br />
- Ownership is build out of being part of the decision. I can&#8217;t put enough emphasis on this. If a Dev Lead has a view into why something was selected and actively or tacitly participated in the decision, the PMs job is going to be a lot easier.</p>
<p>Scott</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Susan Lim</title>
		<link>http://www.productbeautiful.com/2008/04/25/development-leave-us-the-f-alone/comment-page-1/#comment-1360</link>
		<dc:creator>Susan Lim</dc:creator>
		<pubDate>Sat, 26 Apr 2008 19:03:41 +0000</pubDate>
		<guid isPermaLink="false">http://www.productbeautiful.com/?p=91#comment-1360</guid>
		<description>Hi Paul, just want to share this about product meeting....

In one of the product meeting I attended last time in a company where Product Management role is new, I sat in the meeting with teams from development and sales (both international and local). I was new to the company and I was supposed to help kick off the product management team (that&#039;s why I was invited to the meeting). There were 3 vice presidents from sales and development and around 5-6 managers attending the meeting.

It was supposed to a discussion on the product roadmap. The meeting started with waiting for more than half an hours for some sales VP &amp; managers because they are obviously busy with customers. Thus, they filled in the time discussing about previous issues (about a product evaluation) that was not settled and seemed like not going to be settled in the near future. Well, obviously, there are no conclusion because they just discussed it for the sake for filling in the time while waiting. When the waiting was over, we went through a list of requirements from different customers. We went through the list one by one (some requirements was like a special report from customers) and decided together whether the requirements add to the value to the product (means can be used by other customers or a good sell point) or not. This is acceptable except I felt funny that this task need so many VPs and managers to get involved. But it was good that everyone important to the product are present to trash out all issues. 

Then, the development team announced there will be rolling out version 4.0 in a year later and most of the resources will be tied up. So , any changes to version 3.x would be scaled down to the minimal. Of course, this is unacceptable to the sales team, which as normal, all the requirements from customers are considered urgent. I agreed that version 4 is not really convincing to the sales teams due to the reason they are no one in the room that knows what will be in version 4.0 but one thing for sure is that the developers are going to rewrite the software in the latest programming language framework (something like using VB .NET instead of VB). Eventually, two directors of the company joined our meeting to make the decision. They agreed that version 4.0 will be developed and rolled out in a year and most of the customer requirements will not be fullfilled unless it is an important one. The sales teams are to communicate to the customers that a newer version which will be rolled out in a year , will have the almost the SAME features, but with better architecture or flexibilities to fullfill their requirements. For e.g. any new report they need now may take around months to fullfill, but with version 4.0, it should takes maybe 1-2 weeks. That make it worth for them to wait and &quot;probably suffer&quot; for a year or so in the current version that may not fullfill what they need. But it is only a year, right? Well, that&#039;s probably alright also,except after a year, the development team will come back to say they need an extension because they are so keen to deliver a great product this time that they underestimate some of the things. When the product was finally released to the customers after the delays, the promise that requirements will be fullfilled faster than previous version was not really delivered because the development team is busy fixing new bugs and problems that come with the latest version. 

Anyway, that was the most inefficient meeting that I ever had in my career life. Because I never seen so many top management team gathered around and decided on something at such a high level that nothing was actually achieved.

I suppose that is why it is important to have a product management team rather than to let everyone (development, sales,etc.) to decide together on the product roadmap but no one to take responsibilities.</description>
		<content:encoded><![CDATA[<p>Hi Paul, just want to share this about product meeting&#8230;.</p>
<p>In one of the product meeting I attended last time in a company where Product Management role is new, I sat in the meeting with teams from development and sales (both international and local). I was new to the company and I was supposed to help kick off the product management team (that&#8217;s why I was invited to the meeting). There were 3 vice presidents from sales and development and around 5-6 managers attending the meeting.</p>
<p>It was supposed to a discussion on the product roadmap. The meeting started with waiting for more than half an hours for some sales VP &amp; managers because they are obviously busy with customers. Thus, they filled in the time discussing about previous issues (about a product evaluation) that was not settled and seemed like not going to be settled in the near future. Well, obviously, there are no conclusion because they just discussed it for the sake for filling in the time while waiting. When the waiting was over, we went through a list of requirements from different customers. We went through the list one by one (some requirements was like a special report from customers) and decided together whether the requirements add to the value to the product (means can be used by other customers or a good sell point) or not. This is acceptable except I felt funny that this task need so many VPs and managers to get involved. But it was good that everyone important to the product are present to trash out all issues. </p>
<p>Then, the development team announced there will be rolling out version 4.0 in a year later and most of the resources will be tied up. So , any changes to version 3.x would be scaled down to the minimal. Of course, this is unacceptable to the sales team, which as normal, all the requirements from customers are considered urgent. I agreed that version 4 is not really convincing to the sales teams due to the reason they are no one in the room that knows what will be in version 4.0 but one thing for sure is that the developers are going to rewrite the software in the latest programming language framework (something like using VB .NET instead of VB). Eventually, two directors of the company joined our meeting to make the decision. They agreed that version 4.0 will be developed and rolled out in a year and most of the customer requirements will not be fullfilled unless it is an important one. The sales teams are to communicate to the customers that a newer version which will be rolled out in a year , will have the almost the SAME features, but with better architecture or flexibilities to fullfill their requirements. For e.g. any new report they need now may take around months to fullfill, but with version 4.0, it should takes maybe 1-2 weeks. That make it worth for them to wait and &#8220;probably suffer&#8221; for a year or so in the current version that may not fullfill what they need. But it is only a year, right? Well, that&#8217;s probably alright also,except after a year, the development team will come back to say they need an extension because they are so keen to deliver a great product this time that they underestimate some of the things. When the product was finally released to the customers after the delays, the promise that requirements will be fullfilled faster than previous version was not really delivered because the development team is busy fixing new bugs and problems that come with the latest version. </p>
<p>Anyway, that was the most inefficient meeting that I ever had in my career life. Because I never seen so many top management team gathered around and decided on something at such a high level that nothing was actually achieved.</p>
<p>I suppose that is why it is important to have a product management team rather than to let everyone (development, sales,etc.) to decide together on the product roadmap but no one to take responsibilities.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
