For organizations that don’t already appreciate the value of product management, just trying to explain the role can be very challenging. Usually the “strategic product management” responsibilities are distributed throughout the org. Convincing them that a single person should be a product manager (and not also a marketer, project manager, or designer) is like convincing them to eat gum off a fork.
People management / Requirements / Requirements gathering
Posted on:
Mozilla Director of Product Management Blog
The director of product management at Mozilla (makers of firefox) has started a blog, Sherman’s Blog, about how Mozilla approaches product management. From the first post on the Role of Product Management by (Mr.?) Sherman, I think this blog is likely to be one to watch.
Product Management / Requirements / Requirements gathering
Posted on:
Brainstorming Stirs the Pot
The Wall Street Journal apparently wrote a critique of brainstorming that questions its value. Bob Sutton (professor, author, etc) responds with an entertaining read. Prof. Sutton critiques the data analysis, the experiment execution, and the people involved. Seems the WSJ messed up on everything except the topic.
Communication / Consulting / Product Management
Posted on:
Guerilla Product Management
*(scroll to the bottom and come back) Guerilla Product Management (pdf) is an article available from Sequent Learning Networks, written by Steven Haines. (Hat tip to brainmates for finding it) Steven’s pdf includes 17 golden rules for achieving product management success(no, we won’t do 17 articles on each of them). […]
Product Management / Requirements / Software requirements specification / Writing
Posted on:
Writing Passionate Requirements
One of the ten big rules of writing a good MRD is writing passionate requirements. What in the world is a passionate requirement [they were all wondering]? When you believe in the product, are committed to the work, and aren’t bored, you can write passionately. The goal of a requirement is to create sustained understanding. A dry document can create understanding, but an engaging document will sustain it.
Product Management / Requirements / Software requirements specification / Writing
Posted on:
Writing Atomic Requirements
One of the ten big rules of writing a good MRD is writing atomic requirements. Just as verifiable requirements must be concretely measurable as having been met or not, so must atomic requirements. If a requirement has multiple elements that can be implemented separately, it is not atomic.
Product Management / Requirements / Software requirements specification / Testing / Writing
Posted on:
Writing Verifiable Requirements
One of the ten big rules of writing a good MRD is writing verifiable requirements. Verification is both a function of having a precise goal, and having the ability to affordably measure the requirement. A precise goal is a verifiable requirement if we can clearly answer “yes” or “no” when asked if the requirement has been implemented. We also face the practical realities of being able to measure the results profitably.
Outsourcing / Product Management / Requirements / Software requirements specification / Writing
Posted on:
Writing Unambiguous Requirements
One of the ten big rules of writing a good MRD is writing unambiguous requirements. Ambiguity is a function of communication. The writing can be generically ambiguous, or ambiguous to the writer. A requirement could be precise in intent, but ambiguous in interpretation by the reader. Understanding our audience is as important as precision in language. We write unambiguous requirements because misinterpretation of requirements is the source of 40% of all bugs in delivered software.
Product Management / Requirements / Software requirements specification
Posted on:
Writing Consistent Requirements
One of the ten big rules of writing a good MRD is writing consistent requirements. Consistency within an MRD has two dimensions that are important to requirements – logical consistency and grammatical consistency. There is also the element of writing an MRD that is consistent with other documentation – external consistency.