Interested in hearing reactions to this. I would classify myself as a “technical generalist,” which means that while I have a basic understanding of numerous technical subjects and tools and can typically communicate in their language, I wouldn’t classify myself as an expert on many, if any, of them.
Adding to that, what technical know-how, resources, or abilities have you discovered to be particularly useful for TPMs?
As a Technical PM I would have to have knowledge of API, Micro-services. Contracts. General concepts of data structures. C and OOPS concepts (extend to any other high level language including python and R) Hypothesis testing. Experiment design. Data analysis. Data modelling. Machine learning basics. Model tuning. Tableau. Unit tests pitfalls for data models. Spark. SQL. Data cleaning. General principles of system design. What is a good architecture? Basic statistics.
Depending on the product, the term “technical product manager” might signify a wide range of tasks. Sometimes the product is an API, other times it’s a mobile SDK, sometimes it’s a JS library for web development, sometimes it’s an ML component in a larger product, and other times it’s platforms and tools for developers (like logging and monitoring tools, cloud infrastructure products from AWS/Google/Azure, etc.).
Many of those ought to be PM’d most likely by someone with firsthand personal experience that informs their intuition about how to cater to the particular clients/users of the product. For instance, since I’ve never used a tool like that to analyze application logs, I would not feel instantly at ease PM’ing the Splunk web UI. I could certainly catch up, but before I felt ready to function in that setting as a PM, I would need to gain some fresh experience.
As an example of what I mean by “gain some new experience,” I spent six months of evenings and weekends learning to program while maintaining a set of platform APIs for the cart and checkout in an e-commerce stack. To be clear, you don’t want me to write any code for you because I’m bad at programming. The ability to make sound “UX” decisions (on behalf of the engineers who required to use my APIs) and to have fruitful interactions with both my own engineering team and the engineers who used my product, however, improved dramatically.
I believe the following to be a decent minimum standard for most technical roles, and each of these is very beneficial in virtually any PM role as well:
HTTP (since pretty much every software is using it in some way for something) (because pretty much all software is using it in some capacity for something)
REST APIs (for instance, the ability to read API documentation to determine whether or how you could use an API to implement a particular feature in your product, or even manage an API as a product)
It can be really helpful to cut through ambiguity and make sure we’re all talking about the same thing by using data structures and dot notation (for example, being able to communicate with engineers like “If item.price.current price > 299.99, display the special return policy message” — way clearer for everyone than just saying “If the price…”).
Grasp of common design patterns, managing tradeoffs, etc. in large systems and web and native mobile applications. Although I don’t believe that product should be the driving force behind these choices, being able to easily communicate with engineering partners is really useful.
Knowing how to read and draw sequence diagrams well is quite beneficial; basic block diagrams are easier to understand but are still useful.
On all of the aforementioned, having at least some programming knowledge in the front-end and back-end is quite beneficial.
The most crucial factor, in my opinion, is a desire to embrace complexity rather than avoid it. You must be willing to participate in conversations you don’t fully understand, do your own research on the subject, seek the advice of intelligent people, etc., because nobody ever fully knows everything.
I look for two minimum requirements in the competency category when hiring a PM for a technical product (the other category is character, but that is not the topic here):
Some programming experience is required because certain technical concepts can’t be learned from reading blogs, watching YouTube videos, or talking to coworkers. Programming knowledge serves as a foundation for the CS concepts required to go extensively into certain technological issues.
Because it’s probably a fantasy to discover someone who already knows everything, they’ll ever need to know to be a good PM on a given product, you should have a natural interest and thirst for learning new things.
Although having more than those two is definitely preferable, with those two as a starting point, the rest of what is required should be quite simple to learn on the job.
@DhirajMehta, Could you please explain how programming skills will help a PM? I know what you mean by comprehending topics like testing, architectural principles, and data structures. I’m interested in the specifics of this and believe that understanding an API’s structure, concepts, how to interact with it via Postman, and “UI” is more important than knowing how to build the code that powers it.
@JuanAllo, yeah definitely, Thank you for pointing up a few important distinctions!
I do not believe that all PMs must be programmers to be successful in their positions. It might not even be worthwhile to require it for “technical” jobs (especially for API goods). Hopefully every hiring manager has the discretion and wisdom to provide the appropriate qualifications for each position. It was a tremendous assistance for my team and our product — as well as for my career since then — that I decided to bite the bullet and learn to program, but I was speaking specifically to my own experience as a PM for APIs (a job I wouldn’t have been offered, btw).
When we had some very strong engineers on that team, I would not have even tried to provide advice on the internal implementation of the API because that was not something I wanted to have a deep grasp of. I can elaborate further about that.
Even though I’ve never created any code for a company, I wasn’t concerned about how we implemented functionality in the API environment. However, I wanted to get a flavor of what it would be like to use the API from the caller’s point of view. My first-draft batting average significantly improved, and I was able to have fruitful feedback discussions with the engineers who relied on my APIs when they needed something different than what I initially assumed. This is not to say that I became a perfect genius.
You wouldn’t want a PM for a web application who had never used a browser on a desktop or mobile device or who lacked the necessary abilities to do so. The only thing they could say would be, “The app needs to be able to accomplish thing X, now please make it do that in some fashion (and I’ll have no idea if the UX/UI you decided to use makes any sense for our users)” By the same reasoning, I didn’t think I could do my work, managing APIs, well without some hands-on experience using APIs — creating requests, processing replies, and going from one endpoint to another in some kind of user journey that reuses the data returning to client.
Programming helped me think through complex scenarios that involved numerous APIs, endpoints, background services, and downstream dependencies, all of which were quite helpful to me in that position. Larger, distributed systems can still benefit greatly from the same programming ideas (clean abstractions, encapsulation/DRY, naming standards, etc.), you’re just talking about “domains” and “endpoints” instead of classes and functions in a monolithic code base.
And on top of all that, the fact that I was able to have far more efficient and quick talks with my own engineering partners was just a really great side bonus. However, you’re correct that this is probably not enough to justify learning to program on its own (unless you have ambition to build and bootstrap a product company independently or be able to build a POC for a startup in the traditional VC-backed model).
Hopefully, that was clear. Every company, team, and product are different and complicated in its own way, so I wouldn’t dare generalize about what’s required in all situations. The best example I have is from my own experience, and I can honestly say that I don’t even remotely regret spending the time and energy it took to learn to program (which was a challenging six months), merely that I didn’t do it a decade sooner.
@DhirajMehta, I am a pm for an SDK. Any tips?
Although I don’t know anything about you, I assume you worry about having the technical knowledge you could require. If I’m misunderstanding something, kindly correct me.
Any reading, podcasts, or YouTube videos you can locate will definitely be beneficial. If you can find any, perhaps reviews of other SDKs for the same platform or platforms.
This is generally the advice I would provide for technical conversations.
I’m coming to the conclusion that learning how to code is totally unrelated to being a project manager. Algorithms? Somewhat. software development? Sure. Creating a system? 1000%. However, unless your users are interacting with your product through code, I’ve never come into a circumstance where my specific understanding of coding was useful. There are usually broader technical concepts involved.
@RisaButler, I think it depends on the software. I’ve found my programming background and experience has been invaluable. I’ve found it really helps when prioritizing and talking with the devs. For the most part they can discuss problems and solutions without having to dumb things down. And I’ve found understanding exactly how the data flows quite helpful when expanding feature sets.
Now I don’t think you need to have any serious programming skills but being able to read code and understand limitations is definitely useful.
Yeah, I agree with all of this. I also think it’s easy to be more effective because of technical background without even realizing it. It’s hard to imagine how a conversation would have gone if you didn’t know what you know. I suspect there are times where I’d say it wasn’t a technical conversation, because we didn’t look at code or discuss a CS concept — but either my own thinking or my ability to understand the other person(s) in the discussion were much stronger thanks to my technical understanding.
I think of it as a bit (SPOILER: this is not a great analogy 
like learning to type fast. As a PM, typing fast is not your job — and you can for sure be good at the critical aspects of the job and get results, which far surpass a faster-typing peer. But if you sit in front of a keyboard all day, typing fast is for sure better than typing slow (all else being equal).
Agree completely. +1 on system design.
When I first started working on products for engineers and data heavy products I yielded to “expert” engineers. The outcome was tragic. I tell PMs today that you should never let someone “write a design document” instead of requirements. Write the requirements and get engineering to help with the detail.
Before I understood that my last “senior” engineering position, web performance at my old company, was so close to product management, I was an engineer for ten years (large and small shops + open source), therefore I made the decision (with my leadership) to change my title as well. It should go without saying that I too had a great time!
Since I was familiar with many systems at my old company, I believe that my technical background was almost detrimental to me in that role. As a PM, you never want to be the most senior engineer because micromanagement by an almost armchair programmer (or benevolent dictator, depending on how you look at it) is too simple, and staying within that line requires strict self-control. Additionally, it reduced the amount of time I had available for PM work; at times, I felt as though I was juggling three tasks at once.
Since then, I’ve entered new businesses, where it has both helped and hurt. It helped because you could
When anything goes wrong, it stings to witness leadership/non-technical PMs and engineering teams simply throwing fingers at one another when you can kind of understand both sides’ positions.
When project estimates are returned with merely either absurdly lengthy or shockingly short dates, it also hurts.
I have four years of technical engineering experience; thus, I feel fairly secure in the technical aspects of my SaaS. I’ll admit that some of my colleagues have “concrete” abilities that aren’t really relevant to SaaS, but the concepts and tools still exist with additional jargon.
The best Technical Product Managers have several years of experience in a software and/or devops role, 1-2 years experience in some kind of customer-facing role, and some experience in business admin (cost ops, P&L, margin management, etc.). TPMs at large companies would make good CTOs at smaller companies.
The best TPM I ever worked with at my 4th workplace had a long career as an SDE/SDM and ended up leaving that place to go work at a consulting firm in technical presales. Next, this person pursued but didn’t finish an MBA and came back to the same company in a TPM role. This person, before they hit 40, ended up creating and running one of the highest margin the products I know of. That’s a freaking massive impact to have in a multi-billion dollar business. This person continues to innovate and inspire teams to build great things.
That’s what you want out of TPM. You want passionate technologists who can innovate, invent, and simplify - all while keeping the customer and business constraints top of mind.
In comparison to what I’ve observed thus far, I’ll provide a slightly different response. I believe myself to be very technical. I probably worked on C++ code for 5-8k hours. On-premises and in the cloud, I’ve architected, developed, and led development on distributed systems. I’ve also performed operations and am very accustomed to pager duties.
I currently don’t spend any time on any of that stuff. Product management only Having said that, I work in a very technical environment and am still regarded as one of the team’s more technical members.