<?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/"
	xmlns:georss="http://www.georss.org/georss" xmlns:geo="http://www.w3.org/2003/01/geo/wgs84_pos#" xmlns:media="http://search.yahoo.com/mrss/"
		>
<channel>
	<title>Comments on: Messenger of problems?</title>
	<atom:link href="http://productmanagementtips.com/2009/03/13/productmanagers-problems-solutions/feed/" rel="self" type="application/rss+xml" />
	<link>http://productmanagementtips.com/2009/03/13/productmanagers-problems-solutions/</link>
	<description>Practical software product management tips</description>
	<lastBuildDate>Fri, 25 May 2012 06:55:25 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.com/</generator>
	<item>
		<title>By: Product Management Reader: 19Mar09 &#124; The Productologist: Exploring the Depths of Product Management</title>
		<link>http://productmanagementtips.com/2009/03/13/productmanagers-problems-solutions/#comment-922</link>
		<dc:creator><![CDATA[Product Management Reader: 19Mar09 &#124; The Productologist: Exploring the Depths of Product Management]]></dc:creator>
		<pubDate>Thu, 19 Mar 2009 13:27:06 +0000</pubDate>
		<guid isPermaLink="false">http://productmanagementtips.com/?p=629#comment-922</guid>
		<description><![CDATA[[...] Messenger of problems? [Product Management Tips] [...]]]></description>
		<content:encoded><![CDATA[<p>[...] Messenger of problems? [Product Management Tips] [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: gopalshenoy</title>
		<link>http://productmanagementtips.com/2009/03/13/productmanagers-problems-solutions/#comment-921</link>
		<dc:creator><![CDATA[gopalshenoy]]></dc:creator>
		<pubDate>Tue, 17 Mar 2009 12:27:02 +0000</pubDate>
		<guid isPermaLink="false">http://productmanagementtips.com/?p=629#comment-921</guid>
		<description><![CDATA[William,

Great points. When I wrote this post, I was writing from the perspective of communication between an employee and his/her boss regarding problems that exist within the department. 

Thank you for taking the time to comment.

Gopal]]></description>
		<content:encoded><![CDATA[<p>William,</p>
<p>Great points. When I wrote this post, I was writing from the perspective of communication between an employee and his/her boss regarding problems that exist within the department. </p>
<p>Thank you for taking the time to comment.</p>
<p>Gopal</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Dr. Jim Anderson</title>
		<link>http://productmanagementtips.com/2009/03/13/productmanagers-problems-solutions/#comment-920</link>
		<dc:creator><![CDATA[Dr. Jim Anderson]]></dc:creator>
		<pubDate>Tue, 17 Mar 2009 01:37:52 +0000</pubDate>
		<guid isPermaLink="false">http://productmanagementtips.com/?p=629#comment-920</guid>
		<description><![CDATA[Sigh, all of us engineers fully recognize the &quot;find a problem&quot; mentality - it&#039;s baked into us. It&#039;s almost like we have some sort of 6th sense - just by looking at something we are able to quickly spot something that is wrong with it.

Coming up with solutions, well that&#039;s not so easy. I fully agree with you that your real value to the company ultimately lies in your ability to fix problems (really to prevent them before they show up).

Case in point: although product testers are very good at what they do, they don&#039;t normally fix problems - they just find them. All too often, when budgets get tight the testers are among the first to be let go.


- Dr. Jim Anderson
&lt;a href=&quot;http://www.TheAccidentalPM.com/&quot; title=&quot;The Accidental Product Manager Blog&quot; rel=&quot;nofollow&quot;&gt;The Accidental PM Blog&lt;/a&gt;
&quot;Home Of The Billion Dollar Product Manager&quot;]]></description>
		<content:encoded><![CDATA[<p>Sigh, all of us engineers fully recognize the &#8220;find a problem&#8221; mentality &#8211; it&#8217;s baked into us. It&#8217;s almost like we have some sort of 6th sense &#8211; just by looking at something we are able to quickly spot something that is wrong with it.</p>
<p>Coming up with solutions, well that&#8217;s not so easy. I fully agree with you that your real value to the company ultimately lies in your ability to fix problems (really to prevent them before they show up).</p>
<p>Case in point: although product testers are very good at what they do, they don&#8217;t normally fix problems &#8211; they just find them. All too often, when budgets get tight the testers are among the first to be let go.</p>
<p>- Dr. Jim Anderson<br />
<a href="http://www.TheAccidentalPM.com/" title="The Accidental Product Manager Blog" rel="nofollow">The Accidental PM Blog</a><br />
&#8220;Home Of The Billion Dollar Product Manager&#8221;</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: William Beecher III</title>
		<link>http://productmanagementtips.com/2009/03/13/productmanagers-problems-solutions/#comment-919</link>
		<dc:creator><![CDATA[William Beecher III]]></dc:creator>
		<pubDate>Mon, 16 Mar 2009 16:58:53 +0000</pubDate>
		<guid isPermaLink="false">http://productmanagementtips.com/?p=629#comment-919</guid>
		<description><![CDATA[I think you&#039;re overlooking an important point. There comes a time where a problem causer either develops the skills to resolve problems he/she causes - or does not. One of the key parts in this journey of self-development is stating the problem and giving them the opportunity to fix it on their own. The first resort is directly to the person, and if needed, the second is to a superior.

You could probably make your argument for same-department interactions, but for cross-department interactions, this argument doesn&#039;t get too far - and such a practice will often be met with frustration and eventual discouragement by those always trying to solve the problems of others as they often end up doing extra work and possibly something that&#039;s not in their job description. 

In my experience, often those who try to solve the problems of others will eventually give up. That is, they&#039;ve tried postulating suggestions and stating the obvious process degradation, yet the results have been fruitless - and they&#039;re not looking to expand their job description :). The problem refuses to be thoughtfully addressed by the causer for who knows what reasons - pride...mediocrity...forgetfulness at best. Whatever the cause maybe, eventually the only solution to the problem is to remove the problem causer which is not something a co-worker will understandably out-right say or even suggest...the only intermediate solution is to just keep tallying the problems as they come up.

Obviously my comment does not address the ignorant problem causer whom we all feel for. We all know that there are cases where someone &quot;just doesn&#039;t know&quot; how things should be done and they should be figuratively (or even literally) taken by the hand and shown the way. But this will eventually come to an end - and then often when problems are simply stated to a superior it&#039;s just to keep a running count on something that has become the status quo for the time being - until someone who can make a serious decision decides they&#039;re tired of what the status-quo has become.]]></description>
		<content:encoded><![CDATA[<p>I think you&#8217;re overlooking an important point. There comes a time where a problem causer either develops the skills to resolve problems he/she causes &#8211; or does not. One of the key parts in this journey of self-development is stating the problem and giving them the opportunity to fix it on their own. The first resort is directly to the person, and if needed, the second is to a superior.</p>
<p>You could probably make your argument for same-department interactions, but for cross-department interactions, this argument doesn&#8217;t get too far &#8211; and such a practice will often be met with frustration and eventual discouragement by those always trying to solve the problems of others as they often end up doing extra work and possibly something that&#8217;s not in their job description. </p>
<p>In my experience, often those who try to solve the problems of others will eventually give up. That is, they&#8217;ve tried postulating suggestions and stating the obvious process degradation, yet the results have been fruitless &#8211; and they&#8217;re not looking to expand their job description <img src='http://s0.wp.com/wp-includes/images/smilies/icon_smile.gif' alt=':)' class='wp-smiley' /> . The problem refuses to be thoughtfully addressed by the causer for who knows what reasons &#8211; pride&#8230;mediocrity&#8230;forgetfulness at best. Whatever the cause maybe, eventually the only solution to the problem is to remove the problem causer which is not something a co-worker will understandably out-right say or even suggest&#8230;the only intermediate solution is to just keep tallying the problems as they come up.</p>
<p>Obviously my comment does not address the ignorant problem causer whom we all feel for. We all know that there are cases where someone &#8220;just doesn&#8217;t know&#8221; how things should be done and they should be figuratively (or even literally) taken by the hand and shown the way. But this will eventually come to an end &#8211; and then often when problems are simply stated to a superior it&#8217;s just to keep a running count on something that has become the status quo for the time being &#8211; until someone who can make a serious decision decides they&#8217;re tired of what the status-quo has become.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Joe Sidowsky</title>
		<link>http://productmanagementtips.com/2009/03/13/productmanagers-problems-solutions/#comment-917</link>
		<dc:creator><![CDATA[Joe Sidowsky]]></dc:creator>
		<pubDate>Mon, 16 Mar 2009 00:46:38 +0000</pubDate>
		<guid isPermaLink="false">http://productmanagementtips.com/?p=629#comment-917</guid>
		<description><![CDATA[More worrisome than above are folks who want to be the first to communicate anything to the boss in a meeting or in person. Like trying to look good, be the first with the answer - basically trying to do anything to look good in front of the big man. In process of doing so, these folks also present problems with no solutions, just so they say something, anything.]]></description>
		<content:encoded><![CDATA[<p>More worrisome than above are folks who want to be the first to communicate anything to the boss in a meeting or in person. Like trying to look good, be the first with the answer &#8211; basically trying to do anything to look good in front of the big man. In process of doing so, these folks also present problems with no solutions, just so they say something, anything.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Perry McDowell</title>
		<link>http://productmanagementtips.com/2009/03/13/productmanagers-problems-solutions/#comment-915</link>
		<dc:creator><![CDATA[Perry McDowell]]></dc:creator>
		<pubDate>Sun, 15 Mar 2009 01:56:49 +0000</pubDate>
		<guid isPermaLink="false">http://productmanagementtips.com/?p=629#comment-915</guid>
		<description><![CDATA[This is a good reason to hire ex-military officers and senior enlisted.  They are taught never to take a problem to their bosses without a solution.]]></description>
		<content:encoded><![CDATA[<p>This is a good reason to hire ex-military officers and senior enlisted.  They are taught never to take a problem to their bosses without a solution.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

