If a member of the press wants to review a product, the Product Marketing Manager shall assist by providing an Evaluation Guide.
If thou does this according to THE SOFTWARE LORD’S wishes, the trade magazine just might run an article extolling to the world the virtues of your product.
Keeping in mind the lower-than-expected IQ and extreme sloth of certain members of the press, the Evaluation Guide should be written as if for your computer illiterate grandmother.
Said Evaluation Guide shall have a screenshot for each and every step, including installation.
Each step shall describe exactly what to type, what button to push, and why each step is being performed. The steps shall leave no room for misinterpretation. The reader must not be required to think at all.
Marketing messages and competitive comparisons shall be interspersed throughout the Evaluation Guide, in hope that the member of the press will directly quote your ritually pure text.
Read more Divine Rules for Product Managers.
Have the Software Gods been speaking to you as well? Have any additional Divine Rules for Product Managers you wish to share? Share them in this post comments. The Cranky Product Manager will feature the best Divine Rules as posts on this blog, with appropriate link-backs to the destination of your choosing….
View all the Divine Rules of Product Management here.
Law #2: On dealing with customers who can’t understand you don’t develop custom software just for them.
If a customer presents a detailed list of features, demands they be developed immediately, and then tries to extract firm commitments with specific dates for each feature, the Product Manager shall adroitly step around the trap as follows.
The Product Manager shall assure the customer s/he understands the issues by paraphrasing them back and sympathizing with the customer’s frustrations.
The Product Manager shall, in front of the customer, write the details of each issue, for posterity, inside a high-class notebook with gold gilded page edges.
The Product Manager shall frequently say phrases like:
- I can see why that’s important to you
- We’ll see what we can do
- I wish we had the resources to work on all these great ideas… which two are most important to you?
The Product Manager shall not definitively promise a feature will be developed nor its delivery date, unless the feature is already done, tested, and due for release within the next 2 weeks.
The Product Manager shall also take copious notes of the entire conversation and circulate these notes to the Product Manager’s boss and the customer’s account team, highlighting that NO PROMISES were made.
If thou does this according to THE SOFTWARE LORD’s wishes, the customer will calm down and perhaps take a less adversarial approach in the future. Even better, the Product Manager won’t get fired in 6 months for allegedly promising the customer something that can’t be delivered.
—————-
Have the Software Gods been speaking to you as well? Have any additional Divine Rules for Product Managers you wish to share? Share them in this post comments. The Cranky Product Manager will feature the best Divine Rules as posts on this blog, with appropriate link-backs to the destination of your choosing….
The Cranky Product Manager had a religious experience recently, where the gods of enterprise software came to her in a vision and presented her with the Laws of Product Management. Being gods, they instructed her to share these sacred Laws with y’all.
The Cranky Product Manager shall post each Law in a separate post. Eventually, when several Laws are posted, you can view them all together via the Divine Rules for Product Managers category.
Law #1: On preparing for potentially contentious meetings with Engineering
If thou plans to meet with the Engineering team, where thou suspects the Engineers will disagree with the recommended priorities for product development, then thou shall endeavor to informally meet with each member of the team individually beforehand.
Over burritos or sushi, thou shall endeavor to convince each Engineer of your point of view, describing the use cases and the research thou has done to arrive at the recommendations. Thou shalt be charming and nice and personable and actually listen for a change.
If the time allotted for lunch is too short to convince the Engineer, thou shall continue the conversation over beers after work. An official “meeting” is to be avoided.
Again, it is emphasized that thou shalt meet with everyone on the team individually, from the mightiest architect to the meekest junior engineer.
If thou does this according to THE SOFTWARE LORD’S wishes, the big meeting with the Engineering team will go smoothly and everyone will leave with common agreement as to the features and priorities of the next release.
