The Role of a Product Manager

My resume says I’m a product manager. But that’s a change only seen in the last 2 years. It took me a while to understand where I fit into the long term scheme of all the companies I worked with, in, or for.

It wasn’t until I lived in Germany that I could proudly wear the title of Product Manager (or CPO, or Head of Product, whatever you want to call it) and feel safe that no one would call me out for a hack). Germans have embraced the idea of a Product Manager (PM) for a long time (meanwhile in the US we’re much more focused on the CTO and CEO until only recently, and still I feel it’s a title reserved for companies with larger infrastructure).

For that reason, while in the US, I always felt I was making up a title whenever I explained what I did to people while still back in the the States. Whether in a job interview, party, or networking event, most of the time “Technology Management” or “Interactive Technology Manager” usually did the job, as long as I conveyed that I bridged the gaps between business objectives and technical projects.

An elevator pitch style sentence that I’ve probably had memorized by accident for the last 6 years was: “I respect the needs of the business and know make sure their ideas are described with wireframes, designs, user stories, and technical detail”. Which usually is followed by explaining that I know enough about the technology to communicate the requirements of each feature, bug, product, etc to the developers, while being sympathetic to the reality of each task put before them. And then I have the job of explaining to people with business and UX (user experience) requirements when and how technical products can be delivered and why it’s not going to happen overnight (usually).

If I could make a venn-diagram, or comic strip to illustrate the PM better, the following statement of each party would somehow fill their comment bubble, or comment in that visual:

Business: “I need a new landing page to sell product, but don’t waist tons of resources building it, of yeah if it’s ready by tomorrow that would be awesome.”

Marketing: “We need tweaks on the funnel to optimize conversions, and there are new tags too”

Programmers: “The technology needs to be stable and consistent, it’s going to take longer” (sub-text: you’re giving us too many things to think about)

User Experience & Front End: “The experience should be fluid, beautiful, and utilize the best in class technology”

QA: “There are serious issues to fix still, it’s killing the experience and probably killing conversions”

Product Manager (right in the middle of it all): “I need to make all of this happen, with the best outcome possible”

As such an illustration would show, what’s important about a product manager is he/she sits in the middle of the technology, the customer, and the business. Whether a team is a guy who is thinking about sales and marketing all day, and another guy who is programming database queries or  HTML/CSS interfaces, or it’s made of a front end engineer, a programmer, a QA test manager, sales managers, an SEO consultant a the CEO. The job the product manager has is to bring it all together; to understand what each entity of the company needs, what the limitations are, and to make sure each other understand the constraints of the other team members’ needs.

Ex: If sales needs to have a new landing page with lead submission form live by Wednesday, then:

  • programmers, and front end guys need sales to understand the bugs they are working on will take a back seat which could hurt the business more than benefits of the new lead form.

If a front end developer thinks she can get this form up without any backend programming – to short cut the programming that would have to be done by the programmer – thus allowing sales to move forward while the programmer solves a critical bug, then:

  • the sales guy needs to understand the programmer will likely still want to modify the lead form later on so all the technology is built consistently (which means there really wasn’t a short cut you just used the front-end dev’s time before the back end guys were ready, which may ultimately cost more development time overall since the backend folks probably wont like the front end work around).

If the various members of the team are all on different planets(and they usually are to some degree), things can feel nuts, and the PM will likely resemble a guidance counselor, easing the anxiety and mitigation conflicts, more than a person who gets things done.

The PM has to understand the needs of each member of his team, make sure the best solution is achieved and the end product result is ideal for the business. Sometimes this means pushing back for more testing and cross platform support, others it means cooling off an over aggressive sales & marketing endeavor which is undermining the quality of the product.

What all of this also means is, if any member of the team is not there (as in it doesn’t exist) the product manager should fill that seat, and make sure those issues are represented.

  • If the CEO doesn’t understand online marketing, the PM will likely fill this seat.
  • If there aren’t enough engineers in house, the PM may need to pitch in here if he can or find a way to close the gap.

Truly a wearer of all hats, yet the most under celebrated of all, the Project Manager is the unicorn – a rare find. But it is an invaluable asset in any team that doesn’t strike a clean balance between the skills of each team member especially with startups, because usually, when starting small and with beginners minds, the improvisation and solution making tactics of a PM smoothes out the kinks as they come, and there are always kinks.

 

Leave a Reply

Your email address will not be published. Required fields are marked *