Comments on: Track customer requests appropriately http://www.goodproductmanager.com/2007/02/12/track-customer-requests-appropriately/ A blog with tips on product management and related topics. Written by Jeff Lash, a product manager in St. Louis, MO Sun, 07 Mar 2010 10:14:56 -0800 http://wordpress.org/?v=2.9.2 hourly 1 By: Harry Nieboer http://www.goodproductmanager.com/2007/02/12/track-customer-requests-appropriately/comment-page-1/#comment-77 Harry Nieboer Sun, 25 Feb 2007 21:20:06 +0000 http://www.goodproductmanager.com/2007/02/12/track-customer-requests-appropriately/#comment-77 A clear naming convention helps to decide what’s in the next release, and what’s not. e.g. whent your next release is called "Usability release", wou would not want to include new functionality in that release. Actually, the convention fits nicely in the way releases should be handled within RUP. For every release a problem statement and a product position statement are developed AND agreed upon between all stakeholders of the project. The problem statement is a solution-neutral summary of the stakeholders’ shared understanding of the problem to be solved. The product position statement is the “mission statement” for the system to be built (the solution). The product position statement is a vehicle for communicating a brief definition of the system to all stakeholders (definitions from safari). The problem statement and the product position statement are excellent tools to use in the CCB (Change & Control Board) who decides on including or excluding new features in the (next) release. Both statements are documented in the RUP Vision document. If you have a hard time defining these statements, you will definitely have a hard time with scope-creep. Now you see why! For more on this subject, see: http://hij2mc.wordpress.com/2006/08/21/handling-feature-creep-on-your-next-release/ A clear naming convention helps to decide what’s in the next release, and what’s not.

e.g. whent your next release is called “Usability release”, wou would not want to include new functionality in that release.

Actually, the convention fits nicely in the way releases should be handled within RUP. For every release a problem statement and a product position statement are developed AND agreed upon between all stakeholders of the project.

The problem statement is a solution-neutral summary of the stakeholders’ shared understanding of the problem to be solved.
The product position statement is the “mission statement” for the system to be built (the solution). The product position statement is a vehicle for communicating a brief definition of the system to all stakeholders (definitions from safari).

The problem statement and the product position statement are excellent tools to use in the CCB (Change & Control Board) who decides on including or excluding new features in the (next) release. Both statements are documented in the RUP Vision document.

If you have a hard time defining these statements, you will definitely have a hard time with scope-creep. Now you see why!

For more on this subject, see: http://hij2mc.wordpress.com/2006/08/21/handling-feature-creep-on-your-next-release/

]]> By: Carfield Yim http://www.goodproductmanager.com/2007/02/12/track-customer-requests-appropriately/comment-page-1/#comment-63 Carfield Yim Wed, 14 Feb 2007 09:27:00 +0000 http://www.goodproductmanager.com/2007/02/12/track-customer-requests-appropriately/#comment-63 Very good inspection! Very good inspection!

]]>