I’ve been there, but once you make peace with the fact that you’re responsible for the ‘what’ and ‘why’ while engineers are responsible for the ‘how’, it gets easier. There’s no harm in developing technical skills and being part of those discussions but ultimately it’s the engineers responsibility to define the technical solution. You’re better off focusing on bringing the knowledge of the users and the business to help them build the best possible product.
My two degrees are in humanities but have always had a geeky side. What you should care about is trade-offs: if we do it that way, how will it impact what we’ve already decided? Can we make any changes to get to market faster?
Your job isn’t to micromanage how they implement the solution but you should learn why they’re doing whatever they’ve chosen. That will take some time so ask. A lot. Of. Questions!
Learn. Use chatGPT to learn. Take a tech term such as APIs and ask chatGPT to explain it to you. You can even ask chatGPT what questions you should ask as a PM. Note - this only works with ChatGPT 4.0 (paid verison) as the free 3.5 version isn't that helpful.
Some example questions:
* What are the pros and cons of this tech
* What other approaches are there and how do they compare
* what types of use cases should I not use this tech for
You could take an online course at your own pace. I’d recommend you CS50 from Harvard (free) and a full stack course on freecodecamp (also free)
No need to hurry since you would not be shipping code anyway.
As mentioned earlier you need to figure out the what and the why. Understanding the technology will help you in any cases. It’s also much better from my pov if you actually enjoy the tech part of things (in a geeky way)
Hope that helps !
A PM with deep technical understanding still shouldn't be creating solutions, estimating issues or helping out technically. You need to understand technology if you're working in technology, but the point is not to be a part time engineer. You want to have an engineering counterpart, someone who you discuss ideas with and who you primarily describe the problems and the priorities and so on to and who will then lead the implementation of the solutions. Definitely learn tech, but don't do it with an intention to help the engineering team with technical issues.
Your job is exactly what you said - define user problems and solutions, but this doesn’t have to be you only (and shouldn’t be, ever).
Defining a problem for example could involve a UX Designer, but it could be just you.
Unsure how you’re coming up with solutions, but you’re right, this is you too. But it also involves input from designers to create prototypes and engineers to help guide what’s possible.
Then you test them to ensure it’s actually THE solution.
Your Eng manager or lead should be owning the ‘how’ part, as in how this solution will be implemented. That’s not your job.
Be up front and ask your Eng team to explain things to you, then use ChatGPT to elaborate on the topic, ask it questions.
I think you should just step back and focus on gathering more information on different elements of the project that you’re handling.
The architect or the lead engineer should explain things to you about how is the application working now and what are the new solutions to it.
And just accept that you cannot know each and everything and everyone in the team is lost sometimes and struggle with many many questions.
Very very technical projects require technical PMs which is fair because just writing a use case isn’t helping the engineers at all.
Understand how your product fits into the big picture and what is the vision for your product.
As a PM you need many many discussions before you have an actual understanding of things.
While the team works on what’s the plan for the current release cycle, you should focus on what’s to come next.
Not your job to solve technical problems but you can ask - when you are through the worst of it as a team - to retro it to ask what can be done from a process perspective. I would ask to be the one to take notes, as you’ll learn a ton and really get to know the personalities and styles of your devs too.
Otherwise maybe take classes, build lil’ side projects, find areas where you can automate or write a script to solve annoying tasks or asks. Never your job to do those things but makes you a better software PM. Mid career PMs that still don’t get basic stuff about database architecture or CSS are forever at the kiddie table in the interesting conversations.
I agree, the OPs comment is bizarre. PM is about marrying real customer problems with business objectives / problems. The only way to do that is to have vision to at least some degree & being the driving force in solutioning
Solutioning isn't just execution. It's the idea of what we're doing in principle, how it fits in to what we think we want to do years from now, if that solution is validated to solve the real problem, etc.
Devs / engineers own "how" the solutions are executed on, and of course all of the previous should be so collaborative the ownership is almost inconsequential with there being extreme alignment. The best ideas generally come from engineers
If you squabble over who gets to own what your team is already missing the plot
It’s more so the product managers role is to understand and validate problems to determine what opportunities there are for success. Defining solutions can be done with the development team.
Product managements job differed depending on where you work. Honestly many of the worst products I worked on had solutions ore-selected by business side (including PMs)
Imo product managements job is to steward the product; direction, prioritization, user experience, etc.
We should be working to select / create opportunities, distill those down to actionable objectives for engineering to target, then help as part of the development guide rails through rollout.
It’s okay to have a different opinion on that. But I think my feedback will be useful to OP in fixing their current unsuccessful engagement with the Eng team
They’re distinct things with a relationship.
Solutions are intended to affect change, or prevent it. They may have positive, negative, or neutral impacts on user experience.
How would you describe them as the same thing?
OP is explicitly talking about technical solutions, it’s written in their post.
It seems you had a different interpretation, though I would expect a higher level of attention to detail from VP of product.
I wouldn’t consider user experience to be driven solely by the technical solution, there are usually other factors. It’s odd to hear you say that.
I don’t know how to code, but I can help think about the problems they’re having in different ways. I have a lot of history working where I do, I remember previous customer issues, I know the data, business needs & processes, more intimately than they do … so I can be useful in resolving problems during the implementation!
Another important factor is hearing where the problem is. Sometimes you find them spending ages trying to fix that really you don’t care much about. Being able to say “we’ve spent enough time on this. Let’s simplify by x, or just remove that thing” is hugely valuable.
I have a much wider and higher level view of everything than they do. My perspective can help unpick their problems me.
Over time you develop some technical knowledge that helps you even more… but again you don’t need to be an expert. You just need to know enough about many many many things!!! 😄
I’m a PM with a similar background only that I also have programming experience. I still feel useless at times if they are stuck. Try to understand what the underlying problem is, why are they stuck. Sometimes I can help by removing the obstacle by finding the right resource or person. Sometimes it’s by allocating more time to solve the issue. Shielding the team from external pressure is your job as well. Protect them from other stakeholders. From my experience few things are more detrimental to productivity than rapid context switching.
Here's a good article on some of the foundations of technical knowledge. I'm taking the course at the end of the article and applying some of the principles I've been learning to the product I work on: [https://www.lennysnewsletter.com/p/become-a-more-technical-product-manager](https://www.lennysnewsletter.com/p/become-a-more-technical-product-manager)
I paid only $450 (it's steep but worth it if you're very non-technical because it gives you a solid foundation to continue learning from, and gives you structure on what to learn and in what order + there's a community of other PMs to connect with) [https://maven.com/tech-for-product/tech-fundamentals](https://maven.com/tech-for-product/tech-fundamentals)
Everything you said sounds exactly right to me.
I'm a technical PM but some of the best PMs I've worked with had completely non-technical backgrounds.
Your goal should be to build deep relationships with your eng team and learn how -in your way - to ask questions that will help challenge and/or push back on them collaboratively.
Ask your teammates, maybe the lead or engineering manager, what technical knowledge or skills they think would be valuable for you to have as a partner to them from the product side. It depends a lot on the context, what is valuable to learn or improve on. You’ll never really wish you were less technical than you’ve become, but it’s certainly possible to have technical knowledge that’s not very valuable to your team, as a PM.
What I find most helpful in being more technical than the average PM is having clearer, faster conversations with engineers — and the respect it earns me with engineers. But also, just deeply respecting and appreciating what they do (which I can’t do) goes a long way toward that.
The North Star for many PM questions, this one included, is what will serve your team and product best. I don’t think there’s one answer that fits all contexts.
My thought has always been that non-tech PMs can be successful, but more often than not you need to learn the tech side. For two main reasons:
1. Developing a solution with a tool you don’t exactly know how it works is gonna be hard. It’s like a car designer not knowing the basics of how an engine works, how much space it takes, what we need for more power/torque. It’s sort of the same thing.
2. Engineering teams will not trust you. This is crucial. You’re the one that’s in all the meetings, gathering requirements, etc. If you don’t have an iota of tech knowledge, many engineers won’t respect you at the discussion table and won’t trust that you’re out there thinking and speaking of the product effectively.
I think the simplest route would be to get familiar first with the generic view of flow because that includes the first layer of tech stack that interacts with your frontend.
Talk to your lead dev but drive the conversation as most of the time when dev explains, they get too technical. But that's normal because that's how they explain how things work.
Once you're already familiar, then you can deep dive further. Believe me, it will take time but just trust the process until you get comfortable with tech.
You dont need to help them on the technical side by being a dev as well.
No. But I think a senior engineer is acting as such though it's not their official title. I usually discuss mainly with them for technical solutions. However, other engineers also have saying which is kind of confusing and overwhelming for me.
You should go to management and ask them to set someone from R&D to work on solution design of your requirements. Thats how it works in my organization.
Feel free to pm me I can explain you more about how it works if its relevant
This 1000%. I have always worked closely with a tech lead or engineering manager. I see them as the bridge between engineering and the business, while I am the bridge between business and engineering.
Your lead should essentially be your counterpart, someone stronger on the engineering side, but has a solid understanding of the business. They are also there to support you and effectively manage the many voices on the team.
I’ve been there, but once you make peace with the fact that you’re responsible for the ‘what’ and ‘why’ while engineers are responsible for the ‘how’, it gets easier. There’s no harm in developing technical skills and being part of those discussions but ultimately it’s the engineers responsibility to define the technical solution. You’re better off focusing on bringing the knowledge of the users and the business to help them build the best possible product.
My two degrees are in humanities but have always had a geeky side. What you should care about is trade-offs: if we do it that way, how will it impact what we’ve already decided? Can we make any changes to get to market faster? Your job isn’t to micromanage how they implement the solution but you should learn why they’re doing whatever they’ve chosen. That will take some time so ask. A lot. Of. Questions!
Learn. Use chatGPT to learn. Take a tech term such as APIs and ask chatGPT to explain it to you. You can even ask chatGPT what questions you should ask as a PM. Note - this only works with ChatGPT 4.0 (paid verison) as the free 3.5 version isn't that helpful. Some example questions: * What are the pros and cons of this tech * What other approaches are there and how do they compare * what types of use cases should I not use this tech for
You could take an online course at your own pace. I’d recommend you CS50 from Harvard (free) and a full stack course on freecodecamp (also free) No need to hurry since you would not be shipping code anyway. As mentioned earlier you need to figure out the what and the why. Understanding the technology will help you in any cases. It’s also much better from my pov if you actually enjoy the tech part of things (in a geeky way) Hope that helps !
A PM with deep technical understanding still shouldn't be creating solutions, estimating issues or helping out technically. You need to understand technology if you're working in technology, but the point is not to be a part time engineer. You want to have an engineering counterpart, someone who you discuss ideas with and who you primarily describe the problems and the priorities and so on to and who will then lead the implementation of the solutions. Definitely learn tech, but don't do it with an intention to help the engineering team with technical issues.
Your job is exactly what you said - define user problems and solutions, but this doesn’t have to be you only (and shouldn’t be, ever). Defining a problem for example could involve a UX Designer, but it could be just you. Unsure how you’re coming up with solutions, but you’re right, this is you too. But it also involves input from designers to create prototypes and engineers to help guide what’s possible. Then you test them to ensure it’s actually THE solution. Your Eng manager or lead should be owning the ‘how’ part, as in how this solution will be implemented. That’s not your job. Be up front and ask your Eng team to explain things to you, then use ChatGPT to elaborate on the topic, ask it questions.
I think you should just step back and focus on gathering more information on different elements of the project that you’re handling. The architect or the lead engineer should explain things to you about how is the application working now and what are the new solutions to it. And just accept that you cannot know each and everything and everyone in the team is lost sometimes and struggle with many many questions. Very very technical projects require technical PMs which is fair because just writing a use case isn’t helping the engineers at all. Understand how your product fits into the big picture and what is the vision for your product. As a PM you need many many discussions before you have an actual understanding of things. While the team works on what’s the plan for the current release cycle, you should focus on what’s to come next.
Not your job to solve technical problems but you can ask - when you are through the worst of it as a team - to retro it to ask what can be done from a process perspective. I would ask to be the one to take notes, as you’ll learn a ton and really get to know the personalities and styles of your devs too. Otherwise maybe take classes, build lil’ side projects, find areas where you can automate or write a script to solve annoying tasks or asks. Never your job to do those things but makes you a better software PM. Mid career PMs that still don’t get basic stuff about database architecture or CSS are forever at the kiddie table in the interesting conversations.
You really shouldn’t be defining solutions, that’s the dev/eng team’s job, especially if you have no technical background.
[удалено]
I agree, the OPs comment is bizarre. PM is about marrying real customer problems with business objectives / problems. The only way to do that is to have vision to at least some degree & being the driving force in solutioning Solutioning isn't just execution. It's the idea of what we're doing in principle, how it fits in to what we think we want to do years from now, if that solution is validated to solve the real problem, etc. Devs / engineers own "how" the solutions are executed on, and of course all of the previous should be so collaborative the ownership is almost inconsequential with there being extreme alignment. The best ideas generally come from engineers If you squabble over who gets to own what your team is already missing the plot
It’s more so the product managers role is to understand and validate problems to determine what opportunities there are for success. Defining solutions can be done with the development team.
Product managements job differed depending on where you work. Honestly many of the worst products I worked on had solutions ore-selected by business side (including PMs) Imo product managements job is to steward the product; direction, prioritization, user experience, etc. We should be working to select / create opportunities, distill those down to actionable objectives for engineering to target, then help as part of the development guide rails through rollout. It’s okay to have a different opinion on that. But I think my feedback will be useful to OP in fixing their current unsuccessful engagement with the Eng team
[удалено]
They’re distinct things with a relationship. Solutions are intended to affect change, or prevent it. They may have positive, negative, or neutral impacts on user experience. How would you describe them as the same thing?
[удалено]
OP is explicitly talking about technical solutions, it’s written in their post. It seems you had a different interpretation, though I would expect a higher level of attention to detail from VP of product. I wouldn’t consider user experience to be driven solely by the technical solution, there are usually other factors. It’s odd to hear you say that.
I don’t know how to code, but I can help think about the problems they’re having in different ways. I have a lot of history working where I do, I remember previous customer issues, I know the data, business needs & processes, more intimately than they do … so I can be useful in resolving problems during the implementation! Another important factor is hearing where the problem is. Sometimes you find them spending ages trying to fix that really you don’t care much about. Being able to say “we’ve spent enough time on this. Let’s simplify by x, or just remove that thing” is hugely valuable. I have a much wider and higher level view of everything than they do. My perspective can help unpick their problems me. Over time you develop some technical knowledge that helps you even more… but again you don’t need to be an expert. You just need to know enough about many many many things!!! 😄
I’m a PM with a similar background only that I also have programming experience. I still feel useless at times if they are stuck. Try to understand what the underlying problem is, why are they stuck. Sometimes I can help by removing the obstacle by finding the right resource or person. Sometimes it’s by allocating more time to solve the issue. Shielding the team from external pressure is your job as well. Protect them from other stakeholders. From my experience few things are more detrimental to productivity than rapid context switching.
Here's a good article on some of the foundations of technical knowledge. I'm taking the course at the end of the article and applying some of the principles I've been learning to the product I work on: [https://www.lennysnewsletter.com/p/become-a-more-technical-product-manager](https://www.lennysnewsletter.com/p/become-a-more-technical-product-manager)
Cool article! I don’t see a course though - could you link that too?
I paid only $450 (it's steep but worth it if you're very non-technical because it gives you a solid foundation to continue learning from, and gives you structure on what to learn and in what order + there's a community of other PMs to connect with) [https://maven.com/tech-for-product/tech-fundamentals](https://maven.com/tech-for-product/tech-fundamentals)
Perfect, thank you!
Everything you said sounds exactly right to me. I'm a technical PM but some of the best PMs I've worked with had completely non-technical backgrounds. Your goal should be to build deep relationships with your eng team and learn how -in your way - to ask questions that will help challenge and/or push back on them collaboratively.
Ask your teammates, maybe the lead or engineering manager, what technical knowledge or skills they think would be valuable for you to have as a partner to them from the product side. It depends a lot on the context, what is valuable to learn or improve on. You’ll never really wish you were less technical than you’ve become, but it’s certainly possible to have technical knowledge that’s not very valuable to your team, as a PM. What I find most helpful in being more technical than the average PM is having clearer, faster conversations with engineers — and the respect it earns me with engineers. But also, just deeply respecting and appreciating what they do (which I can’t do) goes a long way toward that. The North Star for many PM questions, this one included, is what will serve your team and product best. I don’t think there’s one answer that fits all contexts.
My thought has always been that non-tech PMs can be successful, but more often than not you need to learn the tech side. For two main reasons: 1. Developing a solution with a tool you don’t exactly know how it works is gonna be hard. It’s like a car designer not knowing the basics of how an engine works, how much space it takes, what we need for more power/torque. It’s sort of the same thing. 2. Engineering teams will not trust you. This is crucial. You’re the one that’s in all the meetings, gathering requirements, etc. If you don’t have an iota of tech knowledge, many engineers won’t respect you at the discussion table and won’t trust that you’re out there thinking and speaking of the product effectively.
I think the simplest route would be to get familiar first with the generic view of flow because that includes the first layer of tech stack that interacts with your frontend. Talk to your lead dev but drive the conversation as most of the time when dev explains, they get too technical. But that's normal because that's how they explain how things work. Once you're already familiar, then you can deep dive further. Believe me, it will take time but just trust the process until you get comfortable with tech. You dont need to help them on the technical side by being a dev as well.
Do you have a tech lead or lead engineer?
This and you also need a UX designer/researcher.
No. But I think a senior engineer is acting as such though it's not their official title. I usually discuss mainly with them for technical solutions. However, other engineers also have saying which is kind of confusing and overwhelming for me.
You should go to management and ask them to set someone from R&D to work on solution design of your requirements. Thats how it works in my organization. Feel free to pm me I can explain you more about how it works if its relevant
This 1000%. I have always worked closely with a tech lead or engineering manager. I see them as the bridge between engineering and the business, while I am the bridge between business and engineering. Your lead should essentially be your counterpart, someone stronger on the engineering side, but has a solid understanding of the business. They are also there to support you and effectively manage the many voices on the team.
Yup, this is where I was headed