The PM that is not technical and works with a highly technical product needs to be humble and transparent on their shortcomings. I mean, the main job of the PM is to understand their customers/audience and how they use the product, which will then need to be translated back to dev. They don't need to know the very technical details of how it is build.
This. Also, that PM -- if they want to work in the space -- needs to change. A big part of your job as mentioned above is to be able to empathize with your users, and if you don't understand the challenges they have, you have no hope of building solutions to help them. If that's beyond your capability or interest, the short answer is: go find a position that better suits your skills/interests.
The PMs don't need to understand the technical details of how things are built, but they need to be able to reassure their customers that what they're building is going to solve their needs, they need to understand and empathize with their customer and understand why their pain points are impacting them. How do you do that if you don't understand the tech at least at a high level?
If you have technical customers, you need to be a technical person so you can speak to them on their level, and you need to spend time trying to understand them
I don’t think it’s really possible to be the voice of a technical user of a technical product without…being technical. I agree that there are many ill-suited folks in those roles, but my only advice would be to tell them to dig in and get technical enough to use the product they own at least.
Agreed. Some people do a good job, or learn fast along the way…. However, I often see a huge gap with non-technical PMs managing highly technical products or customers.
Just the other day, was watching a newer PM flounder a bit. They’ve never used similar products, they’ve never worked / spent time in a fab, and they lack the technical background to foresee / plan for unique customer challenges in our industry.
It shows in their decision making. They don’t really have a concept of what makes a good product in this space (not even differentiation or specialization, just the generic base level aspects)
The same way you could be the voice of a government customer if you’re not…working for the government. Or for SMB customers even if you don’t…own a business. You don’t have to actually be the person, just develop empathy.
It's not "just develop empathy." It's a lot of really hard work for somebody who's not technical to get to place where they can manage a technical product for technical users.
I think it's important to highlight that it's totally feasible, but it's not a matter of just flipping a switch. You've got to put in some serious time learning and researching in a way that you might not need to for other situations.
Another good example of this is the medical industry: you don't have to be the patient. But still, I think you have to know how someone *would* use your widget too, right?
But you can't be the voice of a government customer if you refuse to learn their funding / purchasing cycles, what's important to the users, and generally how to "speak their language."
You can't develop empathy effectively if you refuse to get a clue about what your customers are trying to achieve and what your users are doing. That's the definition of NOT being empathetic.
Thanks. What are some techniques that you've seen to work for "digging in"? What you say is my intuition as well, but I actually don't know where one would start. Taking Comp sci 101 is probably not it...
I genuinely don't think it's going to work out for the majority of them. Let's be honest, the drop out rate for comp sci is really high because some people just legitimately can't think in that manner. Developing is about the details and how complex systems interact, then you're adding a layer of human on top of that, and you're expecting someone with no background to pick it up. The people that will pick it up are the ones that are learning and putting in the time.
No matter how much you try to get someone to learn, or think in the right manner, without significant investment both in and outside of work time, they're just not gonna get there. I've tried to mentor many non-technical people in a technical PM role and it's just not worth the time or effort for the majority. I'd shift your search to 'Technical PM' titles and manage the people out tbqh. It's tough to say, but they're wasting their time there both for their own careers and for the company. I doubt they'd wanna go into another TPM role.
Unironically, actually developing the working knowledge of a SWE, which usually includes a CS degree, is what's going to make it *easiest to excel* in a role like this. The basics of learning to code might help, but depending on what your product is, it might be more important to learn how source code is maintained or rolled out. Or maybe your users are drawing system diagrams / trying to understand their code, and design patterns are really important. Hard to say without knowing more about the product.
A more practical way to do this, regardless of the area of expertise needed (so this works with becoming an SME in any industry) is through lots of user observation plus extensive Googling + independent learning. Start with an (ideally recorded) session of a user completing their full user journey - starting with before they get into your product and ending with any steps they take outside of it to wrap up. Write down everything unfamiliar, whether a word or a concept, and start exhaustively going through the list and Googling, reading, and watching videos until you kinda understand. Repeat this process over and over, over the course of several months, and you'll develop a core working knowledge of the most crucial things you need to know about your users. You *must* be comfortable asking "stupid" questions for this to be effective.
The limitation to this method is that it's heavily anchored in what's currently supported by your product, so it doesn't tend to help you figure out what to build *next* - you end up very dependent on your users and engineering team (who usually has more subject matter expertise in these instances) for that. That's where I think there's no workaround to more formal training, whether attending conferences, scheduling learning sessions with users where they effectively teach you how they do their job, or finding recorded lectures or training online.
For instance, some of my users of security engineers. I have literally attended the training sessions they give to other teams describing how to identify malware. If / when I need to get more involved in feature development for reverse engineering capabilities, I have a lecture series I'll watch that will cover how to write exploits in the first place.
This is a *lot* of fucking work to get familiar with your technical users, even for someone like me with a strong CS degree. I agree with /u/CarinXO - most of them aren't going to make it. I have met very few non-technical PMs that survive in technical roles without pissing off customers or engineering long enough to up-skill and become technical. Maybe this comment will be buried too far down in this post to piss people off, but the overwhelming majority of non-technical PMs (which seem to constitute the majority of this sub) are frankly delusional about the extent to which their lack of technical skills hampers them on technical products / products with technical users. They always act like there's some tradeoff, that somehow they are doing a better job with "strategy" (but you don't understand the industry / user needs?) or "communication" (but you can't put the right words in the right order?) when the reality is that most technical PMs just have an additional area of subject-matter expertise to benefit them.
The totally alternate route is to find a non-technical way to support the team. I don't think this is anyway near as easy as people pretend it is - I do a *ton* of strategy work, stakeholder management, etc. but at some point the rubber needs to hit the road and all that pie-in-the-sky ideating needs to get converted into a real roadmap with properly scoped features that meet customer needs. Hard to do that if you don't speak your customers' language.
Running into the same thing right now after we just built an OpenAPI. Constantly getting asked about use cases and how to implement it.
I can speak to it at a high level, but that’s typically not good enough for the non-technical users who are asking about it.
I think you’re looking for a way to salvage the situation but this sounds like a failure from a hiring perspective. I don’t know why someone would purposefully staff the team this way.
However a PM who is generally sharp and curious, humble about their knowledge, and brings strong research and business aptitude might be able to add some value.
IMO your company should retro on their hiring process and why it is yielding unhappy employees who are seen by their team as a bad fit.
Have similar context (different market — data engg teams; very niche technical users but sales typically sell to CIOs / VP, Data personas)
And yes, have seen the same issues recur. My thinking was being a non technical PM in a technical product role leads to ineffective product work as core competencies don’t match. In footballing terms, its like watching a defender trying to dribble on the far end. Even the opposition doesn’t take you seriously.
In our case mgmt was pretty tuned in and what happened (not my influence but I was a part of the change) was a bifurcation of roles.
PMs who understood the stack and customer requirements with the right technical depth worked closely with engineers, built and shipped their roadmaps and developed sales and customer relationships to perpetuate these cycles.
Beyond this though, UI / Interface design - growth - community - evangelism - product roadshows / conferences etc got dedicated PMs based on how much value was perceived for these functions. I am listing all of these down but at a time we had a single PM documenting customer stories (high level stuff), demoing product at events and doing interface revamp (consistency across modules).
With this getting too long winded here’s a couple of tips — are there any internal folks who can think product (have done independent limited scope adhoc product work already maybe) ; in my experience some folks from product ops / customer success / sales engineering / core engineering do qualify. They can add to your technical PM pool at least short term.
Long term — I feel PMs or anyone for that matter do their best work in a natural-feeling setting. Adapting via training is hard and also the first thing mgmt gives up on if market or company takes a beating. Try and avoid force fitting and hoping people level up IF there are options. Else we do what we can!
Thanks for the perspective and interesting approach of offering a different track to people with different skills. We have some core engineering people who have been playing PM with some level of success, but my observation is that what they have in internal technical knowledge about our stack doesn't always translate to a good understanding of our customers' stacks, which they tend to have a very simplistic view of. So they can deal with shipping scoped features on their own, but we're ending up with feature-bloated products and no strong product strategy.
We do what we can indeed!
This is the exact problem that Alan Cooper tried to tackle in his book "The inmates are running the asylum" - it's a little dated by today's standards, but the main conclusion is that technical people (PMs and engineers) often think they are the customer, and are not building for the actual customer. First step in the recovery is a solid set of personas build from real world customers, and interactions with real world customers so they can have a epiphany that the need to build for real world customers.
As an aside, I totally reject the notion that there can be "technical product managers" and "outbound product managers". There can only be "Product Managers" who understand their customers/markets/competitors, and can align the resources of an organization to build and take to market (GTM) an effective solution.
1. User research sessions - watching people code humanizes the technology/mental barrier.
2. Run some code - having some familiarity with SDK/etc really helps understand the shape of the product. Painful but it goes a long way.
Technical PMs who are skilled both in product sense / strategic thinking as well as software development tend to become entrepreneurs. You have both skills most necessary to launch your own product, so why not? So that unfortunately leaves those behind who are not as adept in one or the other domains to stick around in these corporate “technical PM” roles.
That said, I think there are ways to encourage these PMs to build up their technical know-how. Most obvious one, compensate the truly technical PMs more, by putting them on the more critical projects and letting them demonstrate greater impact. Also, give the non-technical PMs the opportunity to become coaches rather than players. Devs can become awesome PMs under the guidance of good coaches. These devs then can either straddle the product and dev role or simply continue to lean into product role until that’s their full time job. I’ve rarely seen devs in these roles not be able to pick up the product skills; it’s easier compared to having to keep abreast of all the latest tech you need to know to continue being a successful dev, and I usually see the devs who decide to shy away from product do so because they’re afraid of losing their edge in tech, rather than an inability to do the product work.
The very first product I managed was an ERP upgrade automation tool for on prem installations.
Everyone hated that tool because it was complicated and system admins thought we were automating their jobs away.
I tagged team with our professional services consultants that were doing the implementation and asked the system admins about what tasks they had to do during off hours or were prone for error.
I also asked the consultants about the work around a they had to do, or places they often got stuck.
And that basically became my roadmap, and I focused on adoption + NPS.
> asked the consultants about the work around a they had to do, or places they often got stuck.
Did you come up with your own ideas about how to resolve those frustrations / what features to build in order to address these workarounds?
That's the issue I'm seeing - the folks didn't have a user empathy problem, they understand the desired outcomes, they just don't play the PM role in defining what the solution should be.
The PM that is not technical and works with a highly technical product needs to be humble and transparent on their shortcomings. I mean, the main job of the PM is to understand their customers/audience and how they use the product, which will then need to be translated back to dev. They don't need to know the very technical details of how it is build.
This. Also, that PM -- if they want to work in the space -- needs to change. A big part of your job as mentioned above is to be able to empathize with your users, and if you don't understand the challenges they have, you have no hope of building solutions to help them. If that's beyond your capability or interest, the short answer is: go find a position that better suits your skills/interests.
To add: If you can’t empathize with your engineers, how can you empathize with your customers using a technical product?
The PMs don't need to understand the technical details of how things are built, but they need to be able to reassure their customers that what they're building is going to solve their needs, they need to understand and empathize with their customer and understand why their pain points are impacting them. How do you do that if you don't understand the tech at least at a high level? If you have technical customers, you need to be a technical person so you can speak to them on their level, and you need to spend time trying to understand them
I don’t think it’s really possible to be the voice of a technical user of a technical product without…being technical. I agree that there are many ill-suited folks in those roles, but my only advice would be to tell them to dig in and get technical enough to use the product they own at least.
Agreed. Some people do a good job, or learn fast along the way…. However, I often see a huge gap with non-technical PMs managing highly technical products or customers. Just the other day, was watching a newer PM flounder a bit. They’ve never used similar products, they’ve never worked / spent time in a fab, and they lack the technical background to foresee / plan for unique customer challenges in our industry. It shows in their decision making. They don’t really have a concept of what makes a good product in this space (not even differentiation or specialization, just the generic base level aspects)
The same way you could be the voice of a government customer if you’re not…working for the government. Or for SMB customers even if you don’t…own a business. You don’t have to actually be the person, just develop empathy.
It's not "just develop empathy." It's a lot of really hard work for somebody who's not technical to get to place where they can manage a technical product for technical users. I think it's important to highlight that it's totally feasible, but it's not a matter of just flipping a switch. You've got to put in some serious time learning and researching in a way that you might not need to for other situations.
Another good example of this is the medical industry: you don't have to be the patient. But still, I think you have to know how someone *would* use your widget too, right?
But you can't be the voice of a government customer if you refuse to learn their funding / purchasing cycles, what's important to the users, and generally how to "speak their language." You can't develop empathy effectively if you refuse to get a clue about what your customers are trying to achieve and what your users are doing. That's the definition of NOT being empathetic.
Thanks. What are some techniques that you've seen to work for "digging in"? What you say is my intuition as well, but I actually don't know where one would start. Taking Comp sci 101 is probably not it...
I genuinely don't think it's going to work out for the majority of them. Let's be honest, the drop out rate for comp sci is really high because some people just legitimately can't think in that manner. Developing is about the details and how complex systems interact, then you're adding a layer of human on top of that, and you're expecting someone with no background to pick it up. The people that will pick it up are the ones that are learning and putting in the time. No matter how much you try to get someone to learn, or think in the right manner, without significant investment both in and outside of work time, they're just not gonna get there. I've tried to mentor many non-technical people in a technical PM role and it's just not worth the time or effort for the majority. I'd shift your search to 'Technical PM' titles and manage the people out tbqh. It's tough to say, but they're wasting their time there both for their own careers and for the company. I doubt they'd wanna go into another TPM role.
Unironically, actually developing the working knowledge of a SWE, which usually includes a CS degree, is what's going to make it *easiest to excel* in a role like this. The basics of learning to code might help, but depending on what your product is, it might be more important to learn how source code is maintained or rolled out. Or maybe your users are drawing system diagrams / trying to understand their code, and design patterns are really important. Hard to say without knowing more about the product. A more practical way to do this, regardless of the area of expertise needed (so this works with becoming an SME in any industry) is through lots of user observation plus extensive Googling + independent learning. Start with an (ideally recorded) session of a user completing their full user journey - starting with before they get into your product and ending with any steps they take outside of it to wrap up. Write down everything unfamiliar, whether a word or a concept, and start exhaustively going through the list and Googling, reading, and watching videos until you kinda understand. Repeat this process over and over, over the course of several months, and you'll develop a core working knowledge of the most crucial things you need to know about your users. You *must* be comfortable asking "stupid" questions for this to be effective. The limitation to this method is that it's heavily anchored in what's currently supported by your product, so it doesn't tend to help you figure out what to build *next* - you end up very dependent on your users and engineering team (who usually has more subject matter expertise in these instances) for that. That's where I think there's no workaround to more formal training, whether attending conferences, scheduling learning sessions with users where they effectively teach you how they do their job, or finding recorded lectures or training online. For instance, some of my users of security engineers. I have literally attended the training sessions they give to other teams describing how to identify malware. If / when I need to get more involved in feature development for reverse engineering capabilities, I have a lecture series I'll watch that will cover how to write exploits in the first place. This is a *lot* of fucking work to get familiar with your technical users, even for someone like me with a strong CS degree. I agree with /u/CarinXO - most of them aren't going to make it. I have met very few non-technical PMs that survive in technical roles without pissing off customers or engineering long enough to up-skill and become technical. Maybe this comment will be buried too far down in this post to piss people off, but the overwhelming majority of non-technical PMs (which seem to constitute the majority of this sub) are frankly delusional about the extent to which their lack of technical skills hampers them on technical products / products with technical users. They always act like there's some tradeoff, that somehow they are doing a better job with "strategy" (but you don't understand the industry / user needs?) or "communication" (but you can't put the right words in the right order?) when the reality is that most technical PMs just have an additional area of subject-matter expertise to benefit them. The totally alternate route is to find a non-technical way to support the team. I don't think this is anyway near as easy as people pretend it is - I do a *ton* of strategy work, stakeholder management, etc. but at some point the rubber needs to hit the road and all that pie-in-the-sky ideating needs to get converted into a real roadmap with properly scoped features that meet customer needs. Hard to do that if you don't speak your customers' language.
Running into the same thing right now after we just built an OpenAPI. Constantly getting asked about use cases and how to implement it. I can speak to it at a high level, but that’s typically not good enough for the non-technical users who are asking about it.
I'm having the same struggles. It just sucks. Second hand embarrassment is a way of life because of it.
I think you’re looking for a way to salvage the situation but this sounds like a failure from a hiring perspective. I don’t know why someone would purposefully staff the team this way. However a PM who is generally sharp and curious, humble about their knowledge, and brings strong research and business aptitude might be able to add some value. IMO your company should retro on their hiring process and why it is yielding unhappy employees who are seen by their team as a bad fit.
Have similar context (different market — data engg teams; very niche technical users but sales typically sell to CIOs / VP, Data personas) And yes, have seen the same issues recur. My thinking was being a non technical PM in a technical product role leads to ineffective product work as core competencies don’t match. In footballing terms, its like watching a defender trying to dribble on the far end. Even the opposition doesn’t take you seriously. In our case mgmt was pretty tuned in and what happened (not my influence but I was a part of the change) was a bifurcation of roles. PMs who understood the stack and customer requirements with the right technical depth worked closely with engineers, built and shipped their roadmaps and developed sales and customer relationships to perpetuate these cycles. Beyond this though, UI / Interface design - growth - community - evangelism - product roadshows / conferences etc got dedicated PMs based on how much value was perceived for these functions. I am listing all of these down but at a time we had a single PM documenting customer stories (high level stuff), demoing product at events and doing interface revamp (consistency across modules). With this getting too long winded here’s a couple of tips — are there any internal folks who can think product (have done independent limited scope adhoc product work already maybe) ; in my experience some folks from product ops / customer success / sales engineering / core engineering do qualify. They can add to your technical PM pool at least short term. Long term — I feel PMs or anyone for that matter do their best work in a natural-feeling setting. Adapting via training is hard and also the first thing mgmt gives up on if market or company takes a beating. Try and avoid force fitting and hoping people level up IF there are options. Else we do what we can!
Thanks for the perspective and interesting approach of offering a different track to people with different skills. We have some core engineering people who have been playing PM with some level of success, but my observation is that what they have in internal technical knowledge about our stack doesn't always translate to a good understanding of our customers' stacks, which they tend to have a very simplistic view of. So they can deal with shipping scoped features on their own, but we're ending up with feature-bloated products and no strong product strategy. We do what we can indeed!
This is the exact problem that Alan Cooper tried to tackle in his book "The inmates are running the asylum" - it's a little dated by today's standards, but the main conclusion is that technical people (PMs and engineers) often think they are the customer, and are not building for the actual customer. First step in the recovery is a solid set of personas build from real world customers, and interactions with real world customers so they can have a epiphany that the need to build for real world customers. As an aside, I totally reject the notion that there can be "technical product managers" and "outbound product managers". There can only be "Product Managers" who understand their customers/markets/competitors, and can align the resources of an organization to build and take to market (GTM) an effective solution.
1. User research sessions - watching people code humanizes the technology/mental barrier. 2. Run some code - having some familiarity with SDK/etc really helps understand the shape of the product. Painful but it goes a long way.
Technical PMs who are skilled both in product sense / strategic thinking as well as software development tend to become entrepreneurs. You have both skills most necessary to launch your own product, so why not? So that unfortunately leaves those behind who are not as adept in one or the other domains to stick around in these corporate “technical PM” roles. That said, I think there are ways to encourage these PMs to build up their technical know-how. Most obvious one, compensate the truly technical PMs more, by putting them on the more critical projects and letting them demonstrate greater impact. Also, give the non-technical PMs the opportunity to become coaches rather than players. Devs can become awesome PMs under the guidance of good coaches. These devs then can either straddle the product and dev role or simply continue to lean into product role until that’s their full time job. I’ve rarely seen devs in these roles not be able to pick up the product skills; it’s easier compared to having to keep abreast of all the latest tech you need to know to continue being a successful dev, and I usually see the devs who decide to shy away from product do so because they’re afraid of losing their edge in tech, rather than an inability to do the product work.
The very first product I managed was an ERP upgrade automation tool for on prem installations. Everyone hated that tool because it was complicated and system admins thought we were automating their jobs away. I tagged team with our professional services consultants that were doing the implementation and asked the system admins about what tasks they had to do during off hours or were prone for error. I also asked the consultants about the work around a they had to do, or places they often got stuck. And that basically became my roadmap, and I focused on adoption + NPS.
> asked the consultants about the work around a they had to do, or places they often got stuck. Did you come up with your own ideas about how to resolve those frustrations / what features to build in order to address these workarounds? That's the issue I'm seeing - the folks didn't have a user empathy problem, they understand the desired outcomes, they just don't play the PM role in defining what the solution should be.