Product Managers have the unique role of driving the development of products within a company, which has been and continues to be the source of value and wealth creation in the high technology field over the last several decades. If you are a Product Manager, here are nine ways for you to be a hero for your product development team.
One: Know the Difference between a Requirement and a Specification
A requirement describes need, while a specification describes system behavior. Requirements must drive specifications. When you find yourself looking at a specification and asking yourself “why do we need to do this?” typically you will find that the requirement was not clearly defined. To be a hero, you must know this difference and fight against specifications that don’t have clear and rationalized requirements backing them. Specifications without requirements are a waste of time.
It’s easy for Product Managers (and others) to mix this up. I think this comes from the tendency of people to think visually and focus on concrete enhancements to the product as opposed to the underlying need, which can be fairly abstract.
Two: Tell Stories about how the Product is being used
Engineers want to know that their work is valued and the best way to let them know is to tell them stories about how the product is being used. Tell them about how the key feature they worked so hard on is saving customers’ time, helping them do their jobs more effectively, helping them be more competitive, etc. Stories like this may even clue you into unintended ways the product is being used and help you preempt issues that might come up.
If you don’t have good customer stories to tell, get out of your office and talk to some customers!
Three: Take Responsibility for making Tough Decisions
Should we drop Feature A in order to make our ship date? Should we fix this critical defect and risk delivering on time? This feature should work this way, but the VP wants it done his way—what should we do?
A heroic Product Manager gets in front of issues like this and takes responsibility (and possibly a bullet) and makes a decision that is best for the company. You fight whatever political battles need to be fought and you shield the product development team if at all possible. These are the moments that define your career as a Product Manager—seek them out and take advantage of them.
Four: Help them Navigate Office Politics
Most engineers don’t like to deal with office politics (or at least the majority of ones I’ve worked with), and usually don’t have the depth of experience Product Managers have while working in a cross-functional environment. You make a living on getting things done through influence, not reporting lines, so you’ve got tremendous insight into what makes people tick. Help guide your engineers through the murky waters of office politics—even when they have to deal with their own boss!
Five: Establish a “No Broken Windows” Policy
The Broken Windows Theory implies that behavior is significantly affected by one’s environment. This theory has been used to rationalize the crime epidemic in New York in the 1980s. The idea is that something as simple as a broken window provides a “signal” that disorder is tolerable, which may escalate to trash being left out, broken bottles left on the street, vandalization, theft, etc.
This concept very much applies to product development. If you allow “broken windows” to exist like misspellings in screens and messages, misaligned user interface elements, and unhandled exceptions, you send the signal that the product is not being cared for and the quality of the product may fall off a cliff. This applies to the internal code as well—you shouldn’t tolerate “spaghetti code”, untested modules, or even deviation from naming conventions. If the product is pristine inside and out, everyone on the development team will treat the product with respect. Be sure to partner with the lead engineer to drive this policy inside the code. Be aggressive with fixing any broken windows, regardless of how small the issue might be.
Six: Understand how your Decisions impact Support and Maintenance of the Product
File this under: Not the most fun part about Product Management, but it is part of being an adult. Support and maintenance can make or break a company. It’s better to have something that is less functionally deep and easy to support and maintain than to have something ultra-flexible but impossible to support. Spend some time on technical support calls to get a sense for this. Remember that you must look at both the revenue and cost side of the equation when you make product decisions.
Seven: Help Engineers realize that the best Business Decision is not always the best Technical Decision
There will be times where you have to make decisions based on business constraints, where these decisions conflict with technical purity. One classic example: When to stop testing. Theoretically speaking, it is nearly impossible to have complete test coverage. In an extreme example, you can run user acceptance tests for every individual user your product will ever touch. If you do this, you would have significantly fewer defects once you shipped, but the problem is that you would never ship! When you make decisions like this, be clear that you’re doing so out of business necessity and acknowledge that the decision is not the best technical one.
Eight: Get them all the Tools they need to Succeed
Nothing is more frustrating than being tasked to do something and not having the right tools to do the job. A heroic Product Manager goes to battle—begging, borrowing, and stealing in order to get his or her team these tools. Use your influence and political savvy to get what you need. If you have the privilege to work on a high-visibility project, use this opportunity to pressure management to give you the resources you need to succeed.
Nine: Challenge them to build Something Special
We all want to be a part of something special. For those of us in high technology fields, we are working in exciting times. The speed of innovation is tremendous and we have the opportunity to reach so many people and positively affect so many lives. Use this opportunity to inspire your product development team to build something special—something they can look back on and be proud to say that they were a part of it.