<?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: Which is better: faster- or quality-to-market?</title>
	<atom:link href="http://www.embeddedinsights.com/channels/2011/03/23/which-is-better-faster-or-quality-to-market/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.embeddedinsights.com/channels/2011/03/23/which-is-better-faster-or-quality-to-market/</link>
	<description>Shedding Light on the Hidden World of Embedded Systems</description>
	<lastBuildDate>Mon, 28 Jul 2014 16:18:37 -0400</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0</generator>
	<item>
		<title>By: Steve deRosier</title>
		<link>http://www.embeddedinsights.com/channels/2011/03/23/which-is-better-faster-or-quality-to-market/#comment-6219</link>
		<dc:creator>Steve deRosier</dc:creator>
		<pubDate>Thu, 14 Apr 2011 17:41:23 +0000</pubDate>
		<guid isPermaLink="false">http://www.embeddedinsights.com/channels/?p=492#comment-6219</guid>
		<description>If it&#039;s something revolutionary, perhaps *both* quick and quality are important.  A new startup can&#039;t afford to either alienate customers because their product was trash, nor can it afford to not to get to the market first.

The way to do it is fairly simple: make your initial product simple.  Focus on the direct problem at hand, and ignore the rest.  Create a limited-feature set, but fairly solid product.  Then in your updates you can add the new features.  The side-effect of this is you make your customers happy.  They bought your product for the functions it did do, and now you&#039;re adding more value to their purchase.

And, you&#039;ve given them a good product and it came out quickly.

- Steve</description>
		<content:encoded><![CDATA[<p>If it&#8217;s something revolutionary, perhaps *both* quick and quality are important.  A new startup can&#8217;t afford to either alienate customers because their product was trash, nor can it afford to not to get to the market first.</p>
<p>The way to do it is fairly simple: make your initial product simple.  Focus on the direct problem at hand, and ignore the rest.  Create a limited-feature set, but fairly solid product.  Then in your updates you can add the new features.  The side-effect of this is you make your customers happy.  They bought your product for the functions it did do, and now you&#8217;re adding more value to their purchase.</p>
<p>And, you&#8217;ve given them a good product and it came out quickly.</p>
<p>- Steve</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: B.B. @ TI</title>
		<link>http://www.embeddedinsights.com/channels/2011/03/23/which-is-better-faster-or-quality-to-market/#comment-5901</link>
		<dc:creator>B.B. @ TI</dc:creator>
		<pubDate>Thu, 24 Mar 2011 20:35:41 +0000</pubDate>
		<guid isPermaLink="false">http://www.embeddedinsights.com/channels/?p=492#comment-5901</guid>
		<description>It certainly depends on the product. If it is a product deployed in an environment where out-of-the-box operation is critical, obviously you would develop for that. Or even for a product that is not put into a critical environment, but rather in an environment where many products will not be updated. 

Some products are more seamless and easy to push updates to. I tend to side with faster-to-market by ways of quick iteration software development that can be bundled up and released to testing at any point in the product&#039;s lifecycle. This process also lends itself to easier product maintenance in the long term and thus higher quality software/product in the long term as well.</description>
		<content:encoded><![CDATA[<p>It certainly depends on the product. If it is a product deployed in an environment where out-of-the-box operation is critical, obviously you would develop for that. Or even for a product that is not put into a critical environment, but rather in an environment where many products will not be updated. </p>
<p>Some products are more seamless and easy to push updates to. I tend to side with faster-to-market by ways of quick iteration software development that can be bundled up and released to testing at any point in the product&#8217;s lifecycle. This process also lends itself to easier product maintenance in the long term and thus higher quality software/product in the long term as well.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Dan</title>
		<link>http://www.embeddedinsights.com/channels/2011/03/23/which-is-better-faster-or-quality-to-market/#comment-5885</link>
		<dc:creator>Dan</dc:creator>
		<pubDate>Wed, 23 Mar 2011 23:47:23 +0000</pubDate>
		<guid isPermaLink="false">http://www.embeddedinsights.com/channels/?p=492#comment-5885</guid>
		<description>Answer is very situational. 

Sometimes the first-mover advantages gives a company a big enough head start that it becomes dominant &amp; difficult to beat, even if its product is inferior. 

In other cases (e.g. life-critical medical devices) I think it&#039;s pretty obvious what factor dominates.

Some companies focus initially on time-to-market, get an advantage, and then backfill/improve their product line.

Of course, most of us in product development can relate to management that says, &quot;Yes!&quot; (Put another way: &quot;I want both!&quot;)</description>
		<content:encoded><![CDATA[<p>Answer is very situational. </p>
<p>Sometimes the first-mover advantages gives a company a big enough head start that it becomes dominant &amp; difficult to beat, even if its product is inferior. </p>
<p>In other cases (e.g. life-critical medical devices) I think it&#8217;s pretty obvious what factor dominates.</p>
<p>Some companies focus initially on time-to-market, get an advantage, and then backfill/improve their product line.</p>
<p>Of course, most of us in product development can relate to management that says, &#8220;Yes!&#8221; (Put another way: &#8220;I want both!&#8221;)</p>
]]></content:encoded>
	</item>
</channel>
</rss>
