Comments on: Product Mangers Need A Dictionary In Order To Make Money http://www.theaccidentalpm.com/communication/product-mangers-need-a-dictionary-in-order-to-make-money Home Of The Billion Dollar Product Manager Where You Too Can Learn To Be A Wildly Successful Product Manger Mon, 15 Mar 2010 04:03:05 +0000 http://wordpress.org/?v=abc hourly 1 By: Trevor Rotzien http://www.theaccidentalpm.com/communication/product-mangers-need-a-dictionary-in-order-to-make-money/comment-page-1#comment-531 Trevor Rotzien Fri, 10 Apr 2009 04:25:33 +0000 http://www.theaccidentalpm.com/?p=559#comment-531 Jim, Excellent point regarding design conflicts. This particular problem is an entire study area of its own in software engineering and application development; too broad a subject to get into here. Suffice it to say that the earlier in a project there is conceptual alignment, the more positive the impact, but few project teams recognize the initial lexicon as having the risk management value that it has. Jim,

Excellent point regarding design conflicts. This particular problem is an entire study area of its own in software engineering and application development; too broad a subject to get into here. Suffice it to say that the earlier in a project there is conceptual alignment, the more positive the impact, but few project teams recognize the initial lexicon as having the risk management value that it has.

]]> By: Dr. Jim Anderson http://www.theaccidentalpm.com/communication/product-mangers-need-a-dictionary-in-order-to-make-money/comment-page-1#comment-523 Dr. Jim Anderson Fri, 10 Apr 2009 00:36:20 +0000 http://www.theaccidentalpm.com/?p=559#comment-523 Trevor: those are some very good points. One to add to your list is when you have two (or more) competing designs and although everyone agrees on where they want to get to, it's the HOW that is not clear. Having two design teams working on their own approach as part of the same team can cause huge issues later on... Trevor: those are some very good points. One to add to your list is when you have two (or more) competing designs and although everyone agrees on where they want to get to, it’s the HOW that is not clear. Having two design teams working on their own approach as part of the same team can cause huge issues later on…

]]> By: Trevor Rotzien http://www.theaccidentalpm.com/communication/product-mangers-need-a-dictionary-in-order-to-make-money/comment-page-1#comment-516 Trevor Rotzien Wed, 08 Apr 2009 21:20:45 +0000 http://www.theaccidentalpm.com/?p=559#comment-516 Excellent topic. There are two ways (that I have encountered working as a project debugger, consultant and Product Manager) that false consensus can arise in groups: 1. Passive aggressive agreement in which participants pretend to agree for various social and psychological reasons (See discussion of the The Abilene Paradox here: http://bit.ly/cnb8y) 2. What I call "Gratuitous Agreement" in which participants nod their heads at the same word, only to separate to begin work on their tasks with fundamentally different definitions of that one term in their heads. This isn’t dealt with, not because of dishonestly, but a shared assumption that syntactic agreement = semantic agreement. This isn't necessarily a big deal, except when the term in question relates to the core approach and/or deliverable of a project! I’d be very interested in other causes false consensus that others can share. Shared lexicons, that force the multiple roles and tribes in a project to agree on precise term definitions can be tedious to construct, but often the very construction effort surfaces important misunderstandings and contending conceptualizations well before they can become dangerous. Excellent topic.

There are two ways (that I have encountered working as a project debugger, consultant and Product Manager) that false consensus can arise in groups:

1. Passive aggressive agreement in which participants pretend to agree for various social and psychological reasons (See discussion of the The Abilene Paradox here: http://bit.ly/cnb8y)

2. What I call “Gratuitous Agreement” in which participants nod their heads at the same word, only to separate to begin work on their tasks with fundamentally different definitions of that one term in their heads. This isn’t dealt with, not because of dishonestly, but a shared assumption that syntactic agreement = semantic agreement. This isn’t necessarily a big deal, except when the term in question relates to the core approach and/or deliverable of a project!

I’d be very interested in other causes false consensus that others can share.

Shared lexicons, that force the multiple roles and tribes in a project to agree on precise term definitions can be tedious to construct, but often the very construction effort surfaces important misunderstandings and contending conceptualizations well before they can become dangerous.

]]>