Within every organization, there lies a community of individuals practicing the activities of product management.  These people have all kinds of titles and come from various organizations. Normally, this group functions well enough; each working within its specialized roles and responsibilities.

Lately, a lot is being said about the culture of product management, and if there was one thing that most product management cultures have in common, it would be an ad-hoc structure. This is a consequence of how the product management group evolved in the first place. Most of the constraints your product management team is facing today are due to this ad-hoc structure. If your team wants to break these performance constraints, they'll have to transition from an ad-hoc community, to a formal community of practice (CoP) for product management.

Let's imagine that your product management organization is conversion constrained. This means that you can gather plenty of market evidence, and come up with lots of ideas for product initiatives. The problem is, you have difficulty converting ideas into product concepts. Typically this means that you're having problems in opportunity definition, feature definition, and/or roadmap definition.

Let's further say that after studying the constraint, your innovative team has come up with some new product management knowledge. Yeah! Yes yeah. It's celebration time, you and your team have every right to want to celebrate. But just as you get out the red solo cups, issues begin to appear.  I refer to these as innovation adoption hurdles.

After this new knowledge is created, you'll need to construct new language concepts. In a formal community of practice (CoP) this is accomplished with CoP activities specifically designed to facilitate this objective. In an ad-hoc environment you have nothing but the social click that the specific innovators belong to. If you're lucky, that click will come up with accessible names that make it so others can share in the new language. Normally, this is considered a bad practice for a whole slew of other reasons (but always fail to identify the real reason of an ad-hoc community) and code names are used, so even if someone overheard a discussion at the water cooler, the new language concepts couldn't spread.

The next hurdle to overcome is the exploration hurdle. In an ad-hoc community, exploring, experimenting, and prototyping new concepts is typically limited to a very small group of individuals. In a formal community, specific activities designed to support and control this exploration are used so that a much wider base can participate in the informal and formal exploration of the concepts. This results in the innovation of concepts that spans multiple disciplines and/or organizations. The entire product management team's experience can be leveraged in a formal CoP.

Finally, the last innovation hurdle is the recognition and legitimization of the new concept by the product management team. Of course by now you're tired of hearing it, but ... in formal CoP activities there are activities specifically designed to accomplish this objective; not so with the ad-hoc community. With the ad-hoc situation, we wait until the alpha male acknowledges your validity before others can benefit from the new knowledge.

As you can see, the competitive advantage goes to the most efficient community, which isn't an ad-hoc community by a long mile.

But wait, there's more. So far, I've only addressed the innovating practice, that of legitimizing new concepts. Now, how do we help others learn the things we've learned so that they can leverage our new knowledge into yet more innovative ideas? In an ad-hoc community, it's very difficult. There is no channel for others to use to access new product management knowledge. Of course, in a formal CoP there are activities specifically designed to accomplish this objective.

In a formal CoP, there are activities specifically designed to provide understanding to the new concepts, opportunities to put the new concepts into active use and develop opportunities to share experiences and new knowledge with others, and activities designed to recognize members as insiders of the product management team. This is referred to as the Learning Practice.arning Practice. Each practice is required for the type of sustainable innovation required from a product management team. Ad-hoc cultures just can't support this demand.