This inbound team of heavily technical product managers was responsible for the 2-3 year product roadmap for the company. As a result, their main constituents were the entire engineering community and, more specifically, the software and hardware architects interspersed through that community.
Success Factor
Inside the organization, individual product managers acted as subject matter experts (SMEs) in the various disciplines that made up the software/hardware product suites sold by the company. One of the individual deliverables was the product requirement—that ubiquitous, yet fuzzy, essence of the product manager’s analysis, insight and judgment of what an engineering team needs to focus on for profitable product delivery.
The 12 Blind Men Around the Elephant Problem
The feedback from the engineering team was the typical “we cannot understand what these mean” and “we can’t measure that” response. Product managers management, when faced with this response and the lack of acceptance, realized that they really had no way to judge the quality of a requirement themselves.
Further, they realized they had no way to provide formal guidance or feedback in the form of performance reviews or other HR-oriented methods for PM ranking and motivation.
A Rubric? Isn’t that a Cube Game?
Remember writing term papers in high school? Let’s apply a well-known technique your English teacher used to determine a grade: The Rubric.
Rubrics can be created in a variety of forms and levels of complexity. However, they all contain common features which:
- focus on measuring a stated objective (performance, behavior, or quality);
- use a range to rate performance; and
- contain specific performance characteristics arranged in levels indicating the degree to which a standard has been met.
Let’s take a look at how one might be built to evaluate a product requirement. (Source: www.sdsu.edu).
Here, we have a list of characteristics, which are examples of the Immutable Laws of Requirements. In the case above, we have three levels of observable qualitative characteristics that can be applied to a product requirement (or groups taken together).
Note that an optional point system has been assigned to each level. Generally, I’ve found that using hard numbers tends to produce too much focus on the absolute score rather than the overall message a rubric can provide.
Next, the blank columns allow a summing and weighting function. Drop the numbers scores and you can do away with the summing function. The weighting function, however, can be used to assign relative weight to each of the Immutable Laws, based on the judgment of PM management.
So, how do we apply it? Generally, the rubric is built in collaboration with the engineering community. This ensures your team understands that the rubric represents guidance by the engineering community for acceptable product requirements.
How did it work for the organization mentioned at the beginning of this post? Pretty well.
Understand that many of the product managers had come from engineering and found the discipline of writing objectives and concise product requirements more difficult than they originally thought—even with their former engineers now sitting on the other side of the table!
Product manager management, however, now had a tool to help develop more disciplined, quality requirements and raise overall PM credibility across the entire engineering community.
The discipline of Product Management is in the details. By using the well-known Rubric method, you can offer your product managers more guidance on what you expect from them. If you would like to know more, contact me and I’ll be glad to discuss your situation in detail.
* Attributes: Immutable Laws of Requirements: www.EgressSolutions.net