<?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: Death by a thousand paper cuts &#8230;.</title>
	<atom:link href="http://productmanagementtips.com/2009/10/26/death-by-a-thousand-paper-cuts/feed/" rel="self" type="application/rss+xml" />
	<link>http://productmanagementtips.com/2009/10/26/death-by-a-thousand-paper-cuts/</link>
	<description>Practical software product management tips</description>
	<lastBuildDate>Wed, 15 Feb 2012 20:10:52 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.com/</generator>
	<item>
		<title>By: saeed</title>
		<link>http://productmanagementtips.com/2009/10/26/death-by-a-thousand-paper-cuts/#comment-1440</link>
		<dc:creator><![CDATA[saeed]]></dc:creator>
		<pubDate>Thu, 03 Dec 2009 00:26:46 +0000</pubDate>
		<guid isPermaLink="false">http://productmanagementtips.com/?p=839#comment-1440</guid>
		<description><![CDATA[This is a real problem with most software. For B2B software, when these issues are raised, the inevitable debate happens about whether &quot;fixing&quot; those issues will generate more revenue, and the cost will be NOT implementing something new. I find this to be a really annoying debate, because those issues shouldn&#039;t have been introduced into the product in the first place. 

I wrote about this topic here for Progmatic a while back.

http://www.pragmaticmarketing.com/publications/topics/05/0501sk1

Saeed]]></description>
		<content:encoded><![CDATA[<p>This is a real problem with most software. For B2B software, when these issues are raised, the inevitable debate happens about whether &#8220;fixing&#8221; those issues will generate more revenue, and the cost will be NOT implementing something new. I find this to be a really annoying debate, because those issues shouldn&#8217;t have been introduced into the product in the first place. </p>
<p>I wrote about this topic here for Progmatic a while back.</p>
<p><a href="http://www.pragmaticmarketing.com/publications/topics/05/0501sk1" rel="nofollow">http://www.pragmaticmarketing.com/publications/topics/05/0501sk1</a></p>
<p>Saeed</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: M. Garlington</title>
		<link>http://productmanagementtips.com/2009/10/26/death-by-a-thousand-paper-cuts/#comment-1364</link>
		<dc:creator><![CDATA[M. Garlington]]></dc:creator>
		<pubDate>Fri, 30 Oct 2009 19:21:18 +0000</pubDate>
		<guid isPermaLink="false">http://productmanagementtips.com/?p=839#comment-1364</guid>
		<description><![CDATA[Loved this post.  It reminded me of a very similar experience I had and provided me with lessons I apply to this very day in managing new and existing product releases.  Your post inspired me to blog about my experience as well:   http://bit.ly/2UYKoP. 

M. Garlington]]></description>
		<content:encoded><![CDATA[<p>Loved this post.  It reminded me of a very similar experience I had and provided me with lessons I apply to this very day in managing new and existing product releases.  Your post inspired me to blog about my experience as well:   <a href="http://bit.ly/2UYKoP" rel="nofollow">http://bit.ly/2UYKoP</a>. </p>
<p>M. Garlington</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Don F Perkins</title>
		<link>http://productmanagementtips.com/2009/10/26/death-by-a-thousand-paper-cuts/#comment-1362</link>
		<dc:creator><![CDATA[Don F Perkins]]></dc:creator>
		<pubDate>Thu, 29 Oct 2009 13:29:12 +0000</pubDate>
		<guid isPermaLink="false">http://productmanagementtips.com/?p=839#comment-1362</guid>
		<description><![CDATA[Very good post. I have noticed this many times in my work as a field worker for major electronics and services co. Fortunately, being a smaller and more agile company allowed us to make changes quickly to accommodate user&#039;s reported difficulties. What I found with a larger company I worked for was that they were unwilling to accept input from the field as reason to initiate engineering change most of the time, relying heavily on their own intuition and momentum. I suppose the larger the customer base, the harder it gets to affect change because of scale.

One thing&#039;s for sure though, customer&#039;s love to interact with their suppliers in regards to fixing stupid little irksome problems with products. The challenge is turning that kind of time intensive focus into real ROI for the business.

Don F Perkins]]></description>
		<content:encoded><![CDATA[<p>Very good post. I have noticed this many times in my work as a field worker for major electronics and services co. Fortunately, being a smaller and more agile company allowed us to make changes quickly to accommodate user&#8217;s reported difficulties. What I found with a larger company I worked for was that they were unwilling to accept input from the field as reason to initiate engineering change most of the time, relying heavily on their own intuition and momentum. I suppose the larger the customer base, the harder it gets to affect change because of scale.</p>
<p>One thing&#8217;s for sure though, customer&#8217;s love to interact with their suppliers in regards to fixing stupid little irksome problems with products. The challenge is turning that kind of time intensive focus into real ROI for the business.</p>
<p>Don F Perkins</p>
]]></content:encoded>
	</item>
</channel>
</rss>

