PM Onboarding: Reading List

Product Management Reading List

This is part one in a two part series about our process at Return Path for Onboarding new Product Managers. Part two will cover our 90 day goals to ensure we’re setting PMs up for success.

We had a great panel last week during Boulder Startup Week where I mentioned in one of my answers that we had a rigorous on-boarding process for new Product Managers. This has sparked a surprising interest in the reading list and I thought I would share in more detail.

Here are the list of 5 books that are required reading for our Product team along with the why each book is included:


Getting Things Done by David Allen

Product Managers are always swamped with work and often have multiple different contexts to switch to throughout the day. If you cannot implement a system for managing your work and ensuring your productivity, you won’t survive. This is THE book for productivity management. It tops the list because it’s critical to hit the ground running and also it’s much easier to establish a productivity system before you’re overrun with the minutia of the day to day.

The important take away from the book is the Getting Things Done (GTD) system.  The point isn’t to get religious about the system, but rather understand the principles and implement the basic tenets of GTD in a way that will work for you. The outcome should result in inbox zero and a focus on the important, not just urgent, tasks. If you are still using your mind to remember and recall the tasks that you need to do, then you aren’t doing the system correctly! Getting your to do list out of your head and will ensure you’re much more productive.

If you’re running GMail for your corporate mail I would also highly recommend a much more robust task list system. Gmail tasks are the worst!


The Lean Startup by Eric Ries

Hopefully everyone reading this post has read, or is at least aware of the book, The Lean Startup. Eric’s book covers a lot of ground.  It sets out the language and concepts to incorporate Lean thinking throughout the Product organization. He does a great job of walking through many different concepts and and establishes frameworks we use throughout both our Product and Engineering teams.

The key concepts including: experimentation, a build/measure/learn feedback loop, continuous deployment, KPIs/metrics, minimal viable product (MVP), pivots, and more.  All of these tools are critical to understand as early as possible, when joining our organization. Although all Product Managers will have exposure to these tools while working at our company, it’s important to learn about the theory and the why behind them before you start working within our tailored versions.


Running Lean by Ash Maurya

We use the Lean Canvas for talking through new products or business opportunities. It’s a lightweight way to capture our current assumptions and easy to share with other groups within the organization.

Running Lean provides a complete understanding of the Lean Canvas.  It covers how to implement the Lean Canvas as well as providing tactical steps to start working through the various sections of the canvas. Other organizations have aligned around the business model canvas from which Lean is adapted, but we like the Lean Canvas as it’s slightly more tailored towards product discovery and the book paired with his online videos provides a nice training for new PMs.


Inspired by Marty Cagan

We’re big fans of Marty Cagan and have brought him in to do consulting and also send new Product Managers to do the 2 day trainings he offers through his consulting practice. In addition to his books, I also highly recommend his Silicon Valley Product Group blog, which is a great resource for any Product Manager.

Marty’s book walks you through the structure and roles of the various groups that interact with Product Managers. The big takeaway, and the reasons we recommend his book, are the utilization of UX within the Product team and the triad for doing discovery. Prior to Marty we didn’t have UX as a function in the company and he was instrumental to help us establish the practice.


Escape Velocity by Geoffrey Moore

Geoffrey’s book packs a lot of information and concepts into a normal sized business book. It contains 10+ frameworks/models and recaps several others from his previous books. It’s a lot for anyone to digest, but the most valuable part for our company is understanding and establishing language for managing a portfolio of products/businesses. The Horizon’s model, its context and how to avoid the pitfalls, is the most important model within the book for our PMs and the reason we have everyone to read it. It’s critical as a Product Manager to understand if you’re managing a Horizon 1 product vs. Horizon 3 product. Each type has a different criteria for management and  success. Those differences at the high level spill into the both the strategic and tactical decisions. The Horizon model, paired with his Return on Innovation model, can really start to shape the types of features and guide the work you need to do on each product.

Overall, we don’t mandate an order for all of the books to be read in, but if you’re uncertain I have listed them in the order I would suggest tackling the books for a new Product Manager on my team. It’s absolutely the most important to get a productivity system and ramped into the Lean skills before tackling a portfolio of products.

Let me know in the comments whether you agree or disagree. What books would you add to this list?


Good Product Manager/Bad Product Manager

This is a repost from Ben Horowitz:

Good product managers know the market, the product, the product line and the competition extremely well and operate from a strong basis of knowledge and confidence. A good product manager is the CEO of the product. A good product manager takes full responsibility and measures themselves in terms of the success of the product. The are responsible for right product/right time and all that entails. A good product manager knows the context going in (the company, our revenue funding, competition, etc.), and they take responsibility for devising and executing a winning plan (no excuses).

Bad product managers have lots of excuses. Not enough funding, the engineering manager is an idiot, Microsoft has 10 times as many engineers working on it, I’m overworked, I don’t get enough direction. Barksdale doesn’t make these kinds of excuses and neither should the CEO of a product.

Good product managers don’t get all of their time sucked up by the various organizations that must work together to deliver right product right time. They don’t take all the product team minutes, they don’t project manage the various functions, they are not gophers for engineering. They are not part of the product team; they manage the product team. Engineering teams don’t consider Good Product Managers a “marketing resource.” Good product managers are the marketing counterpart of the engineering manager. Good product managers crisply define the target, the “what” (as opposed to the how) and manage the delivery of the “what.” Bad product managers feel best about themselves when they figure out “how”. Good product managers communicate crisply to engineering in writing as well as verbally. Good product managers don’t give direction informally. Good product managers gather information informally.

Good product managers create leveragable collateral, FAQs, presentations, white papers. Bad product managers complain that they spend all day answering questions for the sales force and are swamped. Good product managers anticipate the serious product flaws and build real solutions. Bad product managers put out fires all day. Good product managers take written positions on important issues (competitive silver bullets, tough architectural choices, tough product decisions, markets to attack or yield). Bad product managers voice their opinion verbally and lament that the “powers that be” won’t let it happen. Once bad product managers fail, they point out that they predicted they would fail.

Good product managers focus the team on revenue and customers. Bad product managers focus team on how many features Microsoft is building. Good product managers define good products that can be executed with a strong effort. Bad product managers define good products that can’t be executed or let engineering build whatever they want (i.e. solve the hardest problem).

Good product managers think in terms of delivering superior value to the market place during inbound planning and achieving market share and revenue goals during outbound. Bad product managers get very confused about the differences amongst delivering value, matching competitive features, pricing, and ubiquity. Good product managers decompose problems. Bad product managers combine all problems into one.

Good product managers think about the story they want written by the press. Bad product managers think about covering every feature and being really technically accurate with the press. Good product managers ask the press questions. Bad product managers answer any press question. Good product managers assume press and analyst people are really smart. Bad product managers assume that press and analysts are dumb because they don’t understand the difference between “push” and “simulated push.”

Good product managers err on the side of clarity vs. explaining the obvious. Bad product managers never explain the obvious. Good product managers define their job and their success. Bad product managers constantly want to be told what to do.

Good product managers send their status reports in on time every week, because they are disciplined. Bad product managers forget to send in their status reports on time, because they don’t value discipline.