<?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: Tips For Buying and Selling Enterprise Software</title>
	<atom:link href="http://blog.jvroom.com/2009/10/29/tips-for-buying-and-selling-enterprise-software/feed/" rel="self" type="application/rss+xml" />
	<link>http://blog.jvroom.com/2009/10/29/tips-for-buying-and-selling-enterprise-software/</link>
	<description>Topics on efficient software, Java, Flex</description>
	<lastBuildDate>Thu, 09 Feb 2012 04:14:55 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.com/</generator>
	<item>
		<title>By: jeffvroom</title>
		<link>http://blog.jvroom.com/2009/10/29/tips-for-buying-and-selling-enterprise-software/#comment-47</link>
		<dc:creator><![CDATA[jeffvroom]]></dc:creator>
		<pubDate>Sat, 07 Nov 2009 18:04:21 +0000</pubDate>
		<guid isPermaLink="false">http://blog.jvroom.com/?p=39#comment-47</guid>
		<description><![CDATA[Hi Cornel,

Thanks, I&#039;ll try to keep the posts coming.   I totally agree this could be taken too far and swamp engineering.  Both support and engineering need good filters to differentiate product bugs from customer bugs and features/support for a specific customer.   You also need to look at the customer and judge them... a good customer will usually be successful and help you make the product successful.   A customer who is not as skilled may cause unnecessary churn and ultimately fail themselves so not helping you out in the long run.  Another reason a product sold by a slide-deck and not solid engineering may prove difficult to monetize long term - as a business, it attracts the wrong kind of customers.]]></description>
		<content:encoded><![CDATA[<p>Hi Cornel,</p>
<p>Thanks, I&#8217;ll try to keep the posts coming.   I totally agree this could be taken too far and swamp engineering.  Both support and engineering need good filters to differentiate product bugs from customer bugs and features/support for a specific customer.   You also need to look at the customer and judge them&#8230; a good customer will usually be successful and help you make the product successful.   A customer who is not as skilled may cause unnecessary churn and ultimately fail themselves so not helping you out in the long run.  Another reason a product sold by a slide-deck and not solid engineering may prove difficult to monetize long term &#8211; as a business, it attracts the wrong kind of customers.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Cornel</title>
		<link>http://blog.jvroom.com/2009/10/29/tips-for-buying-and-selling-enterprise-software/#comment-46</link>
		<dc:creator><![CDATA[Cornel]]></dc:creator>
		<pubDate>Fri, 06 Nov 2009 20:29:46 +0000</pubDate>
		<guid isPermaLink="false">http://blog.jvroom.com/?p=39#comment-46</guid>
		<description><![CDATA[Hi Jeff,

You should post more often...it&#039;s really interesting, and unfortunately there are not too many senior engineers having blogs. 
I completely agree with the direct communication between engineers and customers when dealing with bugs, without scary formal processes. On my previous job I also used quite successfully this approach with good results. The only mention is that the developers should be taught how to discuss with bully customers.]]></description>
		<content:encoded><![CDATA[<p>Hi Jeff,</p>
<p>You should post more often&#8230;it&#8217;s really interesting, and unfortunately there are not too many senior engineers having blogs.<br />
I completely agree with the direct communication between engineers and customers when dealing with bugs, without scary formal processes. On my previous job I also used quite successfully this approach with good results. The only mention is that the developers should be taught how to discuss with bully customers.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

