<?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: Pain points vs. Requirements</title>
	<atom:link href="http://productmanagementtips.com/2007/11/21/software-productmanager-requirements/feed/" rel="self" type="application/rss+xml" />
	<link>http://productmanagementtips.com/2007/11/21/software-productmanager-requirements/</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: Software product manager’s first 30 days at a new job …. &#124; DumasLab</title>
		<link>http://productmanagementtips.com/2007/11/21/software-productmanager-requirements/#comment-2622</link>
		<dc:creator><![CDATA[Software product manager’s first 30 days at a new job …. &#124; DumasLab]]></dc:creator>
		<pubDate>Sun, 30 Jan 2011 17:25:47 +0000</pubDate>
		<guid isPermaLink="false">http://gopalshenoy.wordpress.com/2007/11/21/pain-points-vs-requirements/#comment-2622</guid>
		<description><![CDATA[[...] are the pain points that exist in this mar­ket that cus­tomers are will­ing to [...]]]></description>
		<content:encoded><![CDATA[<p>[...] are the pain points that exist in this mar­ket that cus­tomers are will­ing to [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Andy Fields</title>
		<link>http://productmanagementtips.com/2007/11/21/software-productmanager-requirements/#comment-1445</link>
		<dc:creator><![CDATA[Andy Fields]]></dc:creator>
		<pubDate>Sat, 05 Dec 2009 04:09:20 +0000</pubDate>
		<guid isPermaLink="false">http://gopalshenoy.wordpress.com/2007/11/21/pain-points-vs-requirements/#comment-1445</guid>
		<description><![CDATA[You&#039;ve summed up the point of my brand PainPoint!

-Andy Fields
www.twitter.com/PainPoint]]></description>
		<content:encoded><![CDATA[<p>You&#8217;ve summed up the point of my brand PainPoint!</p>
<p>-Andy Fields<br />
<a href="http://www.twitter.com/PainPoint" rel="nofollow">http://www.twitter.com/PainPoint</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Roger L. Cauvin</title>
		<link>http://productmanagementtips.com/2007/11/21/software-productmanager-requirements/#comment-418</link>
		<dc:creator><![CDATA[Roger L. Cauvin]]></dc:creator>
		<pubDate>Fri, 16 May 2008 14:16:50 +0000</pubDate>
		<guid isPermaLink="false">http://gopalshenoy.wordpress.com/2007/11/21/pain-points-vs-requirements/#comment-418</guid>
		<description><![CDATA[You&#039;re right about the temptation to jump into solutions without fully understanding the problem you&#039;re trying to solve.  It&#039;s a tendency in life and not just in product development.

It&#039;s just a semantic point, but many of us like to say that requirements should be free of design.  Under this terminology, once we get into specifying solutions, we&#039;ve done some design and are therefore not doing requirements.

For this reason, I say that a &lt;a href=&quot;http://cauvin.blogspot.com/2005/06/definition-of-requirement.html&quot; rel=&quot;nofollow&quot;&gt;requirement merely restates a problem you&#039;re trying to solve, but in terms of the least stringent conditions that must hold to solve or avoid the problem&lt;/a&gt;.

So if the problem or pain point is

&quot;Users can&#039;t make phone calls from my car.&quot;

The requirement is

&quot;It shall be possible for users to make phone calls from their cars.&quot;

This example is oversimplified, but hopefully you get the point.

Next, product designers can specify that the product will be a cell phone with certain features, but then it&#039;s a design specification.]]></description>
		<content:encoded><![CDATA[<p>You&#8217;re right about the temptation to jump into solutions without fully understanding the problem you&#8217;re trying to solve.  It&#8217;s a tendency in life and not just in product development.</p>
<p>It&#8217;s just a semantic point, but many of us like to say that requirements should be free of design.  Under this terminology, once we get into specifying solutions, we&#8217;ve done some design and are therefore not doing requirements.</p>
<p>For this reason, I say that a <a href="http://cauvin.blogspot.com/2005/06/definition-of-requirement.html" rel="nofollow">requirement merely restates a problem you&#8217;re trying to solve, but in terms of the least stringent conditions that must hold to solve or avoid the problem</a>.</p>
<p>So if the problem or pain point is</p>
<p>&#8220;Users can&#8217;t make phone calls from my car.&#8221;</p>
<p>The requirement is</p>
<p>&#8220;It shall be possible for users to make phone calls from their cars.&#8221;</p>
<p>This example is oversimplified, but hopefully you get the point.</p>
<p>Next, product designers can specify that the product will be a cell phone with certain features, but then it&#8217;s a design specification.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

