<?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: Product Differentiation vs. Product Improvement</title>
	<atom:link href="http://tynerblain.com/blog/2006/05/24/differentiation-vs-improvement/feed/" rel="self" type="application/rss+xml" />
	<link>http://tynerblain.com/blog/2006/05/24/differentiation-vs-improvement/</link>
	<description>Software product success.</description>
	<lastBuildDate>Sat, 19 May 2012 12:04:06 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0.4</generator>
	<item>
		<title>By: Scott Sehlhorst</title>
		<link>http://tynerblain.com/blog/2006/05/24/differentiation-vs-improvement/comment-page-1/#comment-3069</link>
		<dc:creator>Scott Sehlhorst</dc:creator>
		<pubDate>Mon, 29 May 2006 16:25:27 +0000</pubDate>
		<guid isPermaLink="false">http://tynerblain.com/blog/2006/05/24/differentiation-vs-improvement/#comment-3069</guid>
		<description>Deepak - thanks for commenting - and great point.

There is definitely a point in time where incremental improvements are better than additional functionality.  If we look at the following chart, used most recently in &lt;a href=&quot;http://tynerblain.com/blog/2006/05/22/mrd-writing-tips-ten-from-michael-shrivathsan/&quot; rel=&quot;nofollow&quot;&gt;MRD Writing Tips&lt;/a&gt;, we see that there is a law of diminishing returns in place.

&lt;img src=&quot;http://sehlhorst.smugmug.com/photos/57708984-M.png&quot; alt=&quot;Profit Maximizing incremental improvement&quot;/&gt;

When we are on the left side of the tangent point, we can benefit from incremental improvement.  When the amount of that benefit exceeds the expected benefit of a new feature introduction, we should do it.

Thanks again,
Scott</description>
		<content:encoded><![CDATA[<p>Deepak &#8211; thanks for commenting &#8211; and great point.</p>
<p>There is definitely a point in time where incremental improvements are better than additional functionality.  If we look at the following chart, used most recently in <a href="http://tynerblain.com/blog/2006/05/22/mrd-writing-tips-ten-from-michael-shrivathsan/" rel="nofollow">MRD Writing Tips</a>, we see that there is a law of diminishing returns in place.</p>
<p><img src="http://sehlhorst.smugmug.com/photos/57708984-M.png" alt="Profit Maximizing incremental improvement"/></p>
<p>When we are on the left side of the tangent point, we can benefit from incremental improvement.  When the amount of that benefit exceeds the expected benefit of a new feature introduction, we should do it.</p>
<p>Thanks again,<br />
Scott</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Deepak</title>
		<link>http://tynerblain.com/blog/2006/05/24/differentiation-vs-improvement/comment-page-1/#comment-2947</link>
		<dc:creator>Deepak</dc:creator>
		<pubDate>Sat, 27 May 2006 01:09:52 +0000</pubDate>
		<guid isPermaLink="false">http://tynerblain.com/blog/2006/05/24/differentiation-vs-improvement/#comment-2947</guid>
		<description>I think there is a trap a lot of people fall into, especially techie types.  &quot;Different&quot; does not mean &quot;better&quot;.  Sometimes incremental improvements make more sense than something new (of course, sometimes just the illusion of different makes it seem like things have improved).</description>
		<content:encoded><![CDATA[<p>I think there is a trap a lot of people fall into, especially techie types.  &#8220;Different&#8221; does not mean &#8220;better&#8221;.  Sometimes incremental improvements make more sense than something new (of course, sometimes just the illusion of different makes it seem like things have improved).</p>
]]></content:encoded>
	</item>
</channel>
</rss>

