How to be a Product Manager

My latest read is Marty Cagan's book on how to be an effective Product Manager, Inspired: How to Create Products Customers Love.  I wanted to pick up a guide to Product Management to get an additional perspective in my internship at eBay.  This book came highly recommend by Amazon reviewers, so I thought I would give it a try.  Cagan is the head of the Silicon Valley Product Group, an organization of current and former senior product executives in tech, where he has been since 2002 after leaving his post as eBay's SVP of Product Management and Design.  Side note: Before picking up the book, I had no idea that it was written by my current VP's predecessor.  The fact made the book a bit more interesting and insightful for me, though.

Cagan presents his view that successful PMs are like CEOs of their domains: They utilize all parts of the business and the technology to move their products towards the visions they have created.  He is careful to distinguish this type of role from what is called "Product Manager" in many organizations - in some companies, PMs are focused on market research and the development of business requirements, while in others, PMs are technical managers tasked with delivering defined projects on time and within budget.  Cagan's PM is both of these and neither of these; he advocates for organizations to have "Product Marketers" who focus on the market, and to have "Project Managers" who work with the technical teams (dev, QA, release management) to get products out the door.  Cagan's Product Manager is someone who sits in the middle of those roles, translating what customers/markets want and need into feasible technical specifications.  As part of that process, the PM must seek to understand customers and opportunities (i.e. have a foot in marketing) as well as communicate those opportunities to, and inspire and lead, the technical teams (i.e. have a foot in engineering).

In short, a PM must utilize marketers, user researchers, interaction designers, product designers, developers, testers, and any other roles available, to get the right product built.  She is the one ultimately responsible for the product (the "wringable neck" as some say), though Cagan highlights the fact that she does not have the power of hierarchy - a PM does not manage these people, so she must influence them using her credibility, which is gained over time with success and clear communication.

Cagan spends a large part of the book speaking to the important interaction between PMs and designers. He argues that designers, particularly interaction designers (those who think about the flow of the customer's interaction with the product), need to be involved near the genesis of a project and must be given the time to design a beautiful product before developers get their hands on code.  His argument is that having the right design is critically important and that the function is all too often relegated to "prettying-up" a product that has already been built.  Also, design cannot happen simultaneously with development (at least on the front-end) since developers must be given clear direction on the flow, look, and feel of the product, all of which come together as one package as opposed to modular chunks.

That leads Cagan to a somewhat controversial proposition: That the tried-and-true PRD (Product Requirements Document) should be ditched in favor of a "high-fidelity prototype."  This prototype, ideally created through the efforts of one PM, one developer, and one designer, would contain all of the meaningful interactions to be in the end product, and would of course contain the look and feel of the end product.  The argument for this method of communicating requirements is that it will save time (by quickly communicating what needs to be done) and will improve quality (by unambiguously communicating what needs to be done).  In that argument is the assumption that PRDs tend to be long and boring (and thus aren't read) and tend to be imperfect translations into words what are supposed to be visual and interactive experiences - using a PRD is like translating a French poem into English then back into French - information is inevitably lost.

While everyone has their complaints about them, PRDs are used extensively at eBay.  I brought up Cagan's high-fidelity prototype idea in a couple of conversations with senior PMs on my team, and I heard several valid reservations:

• Developers may be able to play with a prototype and see how to build the product, but what about QA?  What about the edge cases they need to test?
• A lot of (maybe even most) projects do not involve building a new product from the ground-up, and thus are small, involving one or two developers.  If you're taking a developer to build a prototype for this, you might as well just build the whole product.
• What about non-visual products, like APIs?  In that case a prototype doesn't make sense - you just write the specifications.

It is thus apparent that the prototype method should only be used when appropriate for the situation (visual product with a large team).  Also, it is probably a good idea to do a test run of the method before committing to it entirely (i.e. build a prototype and write a PRD, then see which one the team finds more useful).

In summary, Cagan's book serves as a great guide to someone new to the practice of Product Management as it clearly outlines the roles and responsibilities of the PM and everyone else she must work with to get the right product to the customer.  In my own six weeks of experience at eBay, I have found that Cagan very accurately describes this company's version of the role.  For the seasoned PM, the book offers several fresh ideas for how to better do his job, though he must think hard on which ideas would work well for his own situation.