Books for Software Engineers switching to Technical Product Management


As I’ve decided to switch over from being an software engineer to technical product management, I found my theoretical knowledge lacking. Having worked in software companies big and large, I knew the basics. Agile this, MVP that. I knew how prioritize things, and how to get things out the door. But largely, I was repeating what I’ve seen to have worked. The lack of a mental framework left me unprepared for novel problems where I’d need to make ad-hod decisions. I never failed miserably, but it seemed imminent.

Also, not just technical matters, but also on communication. I generally have an easy-going attitude and never had serious problems communicating up and down an organization. But there have been times, faced with challenges, I’d “wing” a solution, instead of really approaching it systematically. Things generally worked out, but I felt more lucky than accomplished. Not particularly sustainable.

So, I did what anyone does to fill in the gaping void in my knowledge. I decided to read some Medium posts. Obviously, that didn’t work. Turns out, reading endless amount of think-pieces isn’t a good way to absorb information, or make sense of it.

I present you 4 books I’ve read over the year and a half that really made an impact on my technical product management thinking. They span the management-product spectrum, but leaning towards “management”. That’s partly because I already felt comfortable on the product side and partly because I haven’t written that post yet.


High Output Management

High Output Management

High Output Management is to management what K&R is to programming in C. From the very first page to the last, it is dense with information, examples, and suggestions. Every sentence, seemingly, is there for a purpose.

The book starts with a hypothetical example of optimizing the output of a diner with a “breakfast factory” example and effortlessly builds the entire Intel empire throughout each chapter.

Some of the most eye-opening chapters were the ones on how and most importantly why many big companies evolve into matrixed organizations with cross-functional reporting structures. It is easy to get disillusioned such organizations and balk at the seemingly insane criss-crossing of management chains. Similarly, the parts about why (well run, and intentional) meetings are important to an organization, why long terms plans are more than the plans itself were all eye-opening.

Similarly, the chapters on how to prioritize and plan projects are full of immediately useful insights. Grove talks about how to streamline a delivery around non-negotiable deadlines and “bulk”, how to track the process with paired indicators that measure a process from both sides (how much work is done and how it gets closer to delivery).

If there’s thing I’d note, I think a dogmatic, straightforward application of all the lessons in this book would optimize your organization for output, not so much for the organization itself. There have been parts where his suggestions made me pause, from an organizational standpoint. I think part of it is due to the didactic prose more so than the content.

I’ve read this book couple times, and I still find myself highlighting certain parts. It’s timeless book, dense, full of information and insights.



If High Output Management is the seminal technical management book, Inspired might be the seminal product management book. People have recommended this book to me couple times, and I wish I read it much earlier in my career.

The main theme in the book is that in technology companies, especially high-growth consumer products, engineering needs to be part of the decision making process from day one. Marty Cagan separates the “product” workflow into two, product discovery and product delivery. His main point is that most companies need to spend more time in product discovery, but do it in a structured way by shipping to learn.

He takes effort to separate prototyping for different goals, a thought I’ve find interesting. The distinction he makes on delivering features versus delivering prototypes seems to be lost on many of the lean-startup folks of the late 2010s era.

The other long-running theme of the book is that successful organizations are full of missionaries, not mercenaries. He does talks quite a bit about how important it is to make product teams aligned on the goals and have their own autonomy. I found agreeing myself with the lessons here, but for some of the recommendations seemed a bit high level, and too obvious.

The book follows a loosely bottoms up approach; Cagan starts from building a team, to process, to products, to culture. The book is seemingly derived from a bunch of blog posts, and it can feel quite repetitive at times. The seemingly similar paragraphs about “missionaries vs. mercenaries” and “discovery vs. delivery” do get in the way of reading.

This book has a quite a narrow target audience, but it delivers on its promise.

Radical Candor

Radical Candor

I have literally judged this book by its cover and almost didn’t read it. The title “Radical Candor” reminded me too much of the “Radical Honesty” movement. I wish I didn’t. Kim takes years of management experience and dilutes into a book that’s easy to read, and full of insight. This book is quite new, but I expect it to become a common piece.

The main theme of the book is that any sizable organization will have lots of conflicts and it is best to handle them with grace and structure, instead of avoiding or sulking over them. She talks many different sources of tension, from how different employees operate, different teams have different goals and seemingly at-odds ways to get there.

Her main lesson in the book is that managers can use honesty as a veiled attempt at being heartless but a way to open a channel of communication. She takes great effort to separate being “direct” from being a “dick”. She mentions that honesty goes both ways; managers need to open to feedback and actively solicit it.

The book is a true Management with capital-M book. Compared to High Output Management, it can be a bit heavy on the jargon and delicately capitalized frameworks. I personally haven’t felt any of the book was filler, or repetitive but if you are not into management books, it can feel slightly MBA-esque.


The Manager’s Path

The Manager’s Path

The Manager’s Path is not about product management but instead of on how to manage engineers. I wish I read this book earlier in my career (had it been published) when I was transitioning from a junior engineer to a more senior one, and than a tech lead spearheading a technical project with different teams.
Camille Fournier follows a straightforward structure. A software engineer turned senior software engineer turned tech lead turned engineering manager and then all the way up to CTO. Fournier has been through the ringer herself, and the book seems very true to the core.

Unlike the other books, this book is heavier on practical advice than on theory. That is not to say it doesn’t have a guiding principle. But in my reading of, it seemed the principles behind the advice came later.

This book also reminded of High Output Management because of the way she builds up the management organization, but in a more thoughtful way. At times reading High Output Management, some of the lessons felt very heavy-handed, even though I’ve agreed with them. In Manager’s Path, Camille Fournier takes time to make the case for why an engineering manager needs to do the thing she does.

A slight improvement to this book would be a better narrative, at least within chapters itself. There have been couple times where the sections jumped from topic to topic too fast, and I found myself distracted. Sometimes a couple paragraphs could be about mentoring a team, then immediately turning over to more technical, almost infrastructure-level advice.

Hang tight for a list of couple books more on the product side of product management.

1 Comment

  1. Pingback: Product Management Book Recommendations – Mostafa Nageeb

Comments are closed.