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.

A Stake in the Outcome

Living in San Francisco while working in San Jose has the drawback of a long, hour-plus commute.  Except in my case, where it’s somewhat of a benefit:  It’s my time to continue my business education while school is out for the summer.  You see, most of the large tech firms in Silicon Valley send buses to San Francisco to pick up employees – you could call it a green initiative, but it’s moreso a tool to attract young talent that prefers city life over the suburban Valley – and eBay is no exception.  So, with each ride in the morning and afternoon, I take the opportunity to work on the list of books my professors recommended to classes for additional insights.

The first one I picked up, Jack Stack’s A Stake in the Outcome, provides a narrative of a company’s journey to create what Stack calls an “ownership culture.”  The company (which he founded and managed), SRC Holdings, began as an employee buyout of a factory owned by a large machining firm, and developed a somewhat democratic management style.  It was one of the first companies to implement an Employee Stock Ownership Plan (ESOP), and it used the plan to great effect in incentivizing positive behavior.

A couple of Stack’s points about creating an effective ownership culture jump out at me:

1. It requires all employees to understand the fundamentals of business.
2. It requires employees to be invested in the business long-term.

The first point relates to a concept he calls the Great Game of Business – effectively, it involves practical business training for all employees by evaluating them based on real business metrics and teaching them what the metrics mean.  For example, a team of line workers might receive a higher bonus if the factory improves its cash balance.  Once the employees understand what contributes to the cash balance, they may find ways to reduce throughput time in order to reduce the investment in inventory, for example.  But even more powerful than reaching for the bonus is the realization of the direct relation of the metric to the health of business, and therefore its stock price.

The effectiveness of that part requires Stack’s second point.  Specifically, he states that employees need to be invested in the company long enough for the feeling of ownership to sink in.  Stock ownership needs to be a long-term deal with employees, not an additional method of compensation.  He expresses his reservations about the route Silicon Valley firms have taken with stock ownership, with options vesting after a year or two:  His belief is that a year, or even a few years, is not enough time for ownership to take root, where an employee feels that he is invested in the business for the long-haul and that his actions have a measurable effect on his business (and therefore his livelihood).  At SRC, stock options typically vest in seven years.

What Stack doesn’t specifically call out, but which I believe is critical to creating an effective ownership mindset, is the requirement of the business to be small in size.  Towards the end of the book, he talks a lot about SRC’s constant search for areas in which to spin off companies, which would create opportunities for new management teams to experience the power of leverage and the power of ownership of a small business.  Without the smallness of size, these effects, and thus the lessons, would be greatly reduced.  This concept is echoed by Clayton Christensen in The Innovator’s Solution, where he states that teams formed for disruptive innovations need to be separated (organizationally and often physically) from the larger business so that they can get excited about small numbers and can be forced to be impatient to generate profits, just as a startup would.  I love thinking about this topic of creating successful innovations from within the context of large organizations, so I’ll be looking for more literature on it.