PM's responsibility #5: Authorize Feature Releases

A week ago we had a funny interchange with our director of engineering. He moved a Trello card to "Done" column, I moved it back to "Review & Testing", then he moved it back to "Done" and I moved it again to "Review & Testing". Finally, he moved it to "Done" column yet again and wrote me:

I've moved the card to "Done" column. We've tested everything end-to-end already two times. Don't you trust me?

My answer to him was that I expect engineers to test everything twice anyway before declaring something completed and passing the buck to me. But to me the feature is "Done" only when also a product manager thoroughly tests it and looks at it through the eyes of the end user if the feature works as expected and if it matches the requirements.

Once the final testing of a feature is over and the product manager verifies that a feature matches users' needs, the product manager is almost ready to authorize feature release. But before doing so, he or she must verify with all the users of the product that releasing the feature in the wild won't interfere with their workflows. Since different users have different levels of sensitivity to change, it's very helpful if product enables staged releases thru feature toggles that can be set per user. This enables release of the feature first internally, then to friendly (beta) users, and to all the users only when everything is fully vetted.

The product manager is ultimately responsible for feature behavior, performance, operation, and consequences. Until the feature is released, it at least doesn't cause any harm. But the moment the feature is released in the wild, it starts a life of its own that can either make the product manager proud or come haunting him or her for months or even years to come.

This is part of series of posts on product manager's responsibilities as we see them at Zemanta.