Comments on: Take responsibility for what, not how http://www.goodproductmanager.com/2007/02/14/take-responsibility-for-what-not-how/ 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: Jason Yip http://www.goodproductmanager.com/2007/02/14/take-responsibility-for-what-not-how/comment-page-1/#comment-12827 Jason Yip Fri, 26 Sep 2008 23:20:22 +0000 http://www.goodproductmanager.com/2007/02/14/take-responsibility-for-what-not-how/#comment-12827 Minor correction, the As a... I want to... so that, approach is not the "SCRUM approach". I first heard of it from Dan North, who I believe learned it from someone else that I can't remember at the moment. The approach was popularised by Mike Cohn's User Stories book. Mike's a Scrum guy but User Stories are really an Extreme Programming concept. Minor correction, the As a… I want to… so that, approach is not the “SCRUM approach”. I first heard of it from Dan North, who I believe learned it from someone else that I can’t remember at the moment.

The approach was popularised by Mike Cohn’s User Stories book. Mike’s a Scrum guy but User Stories are really an Extreme Programming concept.

]]> By: Jarretthousenorth.com » Blog Archive » Radical transparency, part 1 http://www.goodproductmanager.com/2007/02/14/take-responsibility-for-what-not-how/comment-page-1/#comment-8342 Jarretthousenorth.com » Blog Archive » Radical transparency, part 1 Sat, 03 May 2008 21:20:03 +0000 http://www.goodproductmanager.com/2007/02/14/take-responsibility-for-what-not-how/#comment-8342 [...] as has been said eloquently by others, are detail oriented and prone to micromanaging. They tend to stomp on the engineer’s turf by talking implementation and second-guessing the developer’s expertise. Worse, product [...] [...] as has been said eloquently by others, are detail oriented and prone to micromanaging. They tend to stomp on the engineer’s turf by talking implementation and second-guessing the developer’s expertise. Worse, product [...]

]]> By: Jarrett House North » Blog Archive » Radical transparency, part 1 http://www.goodproductmanager.com/2007/02/14/take-responsibility-for-what-not-how/comment-page-1/#comment-8288 Jarrett House North » Blog Archive » Radical transparency, part 1 Tue, 29 Apr 2008 20:07:18 +0000 http://www.goodproductmanager.com/2007/02/14/take-responsibility-for-what-not-how/#comment-8288 [...] as has been said eloquently by others, are detail oriented and prone to micromanaging. They tend to stomp on the engineer’s turf by talking implementation and second-guessing the developer’s expertise. Worse, product [...] [...] as has been said eloquently by others, are detail oriented and prone to micromanaging. They tend to stomp on the engineer’s turf by talking implementation and second-guessing the developer’s expertise. Worse, product [...]

]]> By: Chad http://www.goodproductmanager.com/2007/02/14/take-responsibility-for-what-not-how/comment-page-1/#comment-5459 Chad Mon, 14 Jan 2008 15:59:03 +0000 http://www.goodproductmanager.com/2007/02/14/take-responsibility-for-what-not-how/#comment-5459 While I agree 100% of a product manager's ownership of the "what" of a product, a good product manager should also take charge of the user interface, which is the only part of the "how" that they should be involved with. While I agree 100% of a product manager’s ownership of the “what” of a product, a good product manager should also take charge of the user interface, which is the only part of the “how” that they should be involved with.

]]> By: ’s blog » diigo 11/27/2007 http://www.goodproductmanager.com/2007/02/14/take-responsibility-for-what-not-how/comment-page-1/#comment-3984 ’s blog » diigo 11/27/2007 Tue, 27 Nov 2007 08:58:12 +0000 http://www.goodproductmanager.com/2007/02/14/take-responsibility-for-what-not-how/#comment-3984 [...] Take responsibility for what, not how: How To Be A Good Product Manager: Product management tips  Annotated [...] [...] Take responsibility for what, not how: How To Be A Good Product Manager: Product management tips  Annotated [...]

]]> By: ’s blog » Unnamed 11/27/2007 http://www.goodproductmanager.com/2007/02/14/take-responsibility-for-what-not-how/comment-page-1/#comment-3980 ’s blog » Unnamed 11/27/2007 Tue, 27 Nov 2007 08:46:20 +0000 http://www.goodproductmanager.com/2007/02/14/take-responsibility-for-what-not-how/#comment-3980 [...] Take responsibility for what, not how: How To Be A Good Product Manager: Product management tips  Annotated If you want to be a good product manager, focus on what requirements should be in the product in the first place. Product managers are responsible for what the product should do and other roles are responsible for how the product should do that. [...] [...] Take responsibility for what, not how: How To Be A Good Product Manager: Product management tips  Annotated If you want to be a good product manager, focus on what requirements should be in the product in the first place. Product managers are responsible for what the product should do and other roles are responsible for how the product should do that. [...]

]]> By: ’s blog » 9 11/26/2007 http://www.goodproductmanager.com/2007/02/14/take-responsibility-for-what-not-how/comment-page-1/#comment-3933 ’s blog » 9 11/26/2007 Mon, 26 Nov 2007 09:38:19 +0000 http://www.goodproductmanager.com/2007/02/14/take-responsibility-for-what-not-how/#comment-3933 [...] Take responsibility for what, not how: How To Be A Good Product Manager: Product management tips  Annotated [...] [...] Take responsibility for what, not how: How To Be A Good Product Manager: Product management tips  Annotated [...]

]]> By: Adam Bullied http://www.goodproductmanager.com/2007/02/14/take-responsibility-for-what-not-how/comment-page-1/#comment-66 Adam Bullied Wed, 14 Feb 2007 18:41:36 +0000 http://www.goodproductmanager.com/2007/02/14/take-responsibility-for-what-not-how/#comment-66 Great post, Jeff. I like to think of the "what" / "how" in a different way: write the requirements down, not the solution. Great post, Jeff.

I like to think of the “what” / “how” in a different way: write the requirements down, not the solution.

]]>