A Product Manager By Any Other Name...Still Writes Requirements

When I was younger, I used to care a great deal about people's titles. Maybe it was my little brain's way of organizing people like I organized my Tinkertoys (teachers go over here, doctors are over here, mommies are in this section...). In any case, I believed that a person's title told you all that you needed to know about him or her. I had grand plans for my own title when I grew up. I decided to be a "Professional." "A professional WHAT?" I'd often get asked, and I'd simply reply, "Oh, I don't know yet -- but whatever it is, I want to be a PROFESSIONAL at it." The work didn't matter, but the title did.

Many people, as I did, place a great deal of emphasis on titles. On the Seilevel message board there are multiple threads discussing the differences between Business Analysts, Requirements Analysts, Product Managers, Project Managers, Systems Analysts, and even humorous entries like Requirementers, Information Vigilantes and 'Shall'icitors. In my career I've held the titles of Program Manager, Requirements Analyst, Manager of Requirements Management (say that three times fast), Business Systems Analyst, and Product Manager. I've done pretty much the same work in all of those jobs. Instead of worrying about what my business card says, I focus on doing my job well.

A recent example shows how other people may not share my perspective. During lunch a few weeks ago, a friend was describing someone he works with. "She's a 'Product Manager,' whatever the heck THAT is," my friend chuckled. But did she do her job well? Did she help build great solutions to difficult problems? I don't know, because my friend "checked out" once he got to her title. To him, the title might have sounded silly, or been unfamiliar, or been tainted by previous experiences with sloppy Product Managers, but it was all he knew of her. By focusing on her title, he had lumped his co-worker (and me, although he didn't know it) in with the rest of the silly or sloppy people he knew.

So what DOES a Product Manager (PDM) do? Product Managers outside IT typically focus on understanding their marketplace and seeing that successful products are developed and released to that marketplace. Within IT, a PDM has a similar role. He or she is responsible for the end user adoption of and satisfaction with a product. The PDM is also responsible for the return on investment of that product.

In IT, a product may be anything from shrink-wrapped software to customized tools created for use within an organization. The PDM defines or identifies the scope of the program, project or release by understanding it in relation to the related business objectives. The PDM elicits, models, defines, documents, reviews and baselines requirements. She or he also manages changes to the requirements, supports and often participates in user acceptance testing, and supports product rollout and adoption activities.

All of these responsibilities help ensure that the product released meets both the business objectives and the users' needs. Given the wide range and financial impacts of a PDM's responsibilities, what does it mean to do that job WELL? To me, the most important aspect of being a great PDM is taking ownership of and pride in your product. If you believe and act as though you will personally make this product a success, you will do a good job as a PDM. If others are getting frustrated with your constant involvement, your probing questions, and your unwavering focus on product success, you're on the right track!

Whether you're a PDM, Business Analyst, Requirements Analyst, or some other flavor of requirements professional, don't let the debate over titles distract you from doing a fantastic job. After all, it's your work that matters, not your title.