<?xml version="1.0" encoding="UTF-8"?><!-- generator="wordpress/2.0.3" -->
<rss version="2.0" 
	xmlns:content="http://purl.org/rss/1.0/modules/content/">
<channel>
	<title>Comments on: The other side of product management</title>
	<link>http://www.mikelunt.com/blog/2006/09/08/the-other-side-of-product-management/</link>
	<description>Life is great, and it only gets better.</description>
	<pubDate>Fri, 05 Dec 2008 13:21:54 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.0.3</generator>

	<item>
		<title>by: Sell your requirements to development: How To Be A Good Product Manager: Product management tips</title>
		<link>http://www.mikelunt.com/blog/2006/09/08/the-other-side-of-product-management/#comment-5351</link>
		<pubDate>Fri, 16 Mar 2007 12:20:13 +0000</pubDate>
		<guid>http://www.mikelunt.com/blog/2006/09/08/the-other-side-of-product-management/#comment-5351</guid>
					<description>[...] Mike Lunt calls this The Other Side of Product Management. If one side is &amp;#8220;gathering requirements and selling the products to the sales team,&amp;#8221; then the other side is &amp;#8220;selling the engineering team on the value the new features or changes in the product will have for the customer (and ultimately the success of the group).&amp;#8221; He adds that for a product to be successful, the engineering team must be motivated to implement the product manager’s feedback. Many projects have failed or been plagued by engineering feature creep because the team did not have confidence in the information stream coming from the product manager(s). [...]</description>
		<content:encoded><![CDATA[<p>[&#8230;] Mike Lunt calls this The Other Side of Product Management. If one side is &#8220;gathering requirements and selling the products to the sales team,&#8221; then the other side is &#8220;selling the engineering team on the value the new features or changes in the product will have for the customer (and ultimately the success of the group).&#8221; He adds that for a product to be successful, the engineering team must be motivated to implement the product manager’s feedback. Many projects have failed or been plagued by engineering feature creep because the team did not have confidence in the information stream coming from the product manager(s). [&#8230;]
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: Mike Lunt</title>
		<link>http://www.mikelunt.com/blog/2006/09/08/the-other-side-of-product-management/#comment-33</link>
		<pubDate>Thu, 14 Sep 2006 02:10:11 +0000</pubDate>
		<guid>http://www.mikelunt.com/blog/2006/09/08/the-other-side-of-product-management/#comment-33</guid>
					<description>Thanks for the feedback.  I have since posted this comment to the &lt;a href=http://cauvin.blogspot.com/2006/09/mike-lunt-on-selling-to-development.html rel=&quot;nofollow&quot;&gt;above blog entry&lt;/a&gt;.

Roger, I agree that facilitation should make up the bulk of the information flow; however, it would also help to show which customers caused the basis for existing features. Instead of using customer A and customer B, engineers often want to have some basis for the features being proposed, especially when prioritzation occurs. For instance, the question about why certain features are being proposed in front of other features seems like a good place to implement some objective data. Maybe a post on the negative effects of showing objective data might help sway me.</description>
		<content:encoded><![CDATA[<p>Thanks for the feedback.  I have since posted this comment to the <a href=http://cauvin.blogspot.com/2006/09/mike-lunt-on-selling-to-development.html rel="nofollow">above blog entry</a>.</p>
<p>Roger, I agree that facilitation should make up the bulk of the information flow; however, it would also help to show which customers caused the basis for existing features. Instead of using customer A and customer B, engineers often want to have some basis for the features being proposed, especially when prioritzation occurs. For instance, the question about why certain features are being proposed in front of other features seems like a good place to implement some objective data. Maybe a post on the negative effects of showing objective data might help sway me.
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: Roger L. Cauvin</title>
		<link>http://www.mikelunt.com/blog/2006/09/08/the-other-side-of-product-management/#comment-31</link>
		<pubDate>Tue, 12 Sep 2006 21:33:42 +0000</pubDate>
		<guid>http://www.mikelunt.com/blog/2006/09/08/the-other-side-of-product-management/#comment-31</guid>
					<description>Couldn't agree more about the proper role of a product manager.  Not sure if objective data is the solution, though.  See &lt;a href=&quot;http://cauvin.blogspot.com/2006/09/mike-lunt-on-selling-to-development.html&quot; rel=&quot;nofollow&quot;&gt;my latest blog entry&lt;/a&gt; for details.</description>
		<content:encoded><![CDATA[<p>Couldn&#8217;t agree more about the proper role of a product manager.  Not sure if objective data is the solution, though.  See <a href="http://cauvin.blogspot.com/2006/09/mike-lunt-on-selling-to-development.html" rel="nofollow">my latest blog entry</a> for details.
</p>
]]></content:encoded>
				</item>
</channel>
</rss>
