The Productologist

One of my goals for this year is to establish Product Councils for my products. Product Councils, or Product Advisory Boards, as they are sometimes called, are made up of people who are familiar with your product and/or the market. In most cases, they are external, meaning that the members are customers or industry experts who can provide strategic guidance or provide feedback on tactical implementations, but they can also be made up of, wholly or in part, internal members.

I plan to have two; one made up of internal team members and one made up of customers. Both are necessary to help me grow the product to meet the needs of the market.

I wrote a comment the other day on another blog, Security Buddha, in response to a post about how Product Managers (at least not the ones who write blogs) are not really geared for rapid product release cycles. The author had reviewed several Product Management blogs, including this one, and came to this conclusion–

“I can’t help feeling that most of the PM gurus are cut out for old school software development with long release cycles and would balk at the real meaning in the Agile Manifesto.”

My comments on Security Buddha went something like this (paraphrased, but you can see the original here):

Bug scrub is a word that strikes fear and hatred into the hearts of many Product Managers (Developers, QA leads, Release Managers, and Project Managers, too). Not because of the purpose of bug scrub–dispositioning recently filed product defects–but because the process behind the purpose can end up being so heinous and painful.

For the uninitiated, the Cranky Product Manager provides a valuable, albeit hyperbolic glimpse inside the bug scrub process. She highlights the frequent discord and conflicting interests that makes bug scrub such an ordeal and one that all-to-frequently ends up being internally-focused rather than customer- or market-focused.