What books are recommended for technical product managers?

I’ve now held two distinct PM positions at two different firms, and all of them involved technical work. In order to manage workloads, I typically collaborate with infrastructure teams, mainly those focused on networking and hardware for data centers. I have no experience managing or owning software development teams; all of my experience is with physical infrastructure.

Exist any solid recommendations for reading material that focuses more on this kind of PM role? I’ve had some success at work, but as I continue to learn more and sharpen my abilities, it might be challenging to identify the specific components that would be useful to my existing teams.

My strategy thus far has basically consisted of adapting some of the Scrum ceremonies and workflows, while changing or completely ignoring some of the more rigorously planned components that serve only to aggravate me (and management has, so far, been supportive of my approach). For instance, our daily standup is SHORT and focused, and it’s a great way to catch up on everyone’s activities. However, for these teams, 2-week sprints are frequently a really poor method to demonstrate progress because it might take months of planning before significant hardware efforts actually get going, and once they do, there are usually unexpected hiccups we never saw happening.

Any recommendations for readings, blogs, etc. for someone in this kind of role?


I also manage technical product manager for teams working on data engineering and virtual infrastructure. These teams, in my experience, function more in a waterfall paradigm than an agile one, which is appropriate given that if they don’t meticulously design and validate requirements, software teams will depart the platform and your teams will be disbanded. Because of this, regular status reports that show progress backed by metrics, e.g., recent deploys in Gamma showed expected improvements in latency by X ms, will be important for leadership to know.

I work in data infrastructure, so it might not be as relevant to what you do, but I’m still trying to apply Agile principles whenever I can. For example, rather than building out a full stack, we should see if we can build a quick disposable stack for experimentation to gather data points for decision-making. Overall, in this line of work, scalability and maintainability may be more important than MVP.


Yes, I believe the dev teams who depend on our underlying systems have had problems due to the waterfall approach used to design the actual hardware. Senior leadership in such organisations doesn’t understand that we can’t just throw new hardware up whenever we want, unlike in Azure. We are migrating some of our data to the cloud, but it will be some time before we are totally cloud-based due to the nature of our business.


I think there’s still value for the dev teams to test out their product in cloud solutions before coming to you with an onprem resourcing request. Having them experiment on cloud will allow them to have a better idea of how much resource they need from you to scale in the coming years. Cloud isn’t necessarily cheaper at very large scale.


Yeah, we had a rather poorly-planned not-planned-and-dev-teams-just-went-for-it cloud roll out this year that was massively scaled back (SOC audit no likey and InfoSec’s screams could be heard far and wide). I’ve also been driving some discussions about cost vs value around some things that we’ve had management push around. Stuff like thingy costs $X on prem, $Y in cloud. Just because X>Y doesn’t automatically mean cloud is the best way to go. I’ve been pushing hard for those conversations and gotten quite a few head turns when people realize the “real” costs in some areas.

I’m definitely not “anti-cloud” by any stretch. We just have some people in my company that are just pushing “PUT ALL THE THINGS IN THE CLOUD!!!” and I’m trying to bring them back to earth on some things that will be better served, cheaper, etc. keeping in our colo.


Interesting. Yeah once you have compliance costs baked into infrastructure costs, then cloud, or any other SaaS providers won’t look as attractive as a solution anymore. I dealt with something similar in on-prem data labeling vs on-demand remote data labeling workforce.

In that case then in your PM’s role, you should surface these cost “blind spots” with dev teams and leadership; you are putting forth the value of your onprem products that will minimize compliance mitigation costs in the long run.


I really enjoyed An Elegant Puzzle: Systems of Engineering Management. Yes, it is a little more catered to an engineering manager but had some good stuff in there for anyone managing a technical team or product.


The big trends in engineering these days is devops and data science so you should read up on that IMHO.


Yeah, we’ve been doing a devops move “marathon” style (ie it’s a journey not a destination). It’s generally been good. Plenty of kinks to work out though. We’ve had some serious rapid growth in the last year and most of our team is pretty new to the company still. That being said I probably need to spend some more time digging in on DevOps. Thanks!


Can I ask a mildly related question? How are ‘technical product manager’ and ‘technical architect’ roles different?


My feeling on that is that the technical product manager is really a product manager with a deeper technical understand of the product. For example, depending on my/my team’s workload I will actually sometimes step in and help with incident triage. I’m also well-versed enough to be able to have architectural conversations with the engineers without having to ask for more plain explanations. I’m able to explain things to stakeholders and answer their questions without needing to check with an engineer (most of the time anyway, lol). I still run team groomings, prioritize work, etc. like a typical PM, just with a deeper level of technical understanding of the work being done.

I may be missing the mark here a bit as I’ve only ever been a technical PM and I’ve never worked with a pure software development group. I went from a general sysadmin type position to Technical Product Manager for a large network team and kind of had to learn on the fly how to be a PM - that initial position they were really looking for someone who could have a coherent conversation with the network team and then translate things for the “normal” people. I only got an actual certification about a year ago despite being in the role for 5 years.


I’m new, so I’m in the info gathering stage and most of my info is coming from


Software Requirements 3rd Edition has long been my bible for software development. Even if you don’t apply everything in it, there’s still a lot of useful examples to take away.

2-week sprints, though, are often a pretty bad way to show progress for these teams as there is sometimes months of prep work before major hardware initiatives really start moving and then once they do get going there are always crazy hitches we never dreamed of happening.

On the one hand, I get it. On the other hand, is it possible that you’re not grooming the product backlog as effectively as you could be? In terms of Agile, if you’re breaking down the stories to a sufficiently granular level, then the team should be able to pick up tickets that allow them to complete some sort of task within the time box of your sprint, even if the ticket is just a preparatory task for a much bigger initiation. This will also allow you to track velocity and estimate time to delivery more effectively.


Read system design primer if your role is a TPM role.


For a Technical Product Manager, technical know-how of the technologies associated with the product is sufficient to an extent that a TPM can speak the language of engineering. For those reasons, books might be too deeper unless you are exclusively looking for dummies books. If knowing technical concepts sufficient enough for doing a job, i would recommend to read some articles or blogs.

In addition, Technical Product Manager should be aware of the broader technology trends and the ability to differentiate or anticipate fad from reality. Those details cannot be found in any book. You have to keep you ears and eyes open looking around more information.

For e.g. if you are managing a product that deals with ML, a fundamental understanding of the following should suffice:

  • What is supervised and unsupervised learning?
  • What are various models under each of those categories? How to identify the right model depending on the use-case?
  • How to interpret error for various algorithms?
  • What is regularization and when it is used?
  • What are bias and variance?
  • When to add more features to existing data and when to augment more data to existing data?

To again the above knowledge, the following Medium article is a great source - A Beginner’s Guide to AI/ML – Machine Learning for Humans – Medium

Reading books are always helpful unless you are willing to go deeper and can invest time. Otherwise, blogs or articles as referred earlier should suffice for understanding the technical concepts like Big Data, APIs, IOT (I refer to Daniel Elizalde Blog), Blockchain etc.

1 Like

Fortunately, I stumbled upon a list of readings including blogs, books, articles, specially compiled for Technical PMs. I think this would be helpful for you as well as all the other community members. Here it is: