Ask HN: Move to product management at 35?
132 comments
My $0.02, having been a PM for many years:
Read Cracking the PM Interview [1] (for an overview of the job, not the actual interview tips) and The Lean Startup [2] (for general philosophy).
35 is a great age for a PM, especially since PM's often start elsewhere -- maturity is a plus here. I'd say there are 3 main ways into it -- as an engineer, who starts to do PM-type stuff on a team where there's no PM. As a designer, who starts to do PM-type stuff on a team where there's no PM. Or as an MBA who has a good sense for engineering and design. Certifications generally don't mean anything -- communication and leadership skills, good judgment, experience and a proven track record are what matter. But all those things can be demonstrated in previous non-PM roles, in order to make the initial switch.
Also, if you want to be a PM then you'd better enjoy meetings, slides, people, and communicating & convincing all day long, day-in day-out. If those make you say an enthusiastic "yes that's me!" then jump right in. If not... you're gonna have a bad time...
[1] https://www.amazon.com/Cracking-PM-Interview-Product-Technol...
[2] https://www.amazon.com/Lean-Startup-Entrepreneurs-Continuous...
Read Cracking the PM Interview [1] (for an overview of the job, not the actual interview tips) and The Lean Startup [2] (for general philosophy).
35 is a great age for a PM, especially since PM's often start elsewhere -- maturity is a plus here. I'd say there are 3 main ways into it -- as an engineer, who starts to do PM-type stuff on a team where there's no PM. As a designer, who starts to do PM-type stuff on a team where there's no PM. Or as an MBA who has a good sense for engineering and design. Certifications generally don't mean anything -- communication and leadership skills, good judgment, experience and a proven track record are what matter. But all those things can be demonstrated in previous non-PM roles, in order to make the initial switch.
Also, if you want to be a PM then you'd better enjoy meetings, slides, people, and communicating & convincing all day long, day-in day-out. If those make you say an enthusiastic "yes that's me!" then jump right in. If not... you're gonna have a bad time...
[1] https://www.amazon.com/Cracking-PM-Interview-Product-Technol...
[2] https://www.amazon.com/Lean-Startup-Entrepreneurs-Continuous...
> Also, if you want to be a PM then you'd better enjoy meetings, slides, people, and communicating & convincing all day long, day-in day-out
I transitioned from dev to architect. This statement is so true, even more so for PMs.
I transitioned from dev to architect. This statement is so true, even more so for PMs.
I’ve always understood that one of the most important pieces of the PM role is to act as a sort of negotiator between design/development and all other stakeholders. Customers and everybody else in the business all want their own things, and all have their own priorities. The good PMs that I’ve known have kept those people happy, managed their expectations well, and mostly shielded design/development from their demands and politics.
35 is a good age as it increases the likelihood that the PM will have parenting experience which provides the benefit of improving expectation mgmt, negotiation, and communication skills to a non-technical audience.
Now that I think about it, a lot of the people I most enjoy working with in the office are parents, and the kind of parents who are obviously really good parents.
I've read how being responsible for family make employees plan their work better because they want to get home for the dinner, how it makes them more responsible or loyal – but that's the first time I hear about parenting experience directly affecting management skills. Some similarities are obvious now that I think about it – you want to help them grow and flourish. You set expectations and put boundaries while avoiding micromanagement and try not to spoil internal gratification with bribes. Well, except firing – you don't fire kids early due to lack of culture fit.
Or the likelihood of developing these skills as a member of successful teams.
Any tips for a dev aspiring to transition to architect?
This is all great info. One additional note. The best way to become a PM is to just start doing the job.
Even if you're on a team with a PM already, offer to write a few of the specs. Or if there's no room to do that, then create a side project where you go through the product development process and show your work. Create sort of a portfolio that demonstrates your abilities.
Even if you're on a team with a PM already, offer to write a few of the specs. Or if there's no room to do that, then create a side project where you go through the product development process and show your work. Create sort of a portfolio that demonstrates your abilities.
Pm is really about being customer facing (communication skills, understanding business needs), and being able to make insightful trade offs. Developers can write specs. Spec writing is a plus for pm, but not core.
My suggestion that the best way to crack pm other than comm skills is doing competitive surveys.
My suggestion that the best way to crack pm other than comm skills is doing competitive surveys.
Also served as a pm for 5+ years.
I recommend you build and release your own product start to finish. This helps you get exposure to parts you got to avoid in your engineering role.
I see product management as a producer role which includes the successful release and iteration. This is best learned by doing and if you don’t have a team, you be the team.
I recommend you build and release your own product start to finish. This helps you get exposure to parts you got to avoid in your engineering role.
I see product management as a producer role which includes the successful release and iteration. This is best learned by doing and if you don’t have a team, you be the team.
> Also, if you want to be a PM then you'd better enjoy meetings, slides, people, and communicating & convincing all day long, day-in day-out.
Leave me in my room with my beloved keyboard! I can sense other likely-minded beings over the wire. No slides, no meetings, no politics. Only the austerity of code, measurements, technical merit.
Leave me in my room with my beloved keyboard! I can sense other likely-minded beings over the wire. No slides, no meetings, no politics. Only the austerity of code, measurements, technical merit.
No meetings, no politics? Lots a dev jobs have both don’t they, especially as you become more senior and/or want to drive change in how things are done.
It depends on what you want. If you want some sort of "purity of code", that's great.
If you want more (especially control), you'll never have it. Except for your side projects.
If you want more (especially control), you'll never have it. Except for your side projects.
Technical co-founder with controlling equity is the role you meant, not side projects. Like most co-founders of big tech companies nowadays.
Founders of big tech companies deal with politics on a level you can’t imagine.
Asin actual, literal politics. As in, appearing before Congress to convince them why what's good for your company is good for America. And/or sending campaign contributions their way to help with the convincing.
But there's a lot of fun to be had between now and then.
But there's a lot of fun to be had between now and then.
Don’t get carried away, most startups never rise to that level, even fairly big ones.
[deleted]
Such a vision is a fallacy.
Thank you for this. I appreciate it. I like collaboration and working with people to drive projects and get things done. As an IC who has been a tech lead (without direct reports), I haven't had a chance to demonstrate or learn a lot of leadership nuances, but I've recently moved to a scrum master role, and am learning a lot there. I'll definitely read up on the books you suggested. Thank you so much.
You can say it's none of my business, but may I ask you why would you like to change?
I cannot ask for advice and counter with a "none of your business" when asked questions. That's not how any of this works. Thank you for your question.
I can probably write an essay on this, but here's a TLDR version. I do like coding, and will definitely continue working on my side projects. Although programming pays quite well, I'm not sure of the long term payoffs of continuing as a programmer (unless you are one of the Linus Torvalds, or in a similar league - which I am no where close to).
Longer term: I do want to get to a point in my career where I would like to influence product strategy (focus on the whys) a s a VP of Product Management vs. VP of Engineering.
Having said that I do believe I have the skills to be a good PM. I will explore this, and if it's not the right fit, I can switch back.
If you have a completely different perspective, please let me know.
I can probably write an essay on this, but here's a TLDR version. I do like coding, and will definitely continue working on my side projects. Although programming pays quite well, I'm not sure of the long term payoffs of continuing as a programmer (unless you are one of the Linus Torvalds, or in a similar league - which I am no where close to).
Longer term: I do want to get to a point in my career where I would like to influence product strategy (focus on the whys) a s a VP of Product Management vs. VP of Engineering.
Having said that I do believe I have the skills to be a good PM. I will explore this, and if it's not the right fit, I can switch back.
If you have a completely different perspective, please let me know.
IME if you are going to product for the "money", I think in the long run you're more likely to be disappointed than hit VP of Product. There's just fewer spots in product vs engineering. I think it's much more driven by chance and other factors.
But from an overall career experience, it will likely open new doors for you. Whether those doors are the ones you want remain to be seen.
I also think the vast majority of PM roles are just implementing some Director/VP of Product's wish lists rather than doing much strategy on your own. And hopefully you encounter good product direction, but IME that's few and far in between. Moving up has been much more about adherence to the company's vision/politics than good products/tech.
Plus there's also the interesting dynamic of overall eng/PM relationship within a company. Those can vary from very good to pretty darn toxic.
I don't mean to discourage you from trying. I learned a lot of doing it... but I think it's a tougher path. Depends on your personality and interests. Often it's much more a people job than a tech job, even for very techy products.
To be fair, the product role is also much more varied from company to company (than eng). You may find a place where it is more about the tech and less about company politics.
My bigger question for you is are you at the stage of your (personal) life where you can afford to take a chance on your career. Switching back may not be as easy as you think... especially if you truly embrace the product side (and also depends on what part of tech you're in).
While it may be okay at your present company, IME it's very easy to end up in a wierdo trap of having your feet on two different ships heading in different directions.
I've also got some funny stories about engineering managers who think I've been infected by some disease due to my time in product.
Source: I started my career as engineering IC for several years, moved to product for several, and have now returned to engineering IC for several.
But from an overall career experience, it will likely open new doors for you. Whether those doors are the ones you want remain to be seen.
I also think the vast majority of PM roles are just implementing some Director/VP of Product's wish lists rather than doing much strategy on your own. And hopefully you encounter good product direction, but IME that's few and far in between. Moving up has been much more about adherence to the company's vision/politics than good products/tech.
Plus there's also the interesting dynamic of overall eng/PM relationship within a company. Those can vary from very good to pretty darn toxic.
I don't mean to discourage you from trying. I learned a lot of doing it... but I think it's a tougher path. Depends on your personality and interests. Often it's much more a people job than a tech job, even for very techy products.
To be fair, the product role is also much more varied from company to company (than eng). You may find a place where it is more about the tech and less about company politics.
My bigger question for you is are you at the stage of your (personal) life where you can afford to take a chance on your career. Switching back may not be as easy as you think... especially if you truly embrace the product side (and also depends on what part of tech you're in).
While it may be okay at your present company, IME it's very easy to end up in a wierdo trap of having your feet on two different ships heading in different directions.
I've also got some funny stories about engineering managers who think I've been infected by some disease due to my time in product.
Source: I started my career as engineering IC for several years, moved to product for several, and have now returned to engineering IC for several.
That's interesting, I find myself in a similar position.
I like coding and I like to improve my coding skills and knowledge, but I feel I am more of generalist than a specialist, I am always lurking around HN, PH, IH, looking at products, trying to always get a little bit more about product strategy, marketing, design and UX.
I have considered a transition into a PM role but I'm still not sure I'm quite ready to step away from the developer role, a part of me would like to have an awesome project that I could build my own company around but I'm just not there yet either.
Either way, I'll be lurking the responses in this thread. Good luck with your move.
I like coding and I like to improve my coding skills and knowledge, but I feel I am more of generalist than a specialist, I am always lurking around HN, PH, IH, looking at products, trying to always get a little bit more about product strategy, marketing, design and UX.
I have considered a transition into a PM role but I'm still not sure I'm quite ready to step away from the developer role, a part of me would like to have an awesome project that I could build my own company around but I'm just not there yet either.
Either way, I'll be lurking the responses in this thread. Good luck with your move.
This is cool, thanks! I myself am mostly okay with dev but I think communication is very important no matter where you are in the process.
Sometimes I feel that I can't influence the product even though I care for it - but then I grow bitter and start a job seeking cycle.
Sometimes I feel that I can't influence the product even though I care for it - but then I grow bitter and start a job seeking cycle.
Other book recommendations for preparing to be a PM:
- Decode & Conquer
- Inspired (Marty Cagan)
- Radical Focus (about OKRs)
- Decode & Conquer
- Inspired (Marty Cagan)
- Radical Focus (about OKRs)
Thank you
[deleted]
> Also, if you want to be a PM then you'd better enjoy meetings, slides, people, and communicating & convincing all day long, day-in day-out.
For me that's a huge nope, also it's why I love working with a good PM when you're a developer, they're like your partner in crime so to speak!
For me that's a huge nope, also it's why I love working with a good PM when you're a developer, they're like your partner in crime so to speak!
Can anyone recommend additional books on being a highly effective PM and managing ALL THE THINGS. Thx
It makes me sad to hear people thinking they are too old for something at 35. Unless you make it big financially there is a good chance you will have another 30 years ahead of you. That means you are just at the first third of your career.
Do what you think you want to do. I thought about getting an MBA or PhD at that age and thought I was too old. Now I am 51 and thinking how easy and useful it would have been to do something at 35. Later in life you will almost always regret things you didn't do earlier.
Do what you think you want to do. I thought about getting an MBA or PhD at that age and thought I was too old. Now I am 51 and thinking how easy and useful it would have been to do something at 35. Later in life you will almost always regret things you didn't do earlier.
I took at as OP thought they were too young for the role, since PMs tend to be older.
I've been a PM for 3+ years, I switched after being a full-stack developer for 4 years. When I made the move the company had about 150 employees.
My experience so far: the role is very broad, and the responsibilities are -very- different across companies and products. The specifics depend on many things, like maturity/size/culture of your company, pricing of your product, whether or not it is open source, etc.
On one side of the spectrum you have PMs who are very close to the development teams, and you might still be contributing code regularly. You might be a sort of architect who also makes sure documentation is in order and who handles user feedback/discussions. These PMs are typically "user-focused", in that they try to improve the product for the end user.
On the other side you have a much more market-focused role (MBA type) where you'll do market analysis, pricing, marketing, sales materials, etc. You might see the dev team once a week, or maybe only the engineering managers. These PMs are typically "customer-focused", so targeting the buyers of the product (who might not be the actual end-user, but for example a CIO, depending on your market).
In any case: age/wisdom/maturity matters, it is not a junior role. You will also be in a lot of meetings. You will be the face of the product and you need to enjoy interacting with people.
edit: added the sentences about "user-focused" vs "customer-focused".
My experience so far: the role is very broad, and the responsibilities are -very- different across companies and products. The specifics depend on many things, like maturity/size/culture of your company, pricing of your product, whether or not it is open source, etc.
On one side of the spectrum you have PMs who are very close to the development teams, and you might still be contributing code regularly. You might be a sort of architect who also makes sure documentation is in order and who handles user feedback/discussions. These PMs are typically "user-focused", in that they try to improve the product for the end user.
On the other side you have a much more market-focused role (MBA type) where you'll do market analysis, pricing, marketing, sales materials, etc. You might see the dev team once a week, or maybe only the engineering managers. These PMs are typically "customer-focused", so targeting the buyers of the product (who might not be the actual end-user, but for example a CIO, depending on your market).
In any case: age/wisdom/maturity matters, it is not a junior role. You will also be in a lot of meetings. You will be the face of the product and you need to enjoy interacting with people.
edit: added the sentences about "user-focused" vs "customer-focused".
I feel many comments here are confusing "Product" Management with "Project" Management. Many describing being a "people person" which isn't (in my eyes) a needed trait for a product manager, but is for a project manager. There are obviously social aspects of being a product manager, but much of it has to do with relaying what's in your head moreso than trying to manage people day-to-day.
To me, what matters for the OP, is that you are actually a product person? In my experience too many people are just terrible at understanding their field, products, how to actually break down product problems to their basic pieces and build solutions up from there. Being able to trust their designers, ui/ux, engineers to take their vision and execute (or simply just being good at transferring the vision in their head to being executable by others.
If you're not great at the above, please don't try and shoehorn yourself into product management. I've had too many terrible product managers that should have been something entirely different in my day that just literally ruins years of people's lives.
If you are not interested / good at the above, I'd consider a more Project Management role, which is about figuring out how to take a team and turn them into a well-oiled machine that loves working together towards common goals.
In many places (like startups) the line between the two above obviously blurs, my only concern is moving into Product Management role that you're not fit for. I say this more in general for people thinking about this themselves - mostly because of all the Product / Project Managers I've seen, I'd say 2/10 of them I'd actually want to work with again (though they both had engineering backgrounds which works in your favor).
To me, what matters for the OP, is that you are actually a product person? In my experience too many people are just terrible at understanding their field, products, how to actually break down product problems to their basic pieces and build solutions up from there. Being able to trust their designers, ui/ux, engineers to take their vision and execute (or simply just being good at transferring the vision in their head to being executable by others.
If you're not great at the above, please don't try and shoehorn yourself into product management. I've had too many terrible product managers that should have been something entirely different in my day that just literally ruins years of people's lives.
If you are not interested / good at the above, I'd consider a more Project Management role, which is about figuring out how to take a team and turn them into a well-oiled machine that loves working together towards common goals.
In many places (like startups) the line between the two above obviously blurs, my only concern is moving into Product Management role that you're not fit for. I say this more in general for people thinking about this themselves - mostly because of all the Product / Project Managers I've seen, I'd say 2/10 of them I'd actually want to work with again (though they both had engineering backgrounds which works in your favor).
I do think Product management is more people facing than project management.
You can't really build a product without talking with the customer or talking to other departments especially sales/marketing/customer service. They know what the users want, what the bounce rate is, what metrics the company is lagging at.
You can't really build a product without talking with the customer or talking to other departments especially sales/marketing/customer service. They know what the users want, what the bounce rate is, what metrics the company is lagging at.
>> You can't really build a product without talking with the customer or talking to other departments especially sales/marketing/customer service
A friend of mine works at a large enterprise company on a multimillion dollar software project. Their dev team has never spoken to a customer or product manager (there is a PM team, they've just never spoken with the devs). It also takes them a long time to ship software. It's very odd.
A friend of mine works at a large enterprise company on a multimillion dollar software project. Their dev team has never spoken to a customer or product manager (there is a PM team, they've just never spoken with the devs). It also takes them a long time to ship software. It's very odd.
On the contrary it seems predictable. Product managers tend to come from the agile way of working. Enterprises do waterfall. I suspect there are layers and layers of formalised specs, but no real understanding of what the customers want (rather than what they say they want), by the pm or the devs
Thank you for your advice.
"In my experience too many people are just terrible at understanding their field, products, how to actually break down product problems to their basic pieces and build solutions up from there."
How does one go about understanding whether one has the right product skills, or has the ability to pick them up (apart from actually jumping in)? As an engineer, I feel I'm somewhat good at breaking technical projects down and solving them. Are any of those skills transferable?
"In my experience too many people are just terrible at understanding their field, products, how to actually break down product problems to their basic pieces and build solutions up from there."
How does one go about understanding whether one has the right product skills, or has the ability to pick them up (apart from actually jumping in)? As an engineer, I feel I'm somewhat good at breaking technical projects down and solving them. Are any of those skills transferable?
To some extent the environment you work in can be helpful / detrimental to figuring this out.
At a startup / workplaces with that vibe where you don't actually have product influence what you want to do is track how the product progresses in relation to your thoughts on what you would do if you were able to influence the product. Consider literally every product decision and if you would have done that, or something else, and why / why not you think it would work. At some point you'll be able to see if those product features work out, or don't, and can compare that to your ideas on the subject. Hopefully whatever your thoughts are (whether constructive or destructive) towards the product decisions match what actually transpired more often than not, then you probably at least are able to have a finger on the pulse for what's good / bad. For me, a lot of it isn't always knowing what the right decision is, but knowing what the wrongs one are (going down the wrong path too often or too deep is really how bad products are made).
If you're at a startup / workplace where you are able to insert yourself / your input into the product pipeline, then do so and see what happens. If you actually have good / valuable ideas and are able to push them into fruition through whatever current product infrastructure that exists at your company then that should be a plus as well.
I personally believe there is no replacement for having done it before yourself. As an engineer, building products for people whether they are clients, consumers, other business, etc directly are what can give you the best product knowledge feedback. The most I learned as an engineer about building products people want was through personal interactions with consumers of a game I built, along with interacting with clients for applications being constructed and fielding feedback directly from their consumers.
Most of the above handles the "Product" side of Product Management, the rest is of course how well you work with people, but that probably goes without needing be said.
At a startup / workplaces with that vibe where you don't actually have product influence what you want to do is track how the product progresses in relation to your thoughts on what you would do if you were able to influence the product. Consider literally every product decision and if you would have done that, or something else, and why / why not you think it would work. At some point you'll be able to see if those product features work out, or don't, and can compare that to your ideas on the subject. Hopefully whatever your thoughts are (whether constructive or destructive) towards the product decisions match what actually transpired more often than not, then you probably at least are able to have a finger on the pulse for what's good / bad. For me, a lot of it isn't always knowing what the right decision is, but knowing what the wrongs one are (going down the wrong path too often or too deep is really how bad products are made).
If you're at a startup / workplace where you are able to insert yourself / your input into the product pipeline, then do so and see what happens. If you actually have good / valuable ideas and are able to push them into fruition through whatever current product infrastructure that exists at your company then that should be a plus as well.
I personally believe there is no replacement for having done it before yourself. As an engineer, building products for people whether they are clients, consumers, other business, etc directly are what can give you the best product knowledge feedback. The most I learned as an engineer about building products people want was through personal interactions with consumers of a game I built, along with interacting with clients for applications being constructed and fielding feedback directly from their consumers.
Most of the above handles the "Product" side of Product Management, the rest is of course how well you work with people, but that probably goes without needing be said.
Both of these roles sound super interesting to me, but I am only a freshman undergrad (studying marketing or finance? & computer science).
I really hate the business school in all honesty. Initially I thought it would be full of people who are passionate about finding what a consumer wants and building it. The reality is that many of these students just want to be suites in either consulting, investment banking, or corporate roles. I am super passionate about building great products and working with A players, but I don't want to be another "pointy haired manager."
Wondering if any of you have advice on how to break into the UX research roles with hope of becoming a project manager or product manager further down the road.
I really hate the business school in all honesty. Initially I thought it would be full of people who are passionate about finding what a consumer wants and building it. The reality is that many of these students just want to be suites in either consulting, investment banking, or corporate roles. I am super passionate about building great products and working with A players, but I don't want to be another "pointy haired manager."
Wondering if any of you have advice on how to break into the UX research roles with hope of becoming a project manager or product manager further down the road.
UX is a tough one, I'm still unsure what the magic bullet there is as I personally believe a lot of itself is generally handwaivy. It's one of those things that you just have some magical touch with (which approximately no one has so don't be foolish and believe that you're the one), or something you gain over time through trial and error.
It's probably hard to get into a UX role that doesn't involve UI as well. So one side of that is being able to actual design UI, and build out some random "product" ideas with the various current tools available which allow you to design UI + make prototypes that seem real (something like Sketch, there's tons of others). This can be helpful for getting some experience together on your own time which hopefully could get you a junior UI/UX somewhere.
The other side of things is being a UI driven developer and try to get in as some sort of frontend UI/UX engineer which deals more with making user experience better vs fleshing out the business logic / internals. These sorts of jobs tend to exist more at larger shops / enterprises than smaller ones.
The third side (yea, this one has three sides) is to just try and get a foot in the door as a junior PM and grow from there. I honestly don't believe this is the best route as I think all it does is breed "pointy haired managers".
I really believe you need some experience in a space before being able to be a good "* Manager" of any kind, whether that be project, product, engineering, or otherwise.
It's probably hard to get into a UX role that doesn't involve UI as well. So one side of that is being able to actual design UI, and build out some random "product" ideas with the various current tools available which allow you to design UI + make prototypes that seem real (something like Sketch, there's tons of others). This can be helpful for getting some experience together on your own time which hopefully could get you a junior UI/UX somewhere.
The other side of things is being a UI driven developer and try to get in as some sort of frontend UI/UX engineer which deals more with making user experience better vs fleshing out the business logic / internals. These sorts of jobs tend to exist more at larger shops / enterprises than smaller ones.
The third side (yea, this one has three sides) is to just try and get a foot in the door as a junior PM and grow from there. I honestly don't believe this is the best route as I think all it does is breed "pointy haired managers".
I really believe you need some experience in a space before being able to be a good "* Manager" of any kind, whether that be project, product, engineering, or otherwise.
I did it at ~28 at Arbor Networks, moving from lead on the service provider product to product marketing manager on the enterprise product. We were at the time 8 figures revenue and had a direct enterprise sales team with, meh, 10s of staff.
Age doesn't matter. Worth knowing that a pretty standard trajectory for PMs is: graduate CS at 22, work in the industry for 3-4 years, go to B-school, graduate at ~28-29, start out of college as a PM. So you're kind of right in the range.
I can't imagine how a certification would matter, but I transitioned to PM in the same company instead of applying cold, and I was hired (for both roles) in part because I had a reputation in the field I was in. I doubt very much that you'd learn anything from the certification (or, for that matter, from business school) that would help you do that job.
I could write a pretty decent list of hazards for engineers moving to the business side of technology companies. But for a PM, probably the most important one is: product managers aren't project managers and they're not engineering managers. You have to simultaneously let go of what's happening in the repository while not letting go of the MRD/feature-function-benefits. I found that to be a pretty nasty tightrope walk and didn't handle it well.
I left Arbor in 2005, so my advice is pre-YC-era, and a lot has changed at startups (though less so at enterprise software companies!). Every role I've had since has been entrepreneurial, so while I'd say that I use skills I developed (haphazardly) as a PM, I haven't had a formal PM role since.
Age doesn't matter. Worth knowing that a pretty standard trajectory for PMs is: graduate CS at 22, work in the industry for 3-4 years, go to B-school, graduate at ~28-29, start out of college as a PM. So you're kind of right in the range.
I can't imagine how a certification would matter, but I transitioned to PM in the same company instead of applying cold, and I was hired (for both roles) in part because I had a reputation in the field I was in. I doubt very much that you'd learn anything from the certification (or, for that matter, from business school) that would help you do that job.
I could write a pretty decent list of hazards for engineers moving to the business side of technology companies. But for a PM, probably the most important one is: product managers aren't project managers and they're not engineering managers. You have to simultaneously let go of what's happening in the repository while not letting go of the MRD/feature-function-benefits. I found that to be a pretty nasty tightrope walk and didn't handle it well.
I left Arbor in 2005, so my advice is pre-YC-era, and a lot has changed at startups (though less so at enterprise software companies!). Every role I've had since has been entrepreneurial, so while I'd say that I use skills I developed (haphazardly) as a PM, I haven't had a formal PM role since.
As someone who went from a technical role (director/architect) into PM, I selected out pretty fast.
When I looked at the differences across organizations where I had worked with other Product Managers, between the ones who selected out, survived, succeeded, and the ones who were great, there were themes.
The great ones (I met two), were charismatic, flexible, technical enough to make engineers feel appreciated, and were the kinds of people who radiated enthusiasm and success. Think ivy grad confidence with an evangelist belief in their product. Likable, clearly on their way to bigger things.
Ones who just succeeded were strong organizational influencers and operators who practically hid their technical understanding, and made it incumbent on more technical people to explain themselves. They kept others talking while they moved pieces and pulled strings. M.Sc/PhD types, classic org power players.
The survivors were corporate natives who brought professionalism to the startups I was at. A few did time in Big 5 consultancies. Often adjacent to confusion, always useful to someone, albeit never clearly to whom. They were experts at allegiances and light relationships and I admired how they managed both the constant contempt from engineering and the relentless outrage of the sales team. They were teflon strong.
People who selected out (I among them) or who rode a product into the ground were a mixed bag of experiments gone wrong. The marketing person with a programming course, the legacy team member, the polymath everyone thought someone else understood, "the only person who understands how it works," the patsy, the brown shoes and patagonia vest guy, the founder in training, etc.
Where I've seen PMs fail seemed to be the result of failing to maintain a balance of flexibility, credibility, and coherence.
There are lots of ways to succeed as a PM and it's a very cool job. It's a rare area where a magic touch is both required and rewarded.
When I looked at the differences across organizations where I had worked with other Product Managers, between the ones who selected out, survived, succeeded, and the ones who were great, there were themes.
The great ones (I met two), were charismatic, flexible, technical enough to make engineers feel appreciated, and were the kinds of people who radiated enthusiasm and success. Think ivy grad confidence with an evangelist belief in their product. Likable, clearly on their way to bigger things.
Ones who just succeeded were strong organizational influencers and operators who practically hid their technical understanding, and made it incumbent on more technical people to explain themselves. They kept others talking while they moved pieces and pulled strings. M.Sc/PhD types, classic org power players.
The survivors were corporate natives who brought professionalism to the startups I was at. A few did time in Big 5 consultancies. Often adjacent to confusion, always useful to someone, albeit never clearly to whom. They were experts at allegiances and light relationships and I admired how they managed both the constant contempt from engineering and the relentless outrage of the sales team. They were teflon strong.
People who selected out (I among them) or who rode a product into the ground were a mixed bag of experiments gone wrong. The marketing person with a programming course, the legacy team member, the polymath everyone thought someone else understood, "the only person who understands how it works," the patsy, the brown shoes and patagonia vest guy, the founder in training, etc.
Where I've seen PMs fail seemed to be the result of failing to maintain a balance of flexibility, credibility, and coherence.
There are lots of ways to succeed as a PM and it's a very cool job. It's a rare area where a magic touch is both required and rewarded.
"...the polymath everyone thought someone else understood, "the only person who understands how it works," the patsy, the brown shoes and patagonia vest guy..." Wow - know em all. Genius!
As a product manager you OWN IT. If the product is clumsy or doesn't make sense to the end user you are failing. If the product doesn't drive target revenue then you have absolutely failed.
Keeping that in mind the objectives vary pretty broadly. Perhaps the most important thing to keep in mind is that product management is NOT project management. Your goal is to deliver product success in order to hit a revenue target. That said product quality and product exposure are more important than release timelines, which is perhaps opposite of a project management role.
To really understand product management you must understand what drives user behavior in the choice and usage of your product versus the competition. Research helps a lot, but you still always find yourself surprised by the behavior of your users. Your assumptions of your users' behavior is probably often flawed.
Keeping that in mind the objectives vary pretty broadly. Perhaps the most important thing to keep in mind is that product management is NOT project management. Your goal is to deliver product success in order to hit a revenue target. That said product quality and product exposure are more important than release timelines, which is perhaps opposite of a project management role.
To really understand product management you must understand what drives user behavior in the choice and usage of your product versus the competition. Research helps a lot, but you still always find yourself surprised by the behavior of your users. Your assumptions of your users' behavior is probably often flawed.
Surely your age will assist you here (I’m 35 too). Unlike software development which is typically a “young mans game” due to the constant need to learn the latest thing (I know, sweeping generalisation), Product Management requires significant past experience of products. As a developer, I’m sure you’ve worked on many successful and non-successful products, and have a good insight as to what went well and not. I think former developers can make the best product managers (it’s the move I made) as you have internal insight into what it takes to make the product (assuming it’s a software product).
“Unlike software development which is typically a “young mans game” due to the constant need to learn the latest thing”
Why? As an old developer you don’t need to constantly learn new things?
Why? As an old developer you don’t need to constantly learn new things?
Because software development generally doesn't reward experience. Technologies change with the wind, and a new grad has just as much experience on the latest JS Foo Framework 0.1 (released yesterday!) as someone with 20 years of industry experience. In addition, older folks say negative things like "don't use JS Foo 0.1 in production...it was released yesterday, and there are battle-tested frameworks to do the same thing in $boring_old_language". This makes younger programmers frowny and sad, and less likely to work overtime in exchange for pizza. After all, those old guys don't know anything, or they wouldn't be using such boring, messy code in the first place!
You do gain some generalizable skills over time (and there are always exceptions to the rule) but in practice, older developers are more expensive versions of that which can be bought at a college career fair -- and the marginal difference in efficiency is offset by the young turks' propensity to work long hours while being paid in snacks.
You do gain some generalizable skills over time (and there are always exceptions to the rule) but in practice, older developers are more expensive versions of that which can be bought at a college career fair -- and the marginal difference in efficiency is offset by the young turks' propensity to work long hours while being paid in snacks.
> the marginal difference in efficiency is offset by the young turks' propensity to work long hours while being paid in snacks.
I don't know if this is true. Even just with my meager 6-7 years of professional experience I can do things now that would've been impossible for me when I was starting out as a professional. Experienced devs aren't just more efficient - everything else being equal, they're more capable along all the axes you can measure a software engineer on.
Additionally if an experienced engineer has non-sucky people skills they can even turn your junior engineers into seniors with mentoring and example-setting. Which means you'll be employing a senior engineer for the price of a junior engineer, at least until they learn their increased value and ask for a raise/move on. /s
I don't know if this is true. Even just with my meager 6-7 years of professional experience I can do things now that would've been impossible for me when I was starting out as a professional. Experienced devs aren't just more efficient - everything else being equal, they're more capable along all the axes you can measure a software engineer on.
Additionally if an experienced engineer has non-sucky people skills they can even turn your junior engineers into seniors with mentoring and example-setting. Which means you'll be employing a senior engineer for the price of a junior engineer, at least until they learn their increased value and ask for a raise/move on. /s
Younger developers are more likely to have learned their trade using the latest thing whereas older developers have to do their job and invest time in learning the latest thing.
Is there a correlation between "do their job" and "learning the latest thing"? I've often heard that the best advice is to use the most boring/stable tools which tend not to be the latest and the greatest but which focus on getting the job done.
Which is fine at your current job. At your next job they're more likely than not going to be using the latest thing though so you'll need to learn it.
If you know it's a sweeping generalization, perhaps don't make it? Software development is maybe a young person's (surely not just for men, right?) game at startups, but that's because startups don't pay as well and have narrow technical needs. Big companies hire young people, too, because they have a lot of grunt work to do and recent college grads are cheap. However, an older developer who's managed her career well is valuable to most organizations.
Age doesn't matter. Passion matters. If you have an interest, give it a try: either ask to take some responsibility writing specs for the product you're currently working on, or ask if you can transition to a team as a junior PM.
I've known three engineers in their 30s who transitioned into PM roles. One went back to school and got an MBA first. One simply changed roles. And one tried being a junior PM for a couple of quarters before deciding, fuck this shit, I'm going back to coding.
One difficult part of the transition is pay ranges. At least in SF where engineers are difficult to find, the PMs pay range is generally lower. You may be asked to take a salary adjustment when you adjust roles. If so, and your life situation makes this difficult, it might not be right for you.
Also, ask yourself, how are my soft skills? As an engineer you can maybe get away without many, but you will not succeed as a PM without them. Am I good or great at talking, explaining, persuading, negotiating, and mediating? This matters way more than your current age.
I've known three engineers in their 30s who transitioned into PM roles. One went back to school and got an MBA first. One simply changed roles. And one tried being a junior PM for a couple of quarters before deciding, fuck this shit, I'm going back to coding.
One difficult part of the transition is pay ranges. At least in SF where engineers are difficult to find, the PMs pay range is generally lower. You may be asked to take a salary adjustment when you adjust roles. If so, and your life situation makes this difficult, it might not be right for you.
Also, ask yourself, how are my soft skills? As an engineer you can maybe get away without many, but you will not succeed as a PM without them. Am I good or great at talking, explaining, persuading, negotiating, and mediating? This matters way more than your current age.
I am 32 and switched to Product Ownership last year, after 15 years of design and front end development. It was, to some extent, nearly seamless since I knew the product and processes inside out after being a team leader in the same product. I guarantee you will face some unknown challenges along the way, but they will also make you a better developer if you ever plan to switch back (greater business and process knowledge is often what a developer needs to really shine, alongside the obvious tech skills).
Age brings wisdom and balance, which are mandatory in a management position if you want to lead, not merely boss people around.
So go for it!
Age brings wisdom and balance, which are mandatory in a management position if you want to lead, not merely boss people around.
So go for it!
One thing to think about - are you looking to transition in your current company or in a new company?
I'm a PM at Google. One thing that works here is having eng do 20% PM projects or do a PM rotation for a few months to get a taste for the life before committing fully. I don't know how it works at your company but you could look into taking on some PM responsibilities before making the move.
A certification may explain more about the role and give you background knowledge, but it wouldn't help in skill development IMO. The best way to learn PM'ing is to do it. And if you're interviewing for a PM role, it's much better to talk about actual work than certifications.
Lastly, age is not an issue and it's probably better if you have more industry experience before moving to a PM role.
Of course, these are my opinions and not that of Google, etc.
I'm a PM at Google. One thing that works here is having eng do 20% PM projects or do a PM rotation for a few months to get a taste for the life before committing fully. I don't know how it works at your company but you could look into taking on some PM responsibilities before making the move.
A certification may explain more about the role and give you background knowledge, but it wouldn't help in skill development IMO. The best way to learn PM'ing is to do it. And if you're interviewing for a PM role, it's much better to talk about actual work than certifications.
Lastly, age is not an issue and it's probably better if you have more industry experience before moving to a PM role.
Of course, these are my opinions and not that of Google, etc.
> I'm a PM at Google. One thing that works here is having eng do 20% PM projects or do a PM rotation for a few months to get a taste for the life before committing fully.
As a dev, does it make more sense to apply as an eng and then try to transfer over to PM using 20% projects / rotational programs or apply as PM directly?
As a dev, does it make more sense to apply as an eng and then try to transfer over to PM using 20% projects / rotational programs or apply as PM directly?
I've read that transitioning into a new role in a new company almost never works out. I'm looking to transition to PM role in my current company since I already know the culture and some of the products.
Would strongly recommend anything by Marty Cagan, including http://svpg.com and https://svpg.com/inspired-how-to-create-products-customers-l...
Avoid certifications at all cost
Avoid certifications at all cost
Thank you
While PM role means different things in different companies (even between teams in bigger companies) let me tell you what you will miss the most transitioning over from Eng:
You can no longer hit a button to compile your work and see the output (even if it is a small part of the whole). As a PM from initial proposal to outcome is typically 6 months or more. And you fill that time with negotiation, communication and a whole lot of politics (the good and bad sides). Then you may see the outcome you had envisioned (but no guarantees).
It is just, different. Be prepared.
You can no longer hit a button to compile your work and see the output (even if it is a small part of the whole). As a PM from initial proposal to outcome is typically 6 months or more. And you fill that time with negotiation, communication and a whole lot of politics (the good and bad sides). Then you may see the outcome you had envisioned (but no guarantees).
It is just, different. Be prepared.
I've been a software engineer and moved into product management 8 years ago. I've worked for medium sized private companies as well as large public ones. I don't know what is right for you, but here's how it worked out for me and maybe you can deduct some value from my learnings.
I started out at 27 with zero experience, but I saw that our business had a problem that could not be fixed in my role as an engineer. It needed a coordinated strategic effort to become successful. How to become a PM: see the need and just decide to be the PM. A good boss loves employees that want responsibilities.
Here's what I love about the role:
- You have an incredible amount of responsibility. Owning responsibility for the outcome of your product is a truly satisfying experience.
- You learn the difference between what truly ads value and what is vanity. This applies to metrics, features and issues.
- You learn a tonne about other disciplines. Wearing many hats makes you value and internalize the importance of design, marketing, sales, HR and everything else more than ever.
- You cooperate with other companies which expands your network into all sorts of verticals.
- You prepare yourself to think like an entrepreneur which gives you the confidence to start your own thing. And you're getting paid for it, which is nice.
The not so glorious:
- You have full product responsibility, but often not the executive power you need to change things. Budgets are created by finance, engineers are managed by the CTO and the sales team is incentivized by their own leaders. This means you have to negotiate and inevitably deal with some form of politics to get shit done. Never make the mistake to complain to anyone: you took full responsibility, including navigating politics.
- You are _not_ an engineer anymore so avoid the following pitfall:, Don't tell engineers _how_ to do something, only _what_ to do. If you f*ck this one up, engineers will feel no responsibility anymore for your product and recovery is almost impossible. Engineers will not give you the same form of credit anymore. You are not writing code anymore so you don't really feel their pain.
- You will do a lot of stuff at the same time and you won't feel a lot of accomplishment on a day to day basis. If you can delay gratification, it can be incredibly rewarding in the long run though!
From engineer to PM was a great move for me personally and I'm really glad I had the confidence to jump in the deep and great people to support me.
I started out at 27 with zero experience, but I saw that our business had a problem that could not be fixed in my role as an engineer. It needed a coordinated strategic effort to become successful. How to become a PM: see the need and just decide to be the PM. A good boss loves employees that want responsibilities.
Here's what I love about the role:
- You have an incredible amount of responsibility. Owning responsibility for the outcome of your product is a truly satisfying experience.
- You learn the difference between what truly ads value and what is vanity. This applies to metrics, features and issues.
- You learn a tonne about other disciplines. Wearing many hats makes you value and internalize the importance of design, marketing, sales, HR and everything else more than ever.
- You cooperate with other companies which expands your network into all sorts of verticals.
- You prepare yourself to think like an entrepreneur which gives you the confidence to start your own thing. And you're getting paid for it, which is nice.
The not so glorious:
- You have full product responsibility, but often not the executive power you need to change things. Budgets are created by finance, engineers are managed by the CTO and the sales team is incentivized by their own leaders. This means you have to negotiate and inevitably deal with some form of politics to get shit done. Never make the mistake to complain to anyone: you took full responsibility, including navigating politics.
- You are _not_ an engineer anymore so avoid the following pitfall:, Don't tell engineers _how_ to do something, only _what_ to do. If you f*ck this one up, engineers will feel no responsibility anymore for your product and recovery is almost impossible. Engineers will not give you the same form of credit anymore. You are not writing code anymore so you don't really feel their pain.
- You will do a lot of stuff at the same time and you won't feel a lot of accomplishment on a day to day basis. If you can delay gratification, it can be incredibly rewarding in the long run though!
From engineer to PM was a great move for me personally and I'm really glad I had the confidence to jump in the deep and great people to support me.
This resonates. Same age when I made the move, saw the need in the company and took on many responsibilities without any real experience.
The product manager of the project I work on is about 55 and many of the other PMs at my company are also age 40+. However I applied for an internal PM position and was passed over for a younger guy with less technical and managerial qualifications but better people skills overall.
I thought I was an excellent candidate because of my decade of experience in QA lead roles on sizable teams but I have gotten a reputation over time as having a bit of a hard edge personality-wise, which I'm working on fixing.
I cannot stress the importance of having good people skills in this kind of role.
I thought I was an excellent candidate because of my decade of experience in QA lead roles on sizable teams but I have gotten a reputation over time as having a bit of a hard edge personality-wise, which I'm working on fixing.
I cannot stress the importance of having good people skills in this kind of role.
In my experience there are a couple kinds of product management. There is very user focused product management, and technical product management.
User-focused PMing is making tools that work for people - working with marketing, UX and client teams, to make sure you have a good Product/Market fit.
Technical PMing is more about making sure that you are building things the right way - making sure that the underlying models that your tools utilise are close to reality and understanding the roadmap that you will need to hit so that your releases will always be useful. It different from an architects role who is fed the information about the domain, the technical PM needs to synthesise this for the tech team to build, but there is a lot of overlap.
For engineers, it makes a lot of sense to become a technical PM, via being a team lead/architect, managing your devs more and coding less, and understanding more about why you are building what you are building that how what you are building it, and working with other PMs. From there, you do become more and more part of the design process, going up the food chain as it were, closer to the source of your user stories.
It's not the quick way of doing it, but PMs who understand the entire ecosystem are obviously more well rounded and may well be more effective than ones who have fallen into it from client management or marketing!
User-focused PMing is making tools that work for people - working with marketing, UX and client teams, to make sure you have a good Product/Market fit.
Technical PMing is more about making sure that you are building things the right way - making sure that the underlying models that your tools utilise are close to reality and understanding the roadmap that you will need to hit so that your releases will always be useful. It different from an architects role who is fed the information about the domain, the technical PM needs to synthesise this for the tech team to build, but there is a lot of overlap.
For engineers, it makes a lot of sense to become a technical PM, via being a team lead/architect, managing your devs more and coding less, and understanding more about why you are building what you are building that how what you are building it, and working with other PMs. From there, you do become more and more part of the design process, going up the food chain as it were, closer to the source of your user stories.
It's not the quick way of doing it, but PMs who understand the entire ecosystem are obviously more well rounded and may well be more effective than ones who have fallen into it from client management or marketing!
I started with sort of an assistant product role at 32. The most important part is knowing how a product works inside out. It's easier to get into with full stack experience, and some marketing experience.
Also agreed that you really have to enjoy meetings. It's no longer a development role. It's a role where you become the communication line between the dev team and the client/users/QA/other depts.
You have to really understand what people are saying even when they're not saying. You also have to be really good at reading body language - people slouching when they're stuck or on something, or their eyes lighting up when you tell them something they want to hear. You have to be good at giving the right questions to unlock these answers.
It's incredibly difficult to go from being developer to product because product does everything developers shouldn't be doing.
I'd say the fastest route is to be a startup founder. A slightly slower route is to take on the product role at your company, but this usually means a performance hit because you can't develop well when 2-4 days of your week are dedicated to meetings.
You can also directly ask your boss if you can transition into the role. People who want to take product roles are very rare and expensive, and developers are much more valuable for the role vs people who took some certification.
Also agreed that you really have to enjoy meetings. It's no longer a development role. It's a role where you become the communication line between the dev team and the client/users/QA/other depts.
You have to really understand what people are saying even when they're not saying. You also have to be really good at reading body language - people slouching when they're stuck or on something, or their eyes lighting up when you tell them something they want to hear. You have to be good at giving the right questions to unlock these answers.
It's incredibly difficult to go from being developer to product because product does everything developers shouldn't be doing.
I'd say the fastest route is to be a startup founder. A slightly slower route is to take on the product role at your company, but this usually means a performance hit because you can't develop well when 2-4 days of your week are dedicated to meetings.
You can also directly ask your boss if you can transition into the role. People who want to take product roles are very rare and expensive, and developers are much more valuable for the role vs people who took some certification.
35 years old is the sweet spot for a PM coming from the technical side. Let's be honest, are you going to code for the rest of your life? Probably not the most sustainable future...
From experience, there's only one thing that is hard to come up with and to convince a company to hire you as a PM - your strategic thinking. I compare that to your ability to crack an algo problem on a whiteboard during a technical interview for a developer. You can be the best backend engineer in the world, you have to show your problem solving skills on a whiteboard in order to be considered as a "great" candidate.
All the other skills are workable, maybe communication skills don't necessarily come naturally for a developer. We all have different communication styles anyway, this is part of our identity. But you can learn how to design a great product, how to identify customer needs, write up documents, make a power point presentation, communicate with other teams, coordinate, etc. etc. Though, strategy is something that you will acquire throughout the years. That involves making a lot of mistakes as a PM, be exposed to a lot of different problems as a PM, etc.
You will most likely get rejected during the hiring process because of a lack of strategic thinking. Google about it, learn, work that area as much as you can. Good luck!
From experience, there's only one thing that is hard to come up with and to convince a company to hire you as a PM - your strategic thinking. I compare that to your ability to crack an algo problem on a whiteboard during a technical interview for a developer. You can be the best backend engineer in the world, you have to show your problem solving skills on a whiteboard in order to be considered as a "great" candidate.
All the other skills are workable, maybe communication skills don't necessarily come naturally for a developer. We all have different communication styles anyway, this is part of our identity. But you can learn how to design a great product, how to identify customer needs, write up documents, make a power point presentation, communicate with other teams, coordinate, etc. etc. Though, strategy is something that you will acquire throughout the years. That involves making a lot of mistakes as a PM, be exposed to a lot of different problems as a PM, etc.
You will most likely get rejected during the hiring process because of a lack of strategic thinking. Google about it, learn, work that area as much as you can. Good luck!
You are asking the wrong question, IMHO.
What does matter is what you like to do. If you are technical, like to try new things, implement, build , etc... things, then you might find Product Management quite boring.
If you are a « people » person and view yourself in a role between Marketing and Engineering, then go for it!
At 35, you might not know what you really like, yet... Might simply go for it for some time, and then if you decide to go back to a “builder” position, you will know _why_.
What does matter is what you like to do. If you are technical, like to try new things, implement, build , etc... things, then you might find Product Management quite boring.
If you are a « people » person and view yourself in a role between Marketing and Engineering, then go for it!
At 35, you might not know what you really like, yet... Might simply go for it for some time, and then if you decide to go back to a “builder” position, you will know _why_.
EDIT: I realize this is directed more towards IC->management, and less IC->product manager. I'm still leaving it, as it feels like it will have value to OP.
If you stay in tech, you will be forever slinging code and at the whim of the business. You will forever be on the tech treadmill, learning new frameworks, languages, and programming languages. You will have an artificial compensation ceiling.
If you move into management, those problems turn into different problems, but with more upside. You develop your soft skills. You network. You learn to manage, shielding your team from bullshit above while helping your ICs develop themselves. If you're a good manager, they will follow you for the rest of your career to where ever you go. This is an asset not to be understated. No 10x developer can ever compete with a manager bringing a solid team with them.
Your potential is then limited less by what you know, and more who and what opportunities you're aware of. Your skills will be transferable to other industries, even the public sector. Again, I can't stress this enough. Could you take a year off as a developer or other technologist and have an easy time coming back into the market? From my research, the answer is no.
With time, you won't just be a product owner/manager; if done properly, you will be able to demonstrate that you can solve business problems while having a solid foundation of the technical underpinnings required to solve those problems. And everyone is looking for competent business problem solvers.
If you stay in tech, you will be forever slinging code and at the whim of the business. You will forever be on the tech treadmill, learning new frameworks, languages, and programming languages. You will have an artificial compensation ceiling.
If you move into management, those problems turn into different problems, but with more upside. You develop your soft skills. You network. You learn to manage, shielding your team from bullshit above while helping your ICs develop themselves. If you're a good manager, they will follow you for the rest of your career to where ever you go. This is an asset not to be understated. No 10x developer can ever compete with a manager bringing a solid team with them.
Your potential is then limited less by what you know, and more who and what opportunities you're aware of. Your skills will be transferable to other industries, even the public sector. Again, I can't stress this enough. Could you take a year off as a developer or other technologist and have an easy time coming back into the market? From my research, the answer is no.
With time, you won't just be a product owner/manager; if done properly, you will be able to demonstrate that you can solve business problems while having a solid foundation of the technical underpinnings required to solve those problems. And everyone is looking for competent business problem solvers.
Sir... you are definitely a “people person”... but not every one fits that model.
Cheers!
Cheers!
[deleted]
35 isn't old in the slightest. In fact, it's a very ripe age to get started as a Product Manager. Even if you were 90, there'd be nothing stopping you (other than your own limiting beliefs and maybe other people's perceptions of you) from being successful in the role. It's not like PMs do manual labor :)
Personally, as a developer-turned-PM-turned-Product Lead, I can ascertain that a lot of the advice on this thread is largely sound. I will also add that when you first start out as a PM, you will make a lot of mistakes, especially if you come from an engineering background (like me).
By the way, I'll be teaching a 10-week course on product management with Stanford Continuing Studies starting next month (April 2018).
https://continuingstudies.stanford.edu/courses/professional-...
It's fully online and much less expensive than a certification program. The goal is to teach you the ins and outs of product management and really prepare people for the role. Not kidding, I've spent hundreds of hours and a lifetime of learning into creating this course....it's the best course on product management out there, and the one I wish I had available to me when I graduated 15 years ago.
Here's a preliminary Syllabus: https://continuingstudies.stanford.edu/courses/professional-...
Classes start the week of April 2nd, registration opens March 5th, and the class is limited to 45 students. Even if I wasn't posting this, I am told there's a high likelihood it'll fill.
Personally, as a developer-turned-PM-turned-Product Lead, I can ascertain that a lot of the advice on this thread is largely sound. I will also add that when you first start out as a PM, you will make a lot of mistakes, especially if you come from an engineering background (like me).
By the way, I'll be teaching a 10-week course on product management with Stanford Continuing Studies starting next month (April 2018).
https://continuingstudies.stanford.edu/courses/professional-...
It's fully online and much less expensive than a certification program. The goal is to teach you the ins and outs of product management and really prepare people for the role. Not kidding, I've spent hundreds of hours and a lifetime of learning into creating this course....it's the best course on product management out there, and the one I wish I had available to me when I graduated 15 years ago.
Here's a preliminary Syllabus: https://continuingstudies.stanford.edu/courses/professional-...
Classes start the week of April 2nd, registration opens March 5th, and the class is limited to 45 students. Even if I wasn't posting this, I am told there's a high likelihood it'll fill.
And in case you're curious about my story:
I started my career as an engineer, but from the beginning, I was always curious about the 'why' and driven to build products that solve real-world problems.
I started a company, but it failed, primarily because we never reached product-market fit. That was a hard lesson to learn. I then decided that I wanted to pursue a career in product management, but with no prior experience in the field, found it surprisingly hard to break into this elusive role. After more than 100 interviews over the course of 2 years and almost at the brink of giving up, I was able to break into the field. That was my big break and I haven't looked back since. I have held executive level positions in Product management, led the conception, execution, go-to-market and growth of products like Treat by Shutterfly (previously called Tiny Prints Greetings), Bills.com, Debt Navigator, Freedom Debt Relief, and FreedomPlus. I am a contributor to Mind The Product, have spoken at conferences like Product Camp Silicon Valley and am an advisor to a few companies.
I started my career as an engineer, but from the beginning, I was always curious about the 'why' and driven to build products that solve real-world problems.
I started a company, but it failed, primarily because we never reached product-market fit. That was a hard lesson to learn. I then decided that I wanted to pursue a career in product management, but with no prior experience in the field, found it surprisingly hard to break into this elusive role. After more than 100 interviews over the course of 2 years and almost at the brink of giving up, I was able to break into the field. That was my big break and I haven't looked back since. I have held executive level positions in Product management, led the conception, execution, go-to-market and growth of products like Treat by Shutterfly (previously called Tiny Prints Greetings), Bills.com, Debt Navigator, Freedom Debt Relief, and FreedomPlus. I am a contributor to Mind The Product, have spoken at conferences like Product Camp Silicon Valley and am an advisor to a few companies.
Why, specifically, do you want to move into Product Management?
To answer one of your questions: Age doesn't matter.
To answer one of your questions: Age doesn't matter.
I think it's pretty obvious. After you've been coding for almost 2 decades across multiple industries, coding becomes predictable and tedious. By that point, you've become an expert in many sub-fields within computer science; you probably even started to forget some of the old technologies/methodologies that you used to be an expert at.
You come to understand that software development methodologies are just fleeting trends. Unlike with many other fields, the returns that you earn from investing in yourself as a software developer/engineer don't compound; they start to depreciate as soon as you stop trying to keep up with the trends.
The subskills that actually compound in value are things like understanding project lifecycles, building teams/culture, understanding good coding standards, CI, deployment, testing, quality assurance, etc.. These 'management' skills never go out of fashion.
You come to understand that software development methodologies are just fleeting trends. Unlike with many other fields, the returns that you earn from investing in yourself as a software developer/engineer don't compound; they start to depreciate as soon as you stop trying to keep up with the trends.
The subskills that actually compound in value are things like understanding project lifecycles, building teams/culture, understanding good coding standards, CI, deployment, testing, quality assurance, etc.. These 'management' skills never go out of fashion.
> I think it's pretty obvious. After you've been coding for almost 2 decades across multiple industries, coding becomes predictable and tedious. By that point, you've become an expert in many sub-fields within computer science; you probably even started to forget some of the old technologies/methodologies that you used to be an expert at.
Are you at this stage now, or theory crafting?
I've been coding for 2 decades and I don't find it predictable or tedious.
Life is an event stream of lessons. Things you learn from previous events don't automatically become useless just because there's a new tech trend in town.
For example, when I was writing PHP code in 2000, I still apply the lessons I learned then to code I write today in non-PHP languages. Those lessons I've learned are what makes me a better programmer today than I was 20 years ago.
Are you at this stage now, or theory crafting?
I've been coding for 2 decades and I don't find it predictable or tedious.
Life is an event stream of lessons. Things you learn from previous events don't automatically become useless just because there's a new tech trend in town.
For example, when I was writing PHP code in 2000, I still apply the lessons I learned then to code I write today in non-PHP languages. Those lessons I've learned are what makes me a better programmer today than I was 20 years ago.
I venture to suggest that the fact that after 20 years you use the word “coding” to refer to the totality of what a human can create with digital technology and computer code reveals that you sadly have glimpsed but a tiny fraction of the wondrous intellectual vistas that were out there for you.
> After you've been coding for almost 2 decades across multiple industries, coding becomes predictable and tedious.
Move out of your comfort zone and take on some projects outside of your established expertise.
> Unlike many other fields, the returns that you make from investing in yourself as a software developer/engineer don't compound; they start to depreciate as soon as you stop trying to keep up.
This is only true if you invest in frameworks/libraries/languages/etc. If you invest in understanding problems faced within industries and how to solve them with software, that's not something that depreciates.
Just so that doesn't sound like something abstract, take for example an e-commerce marketplace. Knowing that you need to create two objects, one for the order and another as an invoice for each seller within that order, isn't knowledge that will depreciate with time.
On top of that, there is general knowledge of algorithms and a thousand other things that are sufficiently generalized that they can be applied at any time.
Virtually every project that I take on is in a new space and I learn constantly, keeping things interesting. For reference, since we're talking about age, I'm 37.
Move out of your comfort zone and take on some projects outside of your established expertise.
> Unlike many other fields, the returns that you make from investing in yourself as a software developer/engineer don't compound; they start to depreciate as soon as you stop trying to keep up.
This is only true if you invest in frameworks/libraries/languages/etc. If you invest in understanding problems faced within industries and how to solve them with software, that's not something that depreciates.
Just so that doesn't sound like something abstract, take for example an e-commerce marketplace. Knowing that you need to create two objects, one for the order and another as an invoice for each seller within that order, isn't knowledge that will depreciate with time.
On top of that, there is general knowledge of algorithms and a thousand other things that are sufficiently generalized that they can be applied at any time.
Virtually every project that I take on is in a new space and I learn constantly, keeping things interesting. For reference, since we're talking about age, I'm 37.
You are correct in that there are higher level lessons to be learned and those are very important.
However, at the end of the day where the rubber meets the road you can't ignore frameworks/libraries/languages. You have to learn what the job/market demands. This gets tiring because not only do these tend to be the same thing rehashed over and over again by some new young developer who doesn't have the experience, but they also ignore a lot of the lessons you have learned throughout your career.
Constantly learning can keep things interesting. After several years of re-learning front end frameworks or even back end frameworks with the same result gets tedious and boring.
However, at the end of the day where the rubber meets the road you can't ignore frameworks/libraries/languages. You have to learn what the job/market demands. This gets tiring because not only do these tend to be the same thing rehashed over and over again by some new young developer who doesn't have the experience, but they also ignore a lot of the lessons you have learned throughout your career.
Constantly learning can keep things interesting. After several years of re-learning front end frameworks or even back end frameworks with the same result gets tedious and boring.
Really well put and there are about a dozen lessons that could be extrapolated from this comment in terms of management, career planning, and software development practices and industry maturity.
You’re confusing learning software engineering and computer science with learning programming frameworks.
>>After you've been coding for almost 2 decades across multiple industries, coding becomes predictable and tedious.
Well yeah, if you are still “coding” after two decades you will probably find it tedious.
You can move into “engineering” and “architecting” however, which involve entirely different challenges, both in type and scale.
Well yeah, if you are still “coding” after two decades you will probably find it tedious.
You can move into “engineering” and “architecting” however, which involve entirely different challenges, both in type and scale.
I used to work with a guy who was really proud of that...
I agree with the intended meaning of this comment. Although none of the terms "engineering", "architecting", "coding" have been defined in this thread, someone who refers to their two decades as "coding" probably does not have a good vision of the intellectual landscape that is out there.
Great question.
I do like coding, and will definitely continue working on my side projects. Although programming pays quite well, I'm not sure of the long term payoffs of continuing as a programmer (unless you are one of the Linus Torvalds, or in a similar league - which I am no where close to).
Longer term: I do want to get to a point in my career where I would like to influence product strategy (focus on the whys) a s a VP of Product Management vs. VP of Engineering.
If you have a complete different outlook to this, please let me know.
I do like coding, and will definitely continue working on my side projects. Although programming pays quite well, I'm not sure of the long term payoffs of continuing as a programmer (unless you are one of the Linus Torvalds, or in a similar league - which I am no where close to).
Longer term: I do want to get to a point in my career where I would like to influence product strategy (focus on the whys) a s a VP of Product Management vs. VP of Engineering.
If you have a complete different outlook to this, please let me know.
I strongly think that the certifications are not critical. I moved in PM around the same age since Google offers rotation program for Engineers to try out PM. I would be happy to chat with you along with providing some insights into PM interview training. DM me.
Thank you for the offer. I'm not at Google, but one of the enterprise software companies in SF. I will definitely DM you. Would love to get some advice/insights into the process.
Not sure how to DM you. No contact info in your profile too. TIA
I’m 37 and have recently started a role as head of product.
Although my background is in design, I’ve spent the last 15 years variously doing design, ux and web development. I got into it as the previous person left suddenly and I sort of took over and was doing it a while before it was made official.
Product management is a mix of ux, development and business, so it helps to have an interest and understanding of these things.
For me the biggest change has been going from solving problems to finding and articulating the problems for the team to solve. I’ve had to hold myself back from getting stuck in to finding answers so that I allow the team autonomy and also don’t accidentally short circuit the process.
The LEAN Startup is worth reading, as is Designing Products People Love by Scott Hurff, and The LEAN Product Playbook. Strategise by Roman Pilcher has some good stuff on business strategy and innovation theory. I signed up to a free trial with Safari Books Online and read everything I could in the time. Lynda.com/LinkedIn Learning has some good videos too.
Although my background is in design, I’ve spent the last 15 years variously doing design, ux and web development. I got into it as the previous person left suddenly and I sort of took over and was doing it a while before it was made official.
Product management is a mix of ux, development and business, so it helps to have an interest and understanding of these things.
For me the biggest change has been going from solving problems to finding and articulating the problems for the team to solve. I’ve had to hold myself back from getting stuck in to finding answers so that I allow the team autonomy and also don’t accidentally short circuit the process.
The LEAN Startup is worth reading, as is Designing Products People Love by Scott Hurff, and The LEAN Product Playbook. Strategise by Roman Pilcher has some good stuff on business strategy and innovation theory. I signed up to a free trial with Safari Books Online and read everything I could in the time. Lynda.com/LinkedIn Learning has some good videos too.
Following. I’m still figuring out if product management is the only path for a sw engineer. I’m 37.
You’re right to think that 35 is pretty young. But it’s not too young to get into Product Management. Or any other career change for that matter.
There are many different types of PMs. Some companies want a more technical PM. Maybe a company selling a technical product to a technical audience would find your engineering experience extremely valuable.
My default career advice to everyone is to figure out where your experience is rare. If other PMs have 5-10 years of experience as a PM, you’re the rare gal or guy with years of actual coding and experience. That group will have a ton of depth to help on your PM gaps. But you’ll be the only one who can do what you do.
There are many different types of PMs. Some companies want a more technical PM. Maybe a company selling a technical product to a technical audience would find your engineering experience extremely valuable.
My default career advice to everyone is to figure out where your experience is rare. If other PMs have 5-10 years of experience as a PM, you’re the rare gal or guy with years of actual coding and experience. That group will have a ton of depth to help on your PM gaps. But you’ll be the only one who can do what you do.
If I might ask, why product management? You mention that you have no experience in it.
People change over their career, different things become important to them, and other things become less important. Their interests shift as well. This can lead to them changing into different roles over time.
I would not suggest to someone to change roles if they were doing so because they felt "too old" in their current role, especially if they still enjoyed it and were good at it. I have seen my share of engineers do that only to put themselves into a horrible bind as they got "lost" trying a bunch of different roles for all of the wrong reasons.
People change over their career, different things become important to them, and other things become less important. Their interests shift as well. This can lead to them changing into different roles over time.
I would not suggest to someone to change roles if they were doing so because they felt "too old" in their current role, especially if they still enjoyed it and were good at it. I have seen my share of engineers do that only to put themselves into a horrible bind as they got "lost" trying a bunch of different roles for all of the wrong reasons.
Related question: do product management skills transfer across domains? A Java engineer is equally employable at a healthcare tech company as a fintech or security company, but they're very different product domains.
A. Age definitely doesn't matter.
B. In Google, for example, many people take a path similar to what you describe, gradually moving to product management from an engineering background. It usually requires demonstrating leadership, and doing some 'rotations' in which you perform a PM role on smaller projects before taking on a full product. Perhaps your best shot is asking your current management to take on product management and ownership duties in a project you are familiar with, maybe even being mentored by an experienced PM.
(Source: was a PM at Google)
B. In Google, for example, many people take a path similar to what you describe, gradually moving to product management from an engineering background. It usually requires demonstrating leadership, and doing some 'rotations' in which you perform a PM role on smaller projects before taking on a full product. Perhaps your best shot is asking your current management to take on product management and ownership duties in a project you are familiar with, maybe even being mentored by an experienced PM.
(Source: was a PM at Google)
PM-turned-software-engineer here. I was in various PM roles for almost 10 years.
35 is fine. In my experience, college graduates don't often land PM roles due to the diverse set of skills required to perform the job well. They move into them after proving capable in other roles. Thus, PMs skew older where I've worked -- 23-year-old PMs are less common than 23-year-old engineers. While I think this is probably try across the board, this is probably also changing, though.
Try to switch at your current company if you can. It's easier and people at your company already know you're a valuable employee. They know you're learning but are probably worth it in the end. Try to pick up product management related tasks from a PM you work with or ask your manager for help in getting some of that experience. If your manager isn't helpful, then pick up tasks from a trusted PM colleague that you can highlight on your resume when you apply for PM jobs at another company.
Yes, lots of books to read and schools don't hurt. But product management is most often an aspirational function. Product management practically never gets executed the way it's written about and learning how to change or cope with these deviations is key (e.g. sales running the roadmap). I could write a book about this, but suffice it to say that on-the-job experience is way more valuable. So try to get some as soon as you can.
35 is fine. In my experience, college graduates don't often land PM roles due to the diverse set of skills required to perform the job well. They move into them after proving capable in other roles. Thus, PMs skew older where I've worked -- 23-year-old PMs are less common than 23-year-old engineers. While I think this is probably try across the board, this is probably also changing, though.
Try to switch at your current company if you can. It's easier and people at your company already know you're a valuable employee. They know you're learning but are probably worth it in the end. Try to pick up product management related tasks from a PM you work with or ask your manager for help in getting some of that experience. If your manager isn't helpful, then pick up tasks from a trusted PM colleague that you can highlight on your resume when you apply for PM jobs at another company.
Yes, lots of books to read and schools don't hurt. But product management is most often an aspirational function. Product management practically never gets executed the way it's written about and learning how to change or cope with these deviations is key (e.g. sales running the roadmap). I could write a book about this, but suffice it to say that on-the-job experience is way more valuable. So try to get some as soon as you can.
It's certainly possible. I PM at Gigster and have seen some BE Engineers switch to being PM's on the network--some successfully and some unsuccessfully.
Joining our network and seeing how it's done on a project by project basis is not a bad start :-).
My view on PM'ing is very similar to what makes a good 'salesperson' or 'consultant'. There are certainly similar traits among large swathes of successful people, but there's no 'rule'. PM'ing a software framework is very different from PM'ing a social network, which should be obvious.
From a backend dev perspective, you should have some perspectives in looking at an overall system and fully understanding what will be required. You'll have empathy for the work when requirements change. That will help.
Of course building the skills that MBA's,'brought up' PM's, and people who started in sales / marketing will take a while to brush up on. Product School can help.
However, the best advice I'd say about PM'ing is starting to build things and get feedback from users. If you don't enjoy or cant: 1) Decide a problem to solve, along with a goal 2) Figure out a path to solve that problem and 3) Iterate and learn based on feedback
PM'ing probably will not be a fulfilling career choice.
Joining our network and seeing how it's done on a project by project basis is not a bad start :-).
My view on PM'ing is very similar to what makes a good 'salesperson' or 'consultant'. There are certainly similar traits among large swathes of successful people, but there's no 'rule'. PM'ing a software framework is very different from PM'ing a social network, which should be obvious.
From a backend dev perspective, you should have some perspectives in looking at an overall system and fully understanding what will be required. You'll have empathy for the work when requirements change. That will help.
Of course building the skills that MBA's,'brought up' PM's, and people who started in sales / marketing will take a while to brush up on. Product School can help.
However, the best advice I'd say about PM'ing is starting to build things and get feedback from users. If you don't enjoy or cant: 1) Decide a problem to solve, along with a goal 2) Figure out a path to solve that problem and 3) Iterate and learn based on feedback
PM'ing probably will not be a fulfilling career choice.
There are lots of PM jobs where an engineering background would be really helpful.
Shameless plug: we have a bunch posted at datadog.com/careers. Take a gander.
Shameless plug: we have a bunch posted at datadog.com/careers. Take a gander.
I have a random related question-- will product management pay as well as engineering? Or is the OP implicitly asking for a loss in pay?
The bands overlap a lot. While the top end for in a product role is likely to be higher, that doesn't mean a guaranteed income change when making the leap. A senior dev will be higher than a junior PM. A very senior (principal level) dev at the top of the compensation band will likely be higher than a first-time PM, even is the role is "Senior". However other commenters are correct: anything in management heads to bigger responsibility and compensation, so the top-end is effective uncapped. It's very different work than writing code though, and it's not for everyone.
Engineering is in higher aggregate demand (there are more open eng roles as the ratio of Engineers:PMs is high, and the minimum qualification bar to be an engineer is higher ie you need to know how to code at a bare minimum. You also generally speaking can always add more engineers to a mature tech product as they can fix bugs, tech debt, etc and help the business overall). As a result, my personal anecdotal observation is that Engineering pays the same or somewhat higher at the more junior / midlevel range where the base of the org chart pyramid is "wider."
However, Product Management is a straighter shot to general management, and becoming a GM/CEO is a path towards some of the highest total comp.
Mileage will vary by company (and probably region).
In terms of compensation, both are excellent.
However, Product Management is a straighter shot to general management, and becoming a GM/CEO is a path towards some of the highest total comp.
Mileage will vary by company (and probably region).
In terms of compensation, both are excellent.
This ++.
I've been working with engineers all my life, and a lot more senior engineers. I've seen engineering careers plateau after a certain point - plateau at either architect level positions or worse, as a senior software engineer. Longer term, a PM level position opens lot many doors (and especially, if you have an software engineering background).
Definitely can be true, although I think that there are a lot of potential paths.
My advice would be to determine what is driving you to want to shift from Engineer => PM. If it's purely money, there are alternatives that don't require leaving coding (job hopping wisely, moving into certain types of management tracks, consulting on the side, switching into industries that pay SWEs ludicrous salaries such as quant finance if you can). Similarly if you're looking for more influence/reputation – all of that can be had as an engineer if you're somewhat thoughtful about your path. However – if you're looking to transition out of coding because you're more interested in the business / sales / working with people (which was my story) then it's a great switch.
Good luck!
My advice would be to determine what is driving you to want to shift from Engineer => PM. If it's purely money, there are alternatives that don't require leaving coding (job hopping wisely, moving into certain types of management tracks, consulting on the side, switching into industries that pay SWEs ludicrous salaries such as quant finance if you can). Similarly if you're looking for more influence/reputation – all of that can be had as an engineer if you're somewhat thoughtful about your path. However – if you're looking to transition out of coding because you're more interested in the business / sales / working with people (which was my story) then it's a great switch.
Good luck!
Do you encounter a lot of frustrated/unhappy older engineers?
It's worth analyzing why they plateaued (or why do you think they have).
If they gave up on learning, well that's a sad, but good explanation.
If they found themselves satisfied with what they were doing, that's not necessarily right or wrong.
Do you believe they were in an environment where they are well supported and well managed?
Moving to product is worth thinking about; but it's not a silver bullet either.
While you can pick up experience in tasks not typically done in engineering, the things that can limit a person's career is partially independent of their work experience (in terms of the task they are actually supposed to do).
It's worth analyzing why they plateaued (or why do you think they have).
If they gave up on learning, well that's a sad, but good explanation.
If they found themselves satisfied with what they were doing, that's not necessarily right or wrong.
Do you believe they were in an environment where they are well supported and well managed?
Moving to product is worth thinking about; but it's not a silver bullet either.
While you can pick up experience in tasks not typically done in engineering, the things that can limit a person's career is partially independent of their work experience (in terms of the task they are actually supposed to do).
It's considered more senior and pays more.
In my experience, associate PM positions require applicants to be undergrad CS students and un-modified & senior PM title positions require recognizable PM experience.
The roles are very competitive, and unless you’ve worked with someone at the company before as a PM, I would say you’d have to be pretty special to be considered. I think a successful PM’s strongest asset is the trust of their team and company, so outsiders aren’t the safest choice for a new hire, unlike roles with more demonstrable skills like engineering.
Edit: I also went to Product School and think it’s a great way to show current employers your dedication to making a transition. For joining a new company though, it doesn’t come close to comparing to what HackReactor does for a developer applicant. As far as educational content, I think the only value I got was talking to current PMs about how the realities of their jobs differ from what you read in books like cracking the pm interview.
The roles are very competitive, and unless you’ve worked with someone at the company before as a PM, I would say you’d have to be pretty special to be considered. I think a successful PM’s strongest asset is the trust of their team and company, so outsiders aren’t the safest choice for a new hire, unlike roles with more demonstrable skills like engineering.
Edit: I also went to Product School and think it’s a great way to show current employers your dedication to making a transition. For joining a new company though, it doesn’t come close to comparing to what HackReactor does for a developer applicant. As far as educational content, I think the only value I got was talking to current PMs about how the realities of their jobs differ from what you read in books like cracking the pm interview.
What was your experience at Product School like? I do plan to try and transition in my current company.
Getting into the course was a strangely sales-y experience. I was working in sales at the time and recognized a lot of similar techniques used by their recruiter/admissions person. I eventually decided to join after considering they were likely to build the best product manager network. There were about a dozen of us twenty-somethings in a twice-weekly night class. Our first instructor was replaced after student complaints that he was phoning it in -- just literally reading slides to us with content seemingly summarized from common wisdom you find on hackernews about lean startups. Our second instructor was much more engaged and enthusiastic. There were assignments that scratched the surface of a few topics within product management like design, engineering, prioritization, and presentations. The end of the course provided some brief interview tips. Alumni have access to a private slack group which, like any networking group, is filled with people looking for jobs and a dearth of recruiters looking for those people.
I might go as far as to say that there really is no such thing as an entry-level PM. Most people who become PMs seem to do so accidentally or because they started as an APM at some company with the resources and retention afford them.
However, in the end, if you do your assignments, you end up with a LinkedIn certification to add to your profile and the confidence that you are probably capable of being a good product manager. Carlos is really an awesome dude (the CEO), but the website's title "Get a job as a Product Manager" is unrelated to the course offered.
I might go as far as to say that there really is no such thing as an entry-level PM. Most people who become PMs seem to do so accidentally or because they started as an APM at some company with the resources and retention afford them.
However, in the end, if you do your assignments, you end up with a LinkedIn certification to add to your profile and the confidence that you are probably capable of being a good product manager. Carlos is really an awesome dude (the CEO), but the website's title "Get a job as a Product Manager" is unrelated to the course offered.
This is a great thread! I am in a similar position currently -
I am working as a software engineer in a domain that I like, but I am really into product design, strategy in general. This lead me down an exploratory path and I got lucky with an offer from a tiny startup to join them as the first PM. The experience seems to be promising and I think I'll learn a lot.
However, I have some concerns such as the loss of pay (no more RSUs), the nasty commute (1 hour each way minimum as opposed to 20 minutes currently), the work life harmony going for a toss. Anyone out here (who made a switch to the PM space in smaller companies) willing to share their experiences ? Would love to know!
However, I have some concerns such as the loss of pay (no more RSUs), the nasty commute (1 hour each way minimum as opposed to 20 minutes currently), the work life harmony going for a toss. Anyone out here (who made a switch to the PM space in smaller companies) willing to share their experiences ? Would love to know!
Before you go through all the trouble of getting certs. I advise that you ask for help from your PM. Maybe you can even take charge of a project.
One thing you quickly discover is that the pressure is pretty intense. You get squeezed from management above and the people you manage below. Yet, you have little power to push back.
Certs will teach you the mechanics of project management but managing the human to human relationships is way harder and you'll get little help there from certs. I've known PM's that are experts at the relationship part and are happy doing what they do. I've known others that try to push the mechanics and end up making everyone and themselves miserable.
Good luck.
One thing you quickly discover is that the pressure is pretty intense. You get squeezed from management above and the people you manage below. Yet, you have little power to push back.
Certs will teach you the mechanics of project management but managing the human to human relationships is way harder and you'll get little help there from certs. I've known PM's that are experts at the relationship part and are happy doing what they do. I've known others that try to push the mechanics and end up making everyone and themselves miserable.
Good luck.
I'm currently going through the transition. One I've learned one fact - People, People, People. It's all about people skills. People with emotions, people with attitude, people with ego and some great people as well. And you'd learn, you have to rely on things that aren't in your control. Age doesn't matter. What matters is how mature you are. Depends on whether you can smile and move ahead even when you know its not what you think is right.
when i hired product managers, the most critical point I looked at was “building something that users love”. If you can prove this, you are ahead of average (of course you also need some standard stuff, including communication skills, but those are more common).
the above is related to intelligence (understanding activity numbers) and emotional intelligence (understanding the user).
thus, it would be good if you can polish up your skills/presentation of yourself in that area
the above is related to intelligence (understanding activity numbers) and emotional intelligence (understanding the user).
thus, it would be good if you can polish up your skills/presentation of yourself in that area
Eng is a common transfer to PM and many of your skills will carry over. I (personally) think age will hurt you but rather help because you have experience and have seen a bunch of failures which you can learn to avoid (this goes well during interviews).
Suggest looking at the rpm program at Facebook or APM (I think this is the name at google) which is for people interested in learning product management but without PM experience.
Suggest looking at the rpm program at Facebook or APM (I think this is the name at google) which is for people interested in learning product management but without PM experience.
APM role at Google (started by Marrisa Mayer?) is only for fresh MS CS grads. Anyone knows more details please let me know if I'm mistaken.
Product management. Own it.
The best product guys treat the product like their 2 year old daughter. Push code? They want to know why. They saw a dip in registrations Wednesday so they spend hours figuring out why. They are ruthless testers, every bug they label and harass anyone that will listen. They love ideas and quickly turn them into tests.
The best product guys treat the product like their 2 year old daughter. Push code? They want to know why. They saw a dip in registrations Wednesday so they spend hours figuring out why. They are ruthless testers, every bug they label and harass anyone that will listen. They love ideas and quickly turn them into tests.
Thank you for asking this. I’m 38 and trying to make a move to product management. I’ve been a front-end developer for years but I’m just not good enough at what’s become front-end to keep up and maintain any kind of work-life balance. It’s not fun anymore.
Why do you think being a PM will be any easier?
I have no trouble keeping up with design and technical trends and understanding deep technical details. I'm just not enough of a programmer to keep up with the pace of being hands-on with the code. I've actually been moving in this direction for a few years.
About three years ago, I got lucky enough to be put into a management position. In order to do the job, I had to put hands-on development aside more and more in order to make room for the job of actually running a small team. We were sorely lacking product management—doing pretty much everything at the whims of stakeholders—so I started bringing it into what I do. I definitely enjoy it more than today's front-end development, although I still love being involved in the process.
My dilemma is how I switch to it full time. Even though I'm trying to do a fair amount of it, it seems like it'll be hard to get my foot in the door anywhere without that title on my resume. We've got a whole department full of people at my company with "product" in their titles, yet they don't do any actual product management, making it hard to make the switch internally.
About three years ago, I got lucky enough to be put into a management position. In order to do the job, I had to put hands-on development aside more and more in order to make room for the job of actually running a small team. We were sorely lacking product management—doing pretty much everything at the whims of stakeholders—so I started bringing it into what I do. I definitely enjoy it more than today's front-end development, although I still love being involved in the process.
My dilemma is how I switch to it full time. Even though I'm trying to do a fair amount of it, it seems like it'll be hard to get my foot in the door anywhere without that title on my resume. We've got a whole department full of people at my company with "product" in their titles, yet they don't do any actual product management, making it hard to make the switch internally.
Why are you transitioning? If you feel like you want to challenge yourself and grow within this new position, fine.
However, if you drank the 'too-old-to-code-coolaid-sv-bs' well I'm sorry to hear that.
However, if you drank the 'too-old-to-code-coolaid-sv-bs' well I'm sorry to hear that.
I'm older than 35 and currently executing a plan to shift to PM. I have no worries that I'm too old.
Do you mind sharing your strategy to shift to the PM role? DM me if you'd like. I would really appreciate it.
I took on a program management role for a team of product managers to learn the ropes while still in a safe-to-fail environment.
How much can PM make I wonder?
Certication matters more than in your previous role.
Willing to give up on coding?
Do you love presenting stuff to big audiences?
Are you good at selling?
Then a PM role might be right for you.
If you love coding/technology or don't have good presenting/selling skills then stick to engineering... my $0.2.
Then a PM role might be right for you.
If you love coding/technology or don't have good presenting/selling skills then stick to engineering... my $0.2.
what if you like both? Asking for myself since I'm transitioning to a product ownership role. To be fair, i've only been coding professionally for 3 years (nonprofessionally for ~20), but in my current role I rescued two products, have done technical demos and customer engagement.
If you like both then find a technical product management role. Products with heavy ML or data science components can benefit greatly from PMs that can code, mock, and do ad hoc analysis.
That's kind of what I'll be doing! Making mock demos for customers, owning a cloud -> on prem product vertical, organizing qa/qc, and there is a data science component!!
Thanks that gives me a bit more confidence, since I don't have as much experience with personnel management outside of a few interns (who have been all wildly successful in their internships).
Thanks that gives me a bit more confidence, since I don't have as much experience with personnel management outside of a few interns (who have been all wildly successful in their internships).
I need some advice from all the wonderful people on Hacker News. I am a Backend engineer looking to move into a product management role. I have no experience in product management. In addition, I am 35. Does age matter? Are certifications such as the one from Product School worth it and help in the transition process? How do engineers typically transition to the role? I’d appreciate any advice from anyone. Thank you.