Ask HN: Move to product management at 35?
286 points| neofrommatrix | 8 years ago | reply
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.
[+] [-] crazygringo|8 years ago|reply
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...
[+] [-] mdgrech23|8 years ago|reply
I transitioned from dev to architect. This statement is so true, even more so for PMs.
[+] [-] cheath|8 years ago|reply
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.
[+] [-] bredren|8 years ago|reply
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.
[+] [-] muxator|8 years ago|reply
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.
[+] [-] neofrommatrix|8 years ago|reply
[+] [-] rahimnathwani|8 years ago|reply
- Decode & Conquer
- Inspired (Marty Cagan)
- Radical Focus (about OKRs)
[+] [-] unknown|8 years ago|reply
[deleted]
[+] [-] ryan-allen|8 years ago|reply
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!
[+] [-] evolve2k|8 years ago|reply
[+] [-] maxxxxx|8 years ago|reply
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.
[+] [-] shaklee3|8 years ago|reply
[+] [-] jtwaleson|8 years ago|reply
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".
[+] [-] Techonomicon|8 years ago|reply
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).
[+] [-] muzani|8 years ago|reply
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.
[+] [-] neofrommatrix|8 years ago|reply
"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?
[+] [-] itsevrgrn|8 years ago|reply
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.
[+] [-] tptacek|8 years ago|reply
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.
[+] [-] motohagiography|8 years ago|reply
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.
[+] [-] tillreiter|8 years ago|reply
[+] [-] austincheney|8 years ago|reply
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.
[+] [-] iamphilrae|8 years ago|reply
[+] [-] tigershark|8 years ago|reply
Why? As an old developer you don’t need to constantly learn new things?
[+] [-] jonstewart|8 years ago|reply
[+] [-] robterrell|8 years ago|reply
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.
[+] [-] ViorelMocanu|8 years ago|reply
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!
[+] [-] BlackJack|8 years ago|reply
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.
[+] [-] canttestthis|8 years ago|reply
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?
[+] [-] neofrommatrix|8 years ago|reply
[+] [-] libovness|8 years ago|reply
Avoid certifications at all cost
[+] [-] neofrommatrix|8 years ago|reply
[+] [-] h1boo|8 years ago|reply
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.
[+] [-] wildekek|8 years ago|reply
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.
[+] [-] jtwaleson|8 years ago|reply
[+] [-] reassembled|8 years ago|reply
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.
[+] [-] pretzel|8 years ago|reply
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!
[+] [-] muzani|8 years ago|reply
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.
[+] [-] bsvalley|8 years ago|reply
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!
[+] [-] realo|8 years ago|reply
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_.
[+] [-] toomuchtodo|8 years ago|reply
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.
[+] [-] kunalspunjabi|8 years ago|reply
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.
[+] [-] kunalspunjabi|8 years ago|reply
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.