<?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: &#8220;Shut Up!&#8221; and Other Lessons Founders Should Learn from Journalists</title>
	<atom:link href="http://powazek.com/posts/572/feed" rel="self" type="application/rss+xml" />
	<link>http://powazek.com/posts/572</link>
	<description>It&#039;s pronounced poe-WAH-zek.</description>
	<lastBuildDate>Thu, 17 Dec 2009 21:26:52 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.2</generator>
	<item>
		<title>By: Lori</title>
		<link>http://powazek.com/posts/572/comment-page-1#comment-610</link>
		<dc:creator>Lori</dc:creator>
		<pubDate>Mon, 04 Jun 2007 21:16:46 +0000</pubDate>
		<guid isPermaLink="false">http://powazek.com/posts/572#comment-610</guid>
		<description>Your story of #3 was compelling (and familiar). When we do customer visits to vet ideas for new features, the hardest part is sticking to the demo presentation and probing for more detailed answers rather than trying to tell our audience about the feature that&#039;s already in the product and would save them tons of time, or trying to convince them that this new feature really WOULD solve their problem. As developers and creatives, our instinct is to solve their problems right away -- but asking &quot;why?&quot; or &quot;could you tell me more about that?&quot; in the short term gives us a better shot at solving more problems in the long term. We end up with lots of real user data to go on, rather than just guesses about how people work and what they want.</description>
		<content:encoded><![CDATA[<p>Your story of #3 was compelling (and familiar). When we do customer visits to vet ideas for new features, the hardest part is sticking to the demo presentation and probing for more detailed answers rather than trying to tell our audience about the feature that&#8217;s already in the product and would save them tons of time, or trying to convince them that this new feature really WOULD solve their problem. As developers and creatives, our instinct is to solve their problems right away &#8212; but asking &#8220;why?&#8221; or &#8220;could you tell me more about that?&#8221; in the short term gives us a better shot at solving more problems in the long term. We end up with lots of real user data to go on, rather than just guesses about how people work and what they want.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Baxter</title>
		<link>http://powazek.com/posts/572/comment-page-1#comment-605</link>
		<dc:creator>Baxter</dc:creator>
		<pubDate>Mon, 04 Jun 2007 13:56:56 +0000</pubDate>
		<guid isPermaLink="false">http://powazek.com/posts/572#comment-605</guid>
		<description>Journalism may be a good training ground for almost anything. But as a recovering journalist, I&#039;m a bit biased on that point.

If I could add one more lesson, it would be that gathering more information is a good thing. Many is the journalist who thought they had a great story (or, alternately, no story) until they gathered more information. And journalists are really good at gathering, sorting and analysing information.</description>
		<content:encoded><![CDATA[<p>Journalism may be a good training ground for almost anything. But as a recovering journalist, I&#8217;m a bit biased on that point.</p>
<p>If I could add one more lesson, it would be that gathering more information is a good thing. Many is the journalist who thought they had a great story (or, alternately, no story) until they gathered more information. And journalists are really good at gathering, sorting and analysing information.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

