Stephen Hara

(Full disclosure: This post includes Amazon affiliate links which, if you click through and purchase the product, will earn me a small commission. If you're interested in the book but prefer not to use affiliate links, I would still appreciate giving the post a read and buying it on your own terms!)

A friend of mine has lately been talking about moving into the tech industry as a product manager. To that end, he's been doing a lot of related reading and asking me a lot of questions about product management that I have little to no answer to. So I thought it'd be a good idea to look into some product management books and resources as a way to expand my horizons and be able to better understand what exactly a PM does. One such book I found is The Product Book: How to Become a Great Product Manager by a couple of people from Product School.

Summary

The book goes over the lifecycle of a product or a feature from generating initial ideas to planning, designing, implementing, and finally launching and iterating on what ends up provided to the customer, be it a service or a physical product. It uses an example fictional application called Moover that helps people looking to move find the best moving company for their needs.

In general, it gives a great look at the overall process of conceptualizing something for your customer through the lens of your company and its value proposition to customers. One nice non-obvious insight from here that applies throughout the process is that it's very easy to state the "what" part of that value proposition, but it's tremendously valuable to also keep to a consistent, simple "how" and "why" on top of that. Doing so helps keep your product offerings focused and gives you a specific frame through which you can evaluate and decide on new features and products.

The overview is also handy for contextualizing one's role in the process, be you designer, engineer, PM, or another participant. Plenty of us would like to imagine our part of the process as most important, but that's (fortunately, in my opinion) not the case in most functional processes. Apple is one commonly referenced company for producing excellent products from the bottom up - while all of the aspects that go into the MacBook for example are necessary, none in isolation are sufficient, and they all have to be excellent at their job, from designers, to engineers, to marketing and sales, and so on.

Some Particulars

The book does a particularly good job of emphasizing that as a PM, most of the work you do is to make sure the rest of the team is doing the right work, and each team is able to put full effort into doing the best work. What that means is things like collecting data to find the right work to be doing, removing and preempting obstacles to their work, and keeping the workflow operational and safe from tripping over itself.

It's unfortunately, despite one way to read the subtitle of the book, not much on advice on how to become a PM, but it does address that both in saying that most product managers transition to that role from other roles such as design, marketing, or engineering, and also in saying that there's not really a conventional path to becoming a product manager. I don't consider this to be a fault of the book when it is likely most books on the subject will say the same thing.

One specific reason why I want to write about and recommend this book is the emphasis throughout the book on making sure what you're working on to improve your offering to a customer is something that not only actually moves toward that goal of enhancing your customer's life with your product, but validating that it will help the customer and trying to do so at all possible times, starting from initial concept and ending with its reception by the customer base at launch. Especially with the speed of technology these days, it's all too possible that a customer needs something you're working on every day up until you launch it.

Rambling

I have another point that goes along with that, something that specifically pertains to engineering but could be relevant to other roles. I notice that software engineers occasionally have a tendency (I've had this myself) to emphasize a perfectly well-architected, well-designed (in software terms) solution from the get go, and invariably this process of design requires time.

Certainly, software should have some design put into it, and a good design is better than none. But a good, simple software design with a better time to market will almost always be better than a great software design that loses out in revenue (and spends more in labor). If you don't believe me, just google how important is time to market. The dearth of results should tell you something.

More or less, when you work for a company providing a product, your primary job is to deliver that product. I know there's something to be said for pride in one's work and being a greater craftsman, but when you want to sell artisan software, that's something to be saved for your artisan software business. (That's why I consult!)

Anyway, enough rambling! That's probably not why you're here.

Conclusion

The Product Book is a pretty solid book for demystifying the general job of a product manager and illustrating the product/feature lifecycle and all the components, work, and people that go into a successful product. I read it so I could learn more about work as a PM and their role in an organization and I think it serves as very educational in that regard, but if you're already a PM or looking to become one, there's plenty to dig up in this book.