Product Management Rule #11 from the best-selling book, 42 Rules of Product Management, was written by Jim Reekes, Senior Principal Consultant, Productside:
The only surprise a product manager should give anyone is, “Hey, we blew away our forecast!” The type of surprise you never want is, “WTF!?”
Consider your Market Requirements Document (MRD).
It can be filled with surprises, and I mean that in a bad way.
Before you hand it to your engineering group, talk to them about it. Before writing your ideas down, share them in person. Tell the team what (and how) you’re thinking. Ask them what format works best. Do they prefer story mode or tables with rows of categories, priorities, sources, etc.? Do they understand the difference between “shall” and “should,” or my preference of “must” and “may”?
I mention that last one because I was once surprised when half way into the development cycle engineering decided not to implement a requirement I had listed as a “shall.” When I asked how could they drop an absolute requirement, they argued with me about—I’m not kidding—the definition of “shall.” WTF? I reminded them when Moses came down from the mountain with those Ten Commandments they were not nice-to-haves—they were absolutes written as “You shall.”
As you are writing the MRD, talk through the ideas informally with them, clarifying the customer’s need and why it is important. If you deliver a document loaded with surprises, they will not take ownership of it and may not support your efforts (or worse, may simply ignore it). Even before submitting your first draft of the MRD, all of your readers should (no, make that “shall”) have heard of its contents from you firsthand. This goes for all of your stakeholders (customers, salespeople, support, engineering, marketing, management, etc.)
Be transparent with everyone on how you gather and prioritize requirements.
Explain your method of prioritization.
Many times people just want to know their ideas are being considered. If you reassure them and show them that you have a logical way of capturing and prioritizing, they will be much more accepting if their feature doesn’t make in.
When attending or running meetings that include a potential bad surprise, especially with people who have strong opinions, always float those ideas by them beforehand. Phrase the idea in the form of a question and ask what they think (engineers love to think). They’ll likely be so engaged with explaining everything down to the minutiae that they’ll not realize you’re pandering to their intellect. It’s like Judo. They want to look smart (and make you feel dumb). The idea of no surprises also includes avoiding the risk of blindsiding the person in a public setting with something that might be a sensitive. If you surprise them in a meeting this way, there’s no predicting what could happen. You don’t want this to happen.
I shouldn’t have to mention this, but it happens way too many times not to highlight it. The biggest source of surprises (and abuse) is email. Email is a great tool, but the tone and content can easily be misinterpreted. It is always better to talk live with a person to avoid misunderstandings.
Lastly, and most importantly, don’t surprise anyone about what your role actually is.
This is usually a big surprise and a bad one.
There’s a long list of responsibilities for a product manager, and few people understand them. They probably think they own some of that list. Be clear on what you do and don’t do with everyone, and evangelize this. If they don’t have a good understanding of how you view your job and priorities, they may have expectations that are very out of line and it can cause bad surprises.
