Ask HN: Product Managers, how did you get there and what's your background?
There aren't "junior product" positions.
What skills must be demonstrable?
119 comments
PM @ McKinsey & Company (New Ventures group)
-Background in software engineering and human-centered design. The best product managers I've been around have a mix of technical, business, and design talent, with the strong PMs excelling in at least two of the categories. -Understand the difference between good and bad products. Actively examine products you use on a daily basis, both physical and digital. E.g. why is my shower setting designed this way? why did I push on a door that needed to be pulled? To flex this muscle, read "The Design of Everyday Things" by Don Norman and check out Tony Fadell's tech talk on product design. -Be a people person. You need to be able to communicate product ideas clearly to everyone from marketing to HR to engineering (obviously). -Be entrepreneurial. You're the "CEO" of the product, so you need to know the product/service inside out. Everything from the software stack down to the marketing materials to the help center articles should have been on your radar at some point in the release cycle. -Protect the engineers. Don't let management demand too much and be vested in their success.
Ping me if you have any other questions :)
-Background in software engineering and human-centered design. The best product managers I've been around have a mix of technical, business, and design talent, with the strong PMs excelling in at least two of the categories. -Understand the difference between good and bad products. Actively examine products you use on a daily basis, both physical and digital. E.g. why is my shower setting designed this way? why did I push on a door that needed to be pulled? To flex this muscle, read "The Design of Everyday Things" by Don Norman and check out Tony Fadell's tech talk on product design. -Be a people person. You need to be able to communicate product ideas clearly to everyone from marketing to HR to engineering (obviously). -Be entrepreneurial. You're the "CEO" of the product, so you need to know the product/service inside out. Everything from the software stack down to the marketing materials to the help center articles should have been on your radar at some point in the release cycle. -Protect the engineers. Don't let management demand too much and be vested in their success.
Ping me if you have any other questions :)
What makes a good product is a great question for Product Managers to be obsessed about.
how do I ping you? :p PG did a great job as a PM with HN, but he "forgot" about some features :p
Actually, please find me on twitter @aswin8728. Didn't realize the volume of responses I'd be receiving, so I need a way to separate the two :)
> What skills must be demonstrable?
Have the balls to stand up to management. You are often under significant pressure to adjust timelines and somehow get "9 women to have a baby in a month."
The PM I have now is excellent and is happy to say things to management like:
"Assuming everything goes well, we estimate you will have your project on dd-mm-yy. Remember that's an ESTIMATE."
"I don't think it's a good idea to try and force our devs to work overtime/weekends. We're more likely to stress our workforce and possibly lose devs eventually if we do that."
"No I'm not changing my estimate."
"No really, I'm not changing my estimate."
You get the idea. Thing is, after a number of projects he actually has the respect of management because they know he will give them the real numbers no matter what the pressure.
Have the balls to stand up to management. You are often under significant pressure to adjust timelines and somehow get "9 women to have a baby in a month."
The PM I have now is excellent and is happy to say things to management like:
"Assuming everything goes well, we estimate you will have your project on dd-mm-yy. Remember that's an ESTIMATE."
"I don't think it's a good idea to try and force our devs to work overtime/weekends. We're more likely to stress our workforce and possibly lose devs eventually if we do that."
"No I'm not changing my estimate."
"No really, I'm not changing my estimate."
You get the idea. Thing is, after a number of projects he actually has the respect of management because they know he will give them the real numbers no matter what the pressure.
That's project management- not product management
Eh, that line is fuzzier than it looks from a distance.
Product managers are responsible for dealing with roadmaps and timelines. Managing expectations is necessarily part of that job.
Add in agile practices where the PM may also be a PO directly managing a backlog and the line gets fuzzier still.
It's part of what makes that job so challenging, as you have to wear so many hats. It also makes the job very difficult to define, and I think, makes the question itself a little tough, since a PM in one org might be a very different role from a PM in another.
Product managers are responsible for dealing with roadmaps and timelines. Managing expectations is necessarily part of that job.
Add in agile practices where the PM may also be a PO directly managing a backlog and the line gets fuzzier still.
It's part of what makes that job so challenging, as you have to wear so many hats. It also makes the job very difficult to define, and I think, makes the question itself a little tough, since a PM in one org might be a very different role from a PM in another.
all fortune 500 companies I worked on that had only PM doing both jobs it went like:
PM promises some project worked out with a designer that only knows the how to wireframe generic screens, both lack understanding of the product and tech. usually because the PM just moved from another place 3 months ago.
PM show up every day at standup and fail to understand the current priorities, push the new project, the enginners see how pointless but easier than real priorities it is. Then remember it is a fortune 500 company so the easier the better. Everyone works on the useless project, try to explain the product to the PM but he will have none of that, after all the wireframes are done! Agile is actually used as an excuse "don't worry, we will iterate later". The PM will now disappear until close to the deadline when you will get constant meeting invites to assess progress, which will never be the standup. Project goes live shoved into actual product and it is a complete failure but everyone mentions it on their accomplishments so management starts to see it as a success. Everyone involved gets a promotion. PM moves over to help troubled team. Some engineers stay and are tasked with maintenance. A year later execs see the numbers and blame the current team, labels them as a troubled team so they get a new PM (remember they had none because the other one left to help another team labeled troubled).
And that's the circle of life in a fortune 500.
PM promises some project worked out with a designer that only knows the how to wireframe generic screens, both lack understanding of the product and tech. usually because the PM just moved from another place 3 months ago.
PM show up every day at standup and fail to understand the current priorities, push the new project, the enginners see how pointless but easier than real priorities it is. Then remember it is a fortune 500 company so the easier the better. Everyone works on the useless project, try to explain the product to the PM but he will have none of that, after all the wireframes are done! Agile is actually used as an excuse "don't worry, we will iterate later". The PM will now disappear until close to the deadline when you will get constant meeting invites to assess progress, which will never be the standup. Project goes live shoved into actual product and it is a complete failure but everyone mentions it on their accomplishments so management starts to see it as a success. Everyone involved gets a promotion. PM moves over to help troubled team. Some engineers stay and are tasked with maintenance. A year later execs see the numbers and blame the current team, labels them as a troubled team so they get a new PM (remember they had none because the other one left to help another team labeled troubled).
And that's the circle of life in a fortune 500.
Well, on the bright side, all you aspiring PMs out there, take note: see how low the bar is??
Speaking as a PM/PO that, I hope, doesn't suck, if you simply take the time to:
1. Understand the market.
2. Understand the product.
3. Understand the user.
4. Actively engage with and converse with developers and negotiate requirements rather than acting as a lofty dictator, and listen when the engineers raise concerns.
5. Be engaged in the process so the product can truly evolve as market and technical requirements are uncovered.
6. Own failures.
7. Share successes.
I'm sure I've left lots off the list, but it's pretty basic stuff (which, I suppose, all starts from the same basic place: humility)...
Speaking as a PM/PO that, I hope, doesn't suck, if you simply take the time to:
1. Understand the market.
2. Understand the product.
3. Understand the user.
4. Actively engage with and converse with developers and negotiate requirements rather than acting as a lofty dictator, and listen when the engineers raise concerns.
5. Be engaged in the process so the product can truly evolve as market and technical requirements are uncovered.
6. Own failures.
7. Share successes.
I'm sure I've left lots off the list, but it's pretty basic stuff (which, I suppose, all starts from the same basic place: humility)...
Oops, sorry!
I'm a Sr. PM at Amazon. Typically PMs start out in a technical role, such as writing code, then get an MBA and switch into a PM role.
My path was a little different, as I am neither a developer nor someone with an MBA - I worked on some personal projects early on (startups, tech focused non-profits) where I demonstrated basic PM/getting the right things done skills, and I combined that with some early experience I had as a program manager at Microsoft and as an undergrad intern within PM groups at other companies.
In terms of how to start, the 3 ways I can think of are:
1) Work as an engineer for some time, try to pick up roles such as being the scrum master, managing sprints etc. (or whatever equivalent your team is doing), then get an MBA - many companies will hire you for PM right out of MBA school with no prior experience
2) The program manager role at Microsoft is one of the few places where you can start in a role that is essentially junior product (they hire undergrads right out of school). If you can find other companies that have roles like this, that's one way to get into the PM role. Another one is Expedia I think, an MS spin-off.
3) Another way would be to go work at a startup where you can add PM input and grow into the role. This is what I would pick if I were to start over again.
Generally speaking I think companies are open-minded when hiring for the PM role - you don't have to fit an exact formula. In my experience people look for evidence of the following in your background:
1) Being able to think big and be truly creative
2) Being able to ship products (preferably you've actually shipped something already)
3) Being comfortable working with data (though my 2c is that we're over-doing this)
4) Having good decision-making frameworks for why, what and when the org should be building things
5) Being able to dive into the weeds of any domain without hesitation.
My team at Amazon is hiring PMs by the way. If you're interested in talking, feel free to send me a note.
My path was a little different, as I am neither a developer nor someone with an MBA - I worked on some personal projects early on (startups, tech focused non-profits) where I demonstrated basic PM/getting the right things done skills, and I combined that with some early experience I had as a program manager at Microsoft and as an undergrad intern within PM groups at other companies.
In terms of how to start, the 3 ways I can think of are:
1) Work as an engineer for some time, try to pick up roles such as being the scrum master, managing sprints etc. (or whatever equivalent your team is doing), then get an MBA - many companies will hire you for PM right out of MBA school with no prior experience
2) The program manager role at Microsoft is one of the few places where you can start in a role that is essentially junior product (they hire undergrads right out of school). If you can find other companies that have roles like this, that's one way to get into the PM role. Another one is Expedia I think, an MS spin-off.
3) Another way would be to go work at a startup where you can add PM input and grow into the role. This is what I would pick if I were to start over again.
Generally speaking I think companies are open-minded when hiring for the PM role - you don't have to fit an exact formula. In my experience people look for evidence of the following in your background:
1) Being able to think big and be truly creative
2) Being able to ship products (preferably you've actually shipped something already)
3) Being comfortable working with data (though my 2c is that we're over-doing this)
4) Having good decision-making frameworks for why, what and when the org should be building things
5) Being able to dive into the weeds of any domain without hesitation.
My team at Amazon is hiring PMs by the way. If you're interested in talking, feel free to send me a note.
I might take you up on your offer to send a note. What's the best way to send you a message? I do not want to side-track or pollute this thread. Thx.
I think the key thing that stands out about what you've written above is dedication and patience.
Any recommendation to improve 4) ?
On a simple level, RICE scoring can help: https://blog.intercom.com/rice-simple-prioritization-for-pro...
PM @ Google.
TL;DR -- The ability, innate or learned, to reason about products is extremely helpful. Being good at working with others, conflict resolution and prioritization are critical. Best tip is to begin working on these skills and start framing yourself as product centric (on LinkedIn, within your company, etc.) and make the leap when it feels doable.
--
My career was mainly in engineering. I started while I was still in college and left college early to enter the work place (it became easy to get a programming job w/o a degree in the late 90s).
I've always been interested in building things (including businesses). It started when I was in elementary school and I would buy zots candy for $.02 and sell them for $.05 out of my locker. Anyways, I went on to start 2 startups (1 failed and the other had a soft landing).
PMing came natural to me because of my experience starting the startups. I didn't have any formal experience doing it but companies like Google will look past that.
My engineering background has been very helpful but the most helpful was my ability to think and reason about products.
TL;DR -- The ability, innate or learned, to reason about products is extremely helpful. Being good at working with others, conflict resolution and prioritization are critical. Best tip is to begin working on these skills and start framing yourself as product centric (on LinkedIn, within your company, etc.) and make the leap when it feels doable.
--
My career was mainly in engineering. I started while I was still in college and left college early to enter the work place (it became easy to get a programming job w/o a degree in the late 90s).
I've always been interested in building things (including businesses). It started when I was in elementary school and I would buy zots candy for $.02 and sell them for $.05 out of my locker. Anyways, I went on to start 2 startups (1 failed and the other had a soft landing).
PMing came natural to me because of my experience starting the startups. I didn't have any formal experience doing it but companies like Google will look past that.
My engineering background has been very helpful but the most helpful was my ability to think and reason about products.
> reason about products
Can you elaborate on this? It's unclear sometimes how much a PM's job is about delivering a predetermined product, vs how much is the PM themselves hypothesizing/strategizing about changes and improvements to the product.
Can you elaborate on this? It's unclear sometimes how much a PM's job is about delivering a predetermined product, vs how much is the PM themselves hypothesizing/strategizing about changes and improvements to the product.
That's a valid point. I think it depends on the company and how they define Product/Project Management.
TL;DR - In my experience it's a combination of both. You need to come up with a vision, convince others (non-direct reports and higher ups) that it's worth spending company $ on, and then be responsible for its success (however that's measured).
--
In some companies a Product Manager is more of a Project Manager and working on a product someone higher up has chartered. My comments do not apply to those roles because the company is probably less concerned about product vision and strategy from the candidate. And to be honest, many companies don't need Product Managers as much as they need Project Managers who help keep the engine of incremental progress running.
Other companies rely heavily on their Product group to come up with new and innovative products. I know this is the case with companies like Google, Facebook and many startups. It's easily visible by seeing if the company has recently launched anything truly different into the market.
Your level will also determine how much strategy and vision you'll be doing. Entry level Product Managers won't be asked to cast a vision for an ambitious product and release it. But as you get more experience you'll be doing more of that.
TL;DR - In my experience it's a combination of both. You need to come up with a vision, convince others (non-direct reports and higher ups) that it's worth spending company $ on, and then be responsible for its success (however that's measured).
--
In some companies a Product Manager is more of a Project Manager and working on a product someone higher up has chartered. My comments do not apply to those roles because the company is probably less concerned about product vision and strategy from the candidate. And to be honest, many companies don't need Product Managers as much as they need Project Managers who help keep the engine of incremental progress running.
Other companies rely heavily on their Product group to come up with new and innovative products. I know this is the case with companies like Google, Facebook and many startups. It's easily visible by seeing if the company has recently launched anything truly different into the market.
Your level will also determine how much strategy and vision you'll be doing. Entry level Product Managers won't be asked to cast a vision for an ambitious product and release it. But as you get more experience you'll be doing more of that.
> reason about Products:
1) If it's an existing product and someone is asking for an enhancement. You need to ask - is this enhancement unique to this person/client or does this apply to a generality of users/customers?
2) Sometimes you have to 'remove' yourself from the picture (i.e. as a user) and imagine how easy it would be for someone who is not technically savvy or conversant with something to easily use a product. An example - I sometimes have fellow PMs/colleagues argue that a design should be done in a particular way and an explanation put in the help (or documentation when it comes to ERP products). I typically counter that people rarely bother to go read up documentation when they suddenly don't understand something on an application screen. I'm not saying don't provide documentation or user guide but we should first exhaust the opportunity of trying to deliver an intuitive to use app.
1) If it's an existing product and someone is asking for an enhancement. You need to ask - is this enhancement unique to this person/client or does this apply to a generality of users/customers?
2) Sometimes you have to 'remove' yourself from the picture (i.e. as a user) and imagine how easy it would be for someone who is not technically savvy or conversant with something to easily use a product. An example - I sometimes have fellow PMs/colleagues argue that a design should be done in a particular way and an explanation put in the help (or documentation when it comes to ERP products). I typically counter that people rarely bother to go read up documentation when they suddenly don't understand something on an application screen. I'm not saying don't provide documentation or user guide but we should first exhaust the opportunity of trying to deliver an intuitive to use app.
I'm a PM at Snap Inc (formerly Snapchat). Before that, GPM at Twitter.
how did you get there / background
For me, engineering was the path that led to being a PM. I was a decent developer, but always found myself more interested in what we should be building opposed to how to build it. Background includes BS computer eng, masters in systems eng and an mba. Did software dev for years and gravitated toward roles that increasingly positioned me for PMing while getting those last two degrees.
"junior product" positions
There are junior product positions, just very few. Google/Twitter have an APM program. At FB it is the RPM program. There are many paths that lead to being a PM. Look for stepping stones and be persistent. I know PMs that were previously a software developer, product marketing manager, project manager, technical program manager, designer, etc. If you are able to take on one of those roles at a company that also has PMs, you can probably work towards a transition.
skills
In terms of skills, this thread on Quora is good, especially Ian McAllister's response: https://www.quora.com/What-distinguishes-the-Top-1-of-Produc... Keep in mind that different companies will put more or less weight on a particular competency. e.g. Google requires PMs to have a technical background will ask technical questions, facebook does not. Facebook will ask a lot of questions around data, experimentation, data-driven decision making, etc. because they are a very data driven culture.
how did you get there / background
For me, engineering was the path that led to being a PM. I was a decent developer, but always found myself more interested in what we should be building opposed to how to build it. Background includes BS computer eng, masters in systems eng and an mba. Did software dev for years and gravitated toward roles that increasingly positioned me for PMing while getting those last two degrees.
"junior product" positions
There are junior product positions, just very few. Google/Twitter have an APM program. At FB it is the RPM program. There are many paths that lead to being a PM. Look for stepping stones and be persistent. I know PMs that were previously a software developer, product marketing manager, project manager, technical program manager, designer, etc. If you are able to take on one of those roles at a company that also has PMs, you can probably work towards a transition.
skills
In terms of skills, this thread on Quora is good, especially Ian McAllister's response: https://www.quora.com/What-distinguishes-the-Top-1-of-Produc... Keep in mind that different companies will put more or less weight on a particular competency. e.g. Google requires PMs to have a technical background will ask technical questions, facebook does not. Facebook will ask a lot of questions around data, experimentation, data-driven decision making, etc. because they are a very data driven culture.
> I was a decent developer, but always found myself more interested in what we should be building opposed to how to build it.
This. But I want to do both and continue to improve the dev side of my game.
This. But I want to do both and continue to improve the dev side of my game.
I'm also exactly there. I feel I cannot really excel at dev while I enjoy it, but I believe I can make a difference in PM
If anyone wants to have a quick chat (10 mins) about getting into PM'ing, what PMs do, etc., I hold office hours here: https://officehours.io/people/toddsherman
I'm not a PM, but I partner closely with them and also interview them. At LinkedIn, most of our PMs have both an MBA and a technical background of some sort. Many have also started companies of their own in the past.
We actually DO have junior PM roles -- "Associate Product Manager" positions that are designed to ease people into the PM path and let them grow into the full skill set.
Key skills are ruthless prioritization (project manager skills) plus product vision. A great PM can look at a bunch of information (our current assets, market trends, internal and external data, etc), develop a vision of what our future should look like, convert it into a practical roadmap to get us there, and herd all the cats to actually make it happen.
We actually DO have junior PM roles -- "Associate Product Manager" positions that are designed to ease people into the PM path and let them grow into the full skill set.
Key skills are ruthless prioritization (project manager skills) plus product vision. A great PM can look at a bunch of information (our current assets, market trends, internal and external data, etc), develop a vision of what our future should look like, convert it into a practical roadmap to get us there, and herd all the cats to actually make it happen.
Hi! Intrigued by the Associate Product Manager role - as someone who has been a Scrum Master and product lead for roughly a year at IBM, would this be enough experience to open the door to a Junior PM Role?
Thanks for the insight, especially about the junior position at LinkedIn. I am an engineer who has run a start up previously in recruiting space and looking for product roles at LinkedIn. Is there a way i can reach out with few questions?
PM @ a well funded AI startup. Previously PM at Netflix. Management consultant prior.
Undergraduate degree in Psychology. Background in marketing/business and customer acquisition. I learned enough programming to automate my marketing activities, and found that I liked driving a roadmap more than I liked acquiring customers.
-Communication and conflict resolution skills are key. You are in a role where you must drive influence without having any direct reports. This means effective, articulate communication skills are required. Know how your voice needs to change between communication to engineering versus communication to an executive or board member.
-At Netflix, I was often told my job was to add clarity. Add clarity to a technical specifications document. Add clarity to the marketing teams understanding of a product feature. The best PMs are able to consolidate their understanding of a 35 page technical document into two sentences.
-Market sizing and back of the envelope calculations. Know how large the market is for your product. How much more can you charge for your product if you add X feature? How long is X feature going to take in engineering cycles? Is this the best way to spend your engineering resources? In my daily routine, I probably make 10 calculations like this and have a response ready for either our product director, CEO, board member, or customer.
-Financial modeling. I've found that modeling skills are absolutely key - know how to model out customer lifetime value, churn rates, and cash flow. You should be prepared to be a 'mini CFO,' because at the end of the day, you are asking for more resources from your executive suite, and are best off making those requests in CFO format.
-Know your technology. Know what is possible and know how to articulate requirements that speak to your technology. This is why there is often a technical barrier for PMs - you have to know how things work, and what is physically possible versus cost prohibitively impossible. This doesn't mean you need to know how to code - but that is helpful. Know source control and developer operations processes. Know how to plan for scale. Know how to recognize elegant solutions for difficult problems, and reward your engineering team for failing spectacularly.
-Finally - be humble and be accountable. It is always your fault, because you are accountable for the success of your product. Don't throw your engineering team into the middle of a sh*tstorm of management politics - be their umbrella. Don't blame customers, politics, or resources. It's always your fault. Find a way to fix it.
Undergraduate degree in Psychology. Background in marketing/business and customer acquisition. I learned enough programming to automate my marketing activities, and found that I liked driving a roadmap more than I liked acquiring customers.
-Communication and conflict resolution skills are key. You are in a role where you must drive influence without having any direct reports. This means effective, articulate communication skills are required. Know how your voice needs to change between communication to engineering versus communication to an executive or board member.
-At Netflix, I was often told my job was to add clarity. Add clarity to a technical specifications document. Add clarity to the marketing teams understanding of a product feature. The best PMs are able to consolidate their understanding of a 35 page technical document into two sentences.
-Market sizing and back of the envelope calculations. Know how large the market is for your product. How much more can you charge for your product if you add X feature? How long is X feature going to take in engineering cycles? Is this the best way to spend your engineering resources? In my daily routine, I probably make 10 calculations like this and have a response ready for either our product director, CEO, board member, or customer.
-Financial modeling. I've found that modeling skills are absolutely key - know how to model out customer lifetime value, churn rates, and cash flow. You should be prepared to be a 'mini CFO,' because at the end of the day, you are asking for more resources from your executive suite, and are best off making those requests in CFO format.
-Know your technology. Know what is possible and know how to articulate requirements that speak to your technology. This is why there is often a technical barrier for PMs - you have to know how things work, and what is physically possible versus cost prohibitively impossible. This doesn't mean you need to know how to code - but that is helpful. Know source control and developer operations processes. Know how to plan for scale. Know how to recognize elegant solutions for difficult problems, and reward your engineering team for failing spectacularly.
-Finally - be humble and be accountable. It is always your fault, because you are accountable for the success of your product. Don't throw your engineering team into the middle of a sh*tstorm of management politics - be their umbrella. Don't blame customers, politics, or resources. It's always your fault. Find a way to fix it.
>-Finally - be humble and be accountable. It is always your fault, because you are accountable for the success of your product. Don't throw your engineering team into the middle of a sh*tstorm of management politics - be their umbrella. Don't blame customers, politics, or resources. It's always your fault. Find a way to fix it.
Man, I would love to work for someone that actually strives to do this. Awesome.
Man, I would love to work for someone that actually strives to do this. Awesome.
Were you at any organisations where they did 360° feedback? What kind of feedback did you receive from developers or designers from your team? What I'm trying to understand is how are organisations ensuring that PMs and team are not in disconnect from how things really are. I know that's a different realm but just trying to understand how did you find what to improve or learn to be a better PM?
Netflix and my current organization religiously practice 360 degree feedback. For my own projects, I practice 360 degree feedback as well. I don't think a team or organization can succeed if employees cannot speak to each other candidly about performance.
My typical feedback from engineering:
1) I state resolutions of a problem without clearly defining the problem.
This was/is my biggest failure as a product manager and is something I work on daily. I enjoy the 'fun' of solving problems but respect that my job is not to solve the problem. My job is to understand the market, define customer and their needs, and create requirements that need to be met to resolve those customer needs.
2) I over-engineer. I like to solve problems with complex, scalable, 'sexy' solutions. At Netflix, my team built a real time marketing analytics platform that used kafka/spark/elasticsearch and an enormous cluster to aggregate marketing data from 5+ marketing platforms. The client was built in angular/d3 and returned aggregations on 1B+ rows of data in < 100ms.
We were so invested in scale and performance that minor changes to the underlying schema (which happened often, as marketing priorities shifted) required a lot of work. This was a huge over engineering mistake on my behalf.
3) I can come off as patronizing. In an effort to describe a problem space or market, my tone has been perceived as patronizing.
4) I do not practice enough active listening. I end up driving conversations and do not make people feel heard.
Being humble and asking for feedback is the best way to learn to be a better PM. Of the PMs I've seen rise(and fall) through the ranks of management, I have generally found that humility, integrity/accountability, and communication skills are the most correlated with success.
My typical feedback from engineering:
1) I state resolutions of a problem without clearly defining the problem.
This was/is my biggest failure as a product manager and is something I work on daily. I enjoy the 'fun' of solving problems but respect that my job is not to solve the problem. My job is to understand the market, define customer and their needs, and create requirements that need to be met to resolve those customer needs.
2) I over-engineer. I like to solve problems with complex, scalable, 'sexy' solutions. At Netflix, my team built a real time marketing analytics platform that used kafka/spark/elasticsearch and an enormous cluster to aggregate marketing data from 5+ marketing platforms. The client was built in angular/d3 and returned aggregations on 1B+ rows of data in < 100ms.
We were so invested in scale and performance that minor changes to the underlying schema (which happened often, as marketing priorities shifted) required a lot of work. This was a huge over engineering mistake on my behalf.
3) I can come off as patronizing. In an effort to describe a problem space or market, my tone has been perceived as patronizing.
4) I do not practice enough active listening. I end up driving conversations and do not make people feel heard.
Being humble and asking for feedback is the best way to learn to be a better PM. Of the PMs I've seen rise(and fall) through the ranks of management, I have generally found that humility, integrity/accountability, and communication skills are the most correlated with success.
What a wonderful and candid reply. Those 4 things are common feedbacks as a PM. It's a role where it can be easy to fool yourself that you think you already know everything. I believe a lot of PMs (myself included) often/always need to continuously improve on. But few would be as open and receptive to speaking of them, or ready to actively work on being more humble, more accountable.
This is so awesome, wasn't expecting such detailed response! I think we all have some of these flaws but having channels to have this feedback and to have open discussions without any ego or taking it personally makes the best teams. Currently I'm not in such a team but I was in past and wish to find one soon!
Thanks for sharing. How are you guys organized at Netflix? Is there a distinction between platform product managers and solution product managers? From outside it looks like the world is divided as Content led by Ted Sarandos and Platform led by Neil Hunt.
when I asked this question I first expected a lot of answers in the lines of your "Financial Modeling" part. Funnily, you are the only one that's named it so far. Anyhow all the answers have been so incredibly enriching...
Not sure if I am product manager per se but here's my story.
Have been a developer for about 12 years, starting at the very bottom at age 18 with no degree or other qualifications. Got promoted through all the different seniorities throughout that time. Then my current company created a new management role for me (Head of Product Development) about a year ago, giving me the dev team and my previous boss (Head of IT) the tech support.
I'm still very much involved in the actual coding but now I am involved in higher level decision making and am the first point of call in anything todo with our products (basically a SaaS company). There's a lot of pressure meeting deadlines etc whilst managing the HR (which I could do without) of my team, but I still love my job 99% of the time.
Edit: Skills are
1. being approachable from all areas of the business and understanding everyones point of view
2. being able to handle deadlines and manage them appropriately
3. actively keep an eye on the relevant areas in your industry and market
4. work directly with customers where applicable
5. being creative
6. hitting said deadlines!
Have been a developer for about 12 years, starting at the very bottom at age 18 with no degree or other qualifications. Got promoted through all the different seniorities throughout that time. Then my current company created a new management role for me (Head of Product Development) about a year ago, giving me the dev team and my previous boss (Head of IT) the tech support.
I'm still very much involved in the actual coding but now I am involved in higher level decision making and am the first point of call in anything todo with our products (basically a SaaS company). There's a lot of pressure meeting deadlines etc whilst managing the HR (which I could do without) of my team, but I still love my job 99% of the time.
Edit: Skills are
1. being approachable from all areas of the business and understanding everyones point of view
2. being able to handle deadlines and manage them appropriately
3. actively keep an eye on the relevant areas in your industry and market
4. work directly with customers where applicable
5. being creative
6. hitting said deadlines!
The biggest thing to remember is that a manager is a servant of the team. Never the other way around. You enable them to do work. Which means handling information, communicating, helping them communicate, talking to management, protecting them from unreasonableness, setting clear goals, going to pick up the dang pizza yourself so the work doesn't stop, making sure there are long stretches of time to do work,etc. You do more grunt work than anybody and in return leadership happens.
You nailed it. The best manager I had was the one who knew everything about the project, diligently updated all KPIs and not only did normal PM work but went beyond that when needed. I still remember the day when she needed me to work on weekend, she was so apologetic came early morning to pick me from home, dropped me back and always made sure everyone in the team was satisfied. She truly embraced servant-leadership.
I'm a product manager for Lightcloud, a next-gen wireless lighting control system. I'm a generalist—undergrad in Architecture with a minor in Poetry, masters in technological art (ITP at NYU), self-taught programmer since elementary school (thanks Dad!).
My product management position grew out of a freelance job, where I was contracted to build a proof-of-concept for the products that we now install on sites all over the US. At first I was managing EVERYTHING, but gradually we spread things out effectively and I now do R&D for new products, high-level UX design of the software and as much of the hardware as I can, and coordinate engineering, sales, CMs, execs, etc. and whatever else needs doing to make sure the products get made and launched with the best possible UX.
> What skills must be demonstrable?
1. Talk to users/customers/salespeople. Understand the product, understand the customers, understand the market.
2. Understand your engineering team(s). Get them excited about the product and make sure they understand WHY the product is being designed/executed in the way that it is.
3. Be an innovative designer. Think laterally. Experience art. Invent new ways of addressing the customer's needs. Don't take 1 step back, don't take 10 steps back, take 100 steps back. Think about what the product is really doing and what the customer really needs. Strip it to the core and imagine the perfect solutions to the problems. Throw out how things are "normally" done (then reconsider them later). If you can't, then I guess at least hire an experienced, professional, creative UX designer.
4. Communicate exceedingly well. Reply to people immediately. Make sure they realize that you care about their needs and opinions. Be extremely accessible.
My product management position grew out of a freelance job, where I was contracted to build a proof-of-concept for the products that we now install on sites all over the US. At first I was managing EVERYTHING, but gradually we spread things out effectively and I now do R&D for new products, high-level UX design of the software and as much of the hardware as I can, and coordinate engineering, sales, CMs, execs, etc. and whatever else needs doing to make sure the products get made and launched with the best possible UX.
> What skills must be demonstrable?
1. Talk to users/customers/salespeople. Understand the product, understand the customers, understand the market.
2. Understand your engineering team(s). Get them excited about the product and make sure they understand WHY the product is being designed/executed in the way that it is.
3. Be an innovative designer. Think laterally. Experience art. Invent new ways of addressing the customer's needs. Don't take 1 step back, don't take 10 steps back, take 100 steps back. Think about what the product is really doing and what the customer really needs. Strip it to the core and imagine the perfect solutions to the problems. Throw out how things are "normally" done (then reconsider them later). If you can't, then I guess at least hire an experienced, professional, creative UX designer.
4. Communicate exceedingly well. Reply to people immediately. Make sure they realize that you care about their needs and opinions. Be extremely accessible.
Studied CS initially, worked as a freelancer, then a few developer positions, then CTO at a small (30 employees) enterprise SaaS company. Later on I took a head of product position at a larger (400), also enterprise SaaS company.
As a freelancer you usually have a lot of discretion in what you build so you develop a sensitivity about cost/benefit tradeoffs and quality of deliverables. These are essential for the PM role. In larger organizations, roles tend to become more specialized and therefore keeping a broad perspective is very important.
In my experience, the background in engineering has made it easy to gain credibility with technical people. I have seen the same sentiment in some of the other comments and it's hard to overstate it.
My key base skill is speaking multiple languages: the engineering language, the design language, the people language and the business language. That can be applied to many things, PM being one of them. If you are strictly an engineer, gain experience and exposure to other things.
As a freelancer you usually have a lot of discretion in what you build so you develop a sensitivity about cost/benefit tradeoffs and quality of deliverables. These are essential for the PM role. In larger organizations, roles tend to become more specialized and therefore keeping a broad perspective is very important.
In my experience, the background in engineering has made it easy to gain credibility with technical people. I have seen the same sentiment in some of the other comments and it's hard to overstate it.
My key base skill is speaking multiple languages: the engineering language, the design language, the people language and the business language. That can be applied to many things, PM being one of them. If you are strictly an engineer, gain experience and exposure to other things.
Head of PM here. I lead 3 PMs in my current position at Styla.com and have taught product management at General Assembly courses.
I myself come from a self-taught programmer background and found myself questioning the product strategy or design decisions towards managers until I was offered a PM position. I do find the technical background enables me to level with devs quite easily but I don't think it's a requirement. A pattern that has been working very well at SoundCloud is that we liked to transition customer support people into a PM role.
Important feats or skills I additionally look for in good PMs are:
- be a users advocate. Has to be good at putting themselves into the users' position and transfer that perspective to the team.
- has to be really good at email. Org/management/soft skills aside, the most powerful tool of a PM is email.
- eager to learn and apply those learnings quickly.
- be comfortable with numbers but be skeptical at the same time. Data is important but be wary of bias.
I myself come from a self-taught programmer background and found myself questioning the product strategy or design decisions towards managers until I was offered a PM position. I do find the technical background enables me to level with devs quite easily but I don't think it's a requirement. A pattern that has been working very well at SoundCloud is that we liked to transition customer support people into a PM role.
Important feats or skills I additionally look for in good PMs are:
- be a users advocate. Has to be good at putting themselves into the users' position and transfer that perspective to the team.
- has to be really good at email. Org/management/soft skills aside, the most powerful tool of a PM is email.
- eager to learn and apply those learnings quickly.
- be comfortable with numbers but be skeptical at the same time. Data is important but be wary of bias.
I've been a PM for over 6 years now and made the transition from an IT Dev Manager. I basically made the case that I understood the product, its target customer, and the value for the company. If you can master that, you're set. Everyone has ideas for new features, but PM's balance the needs of the customer with cost to develop and value to the company. This requires that you understand the market, your competitors, and your customers. The PMs that thrive have mastered this, but more importantly, they've learned how to get the team to work together efficiently -- both the technical side as well as the management side (cutting through the political and management BS). If you are interested in becoming a product manager, know what skills you bring to the table. If you are a developer, you bring strong analytical and technical skills as well as an understanding of the technical effort required to bring a new feature to market. Probably the best skill you would need to demonstrate is judgment: which feature would bring the most value for the least cost. And then showing how would you prioritize the roadmap of features after that.
Have a somewhat unconventional route to becoming a PM.
Project Manager -> Product Marketing -> Product Management
Personally, demonstrable skills that I look for in PMs:
1) Ability to quickly execute on the short term but always keep an eye on the long term
2) Great communication skills with all sides of the business (sales, support, eng, cust. success)
3) A backbone - don't always take "no" as a first answer, try to solve the problems in different ways, think outside of the box
4) Creative - aptitude towards building pretty yet functional products
5) Critical problem solving
6) Humble but confident
7) Fairly deep understanding of the industry you're in
The one thing that has become very clear to me over the course of my career its that there is no one way to becoming a PM and no "course" for it. There is a need for technical PMs, for non-technical PMs, for MBAs, for rapid execution, for strategic execution, etc.
The role and the requirements highly depend on the stage of the company, the vertical the company is in, the complexity of the system, and so much more. I do think that a good general advice is to focus on these 3 areas if you want to move into being a PM:
1) Understanding the business model
2) Understanding how to communicate across departments
3) Understanding a decent amount on the technical side
Personally, demonstrable skills that I look for in PMs:
1) Ability to quickly execute on the short term but always keep an eye on the long term
2) Great communication skills with all sides of the business (sales, support, eng, cust. success)
3) A backbone - don't always take "no" as a first answer, try to solve the problems in different ways, think outside of the box
4) Creative - aptitude towards building pretty yet functional products
5) Critical problem solving
6) Humble but confident
7) Fairly deep understanding of the industry you're in
The one thing that has become very clear to me over the course of my career its that there is no one way to becoming a PM and no "course" for it. There is a need for technical PMs, for non-technical PMs, for MBAs, for rapid execution, for strategic execution, etc.
The role and the requirements highly depend on the stage of the company, the vertical the company is in, the complexity of the system, and so much more. I do think that a good general advice is to focus on these 3 areas if you want to move into being a PM:
1) Understanding the business model
2) Understanding how to communicate across departments
3) Understanding a decent amount on the technical side
For people who transferred from dev to pm, was the salary comparable in the beginning? Did you have to take huge hit in order to break into another industry with no formal experience in managing product?
Most companies have created a Technical PM role, partially because of the requirement for technical skills, but partially to justify paying 1.5x salary to match what you could be making as a developer, so talented PMs are not encouraged financially to go back into development. If you're considering this, most companies should be able to match salary requirements.
Former PM at Google here -
I studied computer science as an undergrad but was pretty rubbish as a coder to be honest. I spent 4 years at Intel in their technical sales program, which was a nice way to learn business skills and particularly B2B selling skills in a non-salesy environment. They also paid for graduate work in MS&E at Stanford which was a nice bonus. By luck, I had a friend of a friend at Google and sent in a resume and got a call back to join their associate program. Spent 4 years there, mostly as a Product Manager in ads.
I think having a technical degree was quite useful to build trust with engineering. Particularly with very talented engineers you need to develop a level of trust to make decision making collaborative, where you can synthesize the need from users/internal teams and then work with engineering to understand tradeoffs, timing constraints and critical features vs longer term features. I'm a lousy dev but it was helpful to be able to run mapreduce jobs to do analysis and present that back to engineering when making decisions, or doing the one-off jobs that they didn't find exciting but were useful to making their jobs smoother. And that credibility goes a long way - developers are far more willing to work above and beyond if they trust you're asking them to do valuable things that won't be discarded on a whim by the organization.
The one key skill IMO for anyone in PM is managing without authority. As a PM you rarely have direct reports (except other PMs) so you need to often shape the direction of sales, marketing, eng and support without actual authority over those teams, so it requires a mindset to find compromise constantly but then also fight when necessary or at least lean on people for help that don't necessarily have you as a priority in their own job. You're the intern CEO - you often are the gatekeeper for all sorts of things left and right, but you can't actually compel anyone to do anything except with persuasion and logic.
Also you have to balance in-office time with getting out and talking to stakeholders. I travelled to almost every remote office we had and tried to meet w/ salespeople and customers. It's not always high ROI but it builds relationships and creates a further rapport that comes in handy again - I would often meet publishers outside the US and take feedback from them that was really helpful and we wouldn't have otherwise thought of in Mountain View.
After PM I got into venture capital and it's a similar skillset of soft management. I think PMs make good VCs later in life. Being a board director is similar in a way that you have the ability to do things but if you need to command things, the battle is probably already lost.
I studied computer science as an undergrad but was pretty rubbish as a coder to be honest. I spent 4 years at Intel in their technical sales program, which was a nice way to learn business skills and particularly B2B selling skills in a non-salesy environment. They also paid for graduate work in MS&E at Stanford which was a nice bonus. By luck, I had a friend of a friend at Google and sent in a resume and got a call back to join their associate program. Spent 4 years there, mostly as a Product Manager in ads.
I think having a technical degree was quite useful to build trust with engineering. Particularly with very talented engineers you need to develop a level of trust to make decision making collaborative, where you can synthesize the need from users/internal teams and then work with engineering to understand tradeoffs, timing constraints and critical features vs longer term features. I'm a lousy dev but it was helpful to be able to run mapreduce jobs to do analysis and present that back to engineering when making decisions, or doing the one-off jobs that they didn't find exciting but were useful to making their jobs smoother. And that credibility goes a long way - developers are far more willing to work above and beyond if they trust you're asking them to do valuable things that won't be discarded on a whim by the organization.
The one key skill IMO for anyone in PM is managing without authority. As a PM you rarely have direct reports (except other PMs) so you need to often shape the direction of sales, marketing, eng and support without actual authority over those teams, so it requires a mindset to find compromise constantly but then also fight when necessary or at least lean on people for help that don't necessarily have you as a priority in their own job. You're the intern CEO - you often are the gatekeeper for all sorts of things left and right, but you can't actually compel anyone to do anything except with persuasion and logic.
Also you have to balance in-office time with getting out and talking to stakeholders. I travelled to almost every remote office we had and tried to meet w/ salespeople and customers. It's not always high ROI but it builds relationships and creates a further rapport that comes in handy again - I would often meet publishers outside the US and take feedback from them that was really helpful and we wouldn't have otherwise thought of in Mountain View.
After PM I got into venture capital and it's a similar skillset of soft management. I think PMs make good VCs later in life. Being a board director is similar in a way that you have the ability to do things but if you need to command things, the battle is probably already lost.
thanks, this was particularly insightful
I started in communications/marketing and fell into the position. We have associate product managers at my company, although I walked straight into the full role. It was a few years before I felt comfortable.
Key skills? I would say an ability to relate to and communication with others and a solid understanding of the business you are in. Marketing experience helped me a lot in that regard as I spent five years explaining releases and product updates to users.
I'm not a developer by any stretch of the imagination, but I was fortunate to have a pair of patient devs who put up with some ignorance in the early days as I gained a better understanding of how the process and systems work together.
Key skills? I would say an ability to relate to and communication with others and a solid understanding of the business you are in. Marketing experience helped me a lot in that regard as I spent five years explaining releases and product updates to users.
I'm not a developer by any stretch of the imagination, but I was fortunate to have a pair of patient devs who put up with some ignorance in the early days as I gained a better understanding of how the process and systems work together.
PM @ Zoosk Labs (Zoosk's in-house incubator).
I am a 20 year old Product Manager. I started a software company at the age of 15 and went on to do more startups afterwards. I got pretty involved in software engineering. I never went to college and I don't have any formal experience. I enjoy Product Management because it's leadership without control. You're more of a diplomat than you are a dictator. Which is really humbling and rewarding!
I enjoy what I do but I still code and design :)
I am a 20 year old Product Manager. I started a software company at the age of 15 and went on to do more startups afterwards. I got pretty involved in software engineering. I never went to college and I don't have any formal experience. I enjoy Product Management because it's leadership without control. You're more of a diplomat than you are a dictator. Which is really humbling and rewarding!
I enjoy what I do but I still code and design :)
I've cofunded my own startup, so I don't know if this is a useful answer to you.
During the first days of our company, my co-founder and I used to do everything: coding, preparing content, teaching, marketing, sales. Everything.
As we grew a little bit over the last year, we've had to specialize on different things and stop doing everything both of us.
I've taking the lead on the "product management" part so I started researching about it. I'm a programmer by training, so I kind of went looking for "product management courses". To be honest, if you're a developer, there's nothing you need to learn. I emailed an old product manager that led a project I worked for and asked him for advice (he's a great product manager with a ton of experience).
His answer was kind of: "you don't need to learn anything special: the key is to stick to the basic principles that you already know".
For me, a good product manager is a ruthless, constant person. If you compare it to Football, it's not the guy that shines 1 match and then is hidden for two. It's the guy that constantly delivers.
You have to wake up every morning and analyze what needs to be done, prioritize it, talk to your engineers, talk to C-level, and repeat. Over and over again.
I don't know what everyone else think, but being a programmer is a great background to become a good product manager. I've been coding for over 8 years and now, whenever we're discussing a feature or issue, it takes minutes to understand how much it implies (in time, resources, etc).
During the first days of our company, my co-founder and I used to do everything: coding, preparing content, teaching, marketing, sales. Everything.
As we grew a little bit over the last year, we've had to specialize on different things and stop doing everything both of us.
I've taking the lead on the "product management" part so I started researching about it. I'm a programmer by training, so I kind of went looking for "product management courses". To be honest, if you're a developer, there's nothing you need to learn. I emailed an old product manager that led a project I worked for and asked him for advice (he's a great product manager with a ton of experience).
His answer was kind of: "you don't need to learn anything special: the key is to stick to the basic principles that you already know".
For me, a good product manager is a ruthless, constant person. If you compare it to Football, it's not the guy that shines 1 match and then is hidden for two. It's the guy that constantly delivers.
You have to wake up every morning and analyze what needs to be done, prioritize it, talk to your engineers, talk to C-level, and repeat. Over and over again.
I don't know what everyone else think, but being a programmer is a great background to become a good product manager. I've been coding for over 8 years and now, whenever we're discussing a feature or issue, it takes minutes to understand how much it implies (in time, resources, etc).
| I'm a programmer by training, so I kind of went looking for "product management courses".
hehe, been there... It feels like there must be some structured way to learn on processes, techniques, etc... but there's none :p
hehe, been there... It feels like there must be some structured way to learn on processes, techniques, etc... but there's none :p
PM is a really awful position, these slick guys come in and take all the credit for the work of the engineering and design teams. It's demoralizing. A better setup I've seen is having no PMs, engineering and design team members stay on top of analytics, user feedback, market trends, business concerns, etc. Everybody provides product and process feedback at monthly meetings. It's way more empowering and agile. We don't need PMs!
> these slick guys come in and take all the credit for the work of the engineering and design teams.
The PMs that take all the credit are bad PMs. The best PMs I've worked with do a ton of behind-the-scenes work and give all the credit to the team. Having a PM that takes care of...
> analytics, user feedback, market trends, business concerns, etc.
..will boost productivity for any engineer or designer.
The PMs that take all the credit are bad PMs. The best PMs I've worked with do a ton of behind-the-scenes work and give all the credit to the team. Having a PM that takes care of...
> analytics, user feedback, market trends, business concerns, etc.
..will boost productivity for any engineer or designer.
But when you "boost productivity" by taking away ownership of the product you're trying to turn the engineers into code monkeys that implement your wishes without too much questioning. In reality it decreases productivity because you've taken away a big part of the fun of building things, the connection with the users and the business. And it drives away the better people.
To be fair (and I am not trying to defend these 'Slick guys'), sometimes there is a lot more happening behind closed doors that a PM might let on. Fights for resources, maintaining a current team, hiring, ownership, etc.
Oftentimes those people trying to portray a 'Slick' exterior are doing so due to the need to portray a sense of success/confidence for their team, to make sure they retain their existing budget and that the team doesn't get moved to other projects or terminated entirely.
Oftentimes those people trying to portray a 'Slick' exterior are doing so due to the need to portray a sense of success/confidence for their team, to make sure they retain their existing budget and that the team doesn't get moved to other projects or terminated entirely.
Man I have to say... from what I've seen over the last 20 years in the industry, this is a very junior-minded position to take. If someone said, "We don't need UX design," or "We don't need DevOps," they'd be laughed out of the building. It takes a village... takes a collection of talented people working in unison to have a successful product.
It's horrendously inefficient for an organization to take away Product Managers. If you want to bring every designer and every developer and ever sales person... and basically your whole company to a meeting to make a decision... maybe you'll get away with cutting the Product Manager role... But there's so much inherent compromise and horse trading as part of every product launch / sprint.
Without someone to organize all that, you're going to waste a lot of time and force a lot of highly skilled people to do things that aren't in their wheelhouse. And then... at the end of the day... who is on the hook for strategy? "Oh, hey we built the wrong MVP so I guess we'll sack some of our <rolls the dice...> Visual Designers!" That makes no sense.
Any complex system or organization will need a management layer... think of them as lubrication if you want... to help all the different parts move efficiently. The team is responsible for the success of the endeavor, anyone worth keeping in an organization knows how to give praise where it's due... if you have individuals trying to take credit for teamwork... that's an issue you should take up with HR.
It's horrendously inefficient for an organization to take away Product Managers. If you want to bring every designer and every developer and ever sales person... and basically your whole company to a meeting to make a decision... maybe you'll get away with cutting the Product Manager role... But there's so much inherent compromise and horse trading as part of every product launch / sprint.
Without someone to organize all that, you're going to waste a lot of time and force a lot of highly skilled people to do things that aren't in their wheelhouse. And then... at the end of the day... who is on the hook for strategy? "Oh, hey we built the wrong MVP so I guess we'll sack some of our <rolls the dice...> Visual Designers!" That makes no sense.
Any complex system or organization will need a management layer... think of them as lubrication if you want... to help all the different parts move efficiently. The team is responsible for the success of the endeavor, anyone worth keeping in an organization knows how to give praise where it's due... if you have individuals trying to take credit for teamwork... that's an issue you should take up with HR.
On behalf of all PMs, I'm sorry you had this experience. Good PMs tend to do just the opposite. If you are in this situation now, I encourage you to share this feedback to the person that is most likely to help change it (ideally with the PM directly?).
As a company scales, there is a tendency to embrace specializations through a division of labor. Of course, different companies adopt different models for various reasons. e.g. Do you need dedicated QA or does that fall upon the developers? With these decisions come trade-offs because you can't optimize for everything. Your proposed model can work, but is far less common in large tech companies because of the overhead of coordinating/communicating across lots of people which tends to fall upon PMs.
As a company scales, there is a tendency to embrace specializations through a division of labor. Of course, different companies adopt different models for various reasons. e.g. Do you need dedicated QA or does that fall upon the developers? With these decisions come trade-offs because you can't optimize for everything. Your proposed model can work, but is far less common in large tech companies because of the overhead of coordinating/communicating across lots of people which tends to fall upon PMs.
I think you're pointing out what can happen if PMing isn't done correctly. If you have worked with a good and skilled PM, you'll feel quite the opposite.
[deleted]
PM @ Adobe
I joined as QE over 12 years ago. By taking a lead in online forums and a growing social network system, I put myself in contact with a lot more users than product management at the time was reaching. As my knowledge of the product and market space grew, I began making more product decisions.
When I first took the PM role for the product, PM was more of an evangelist role in our group. As our group became more data-driven, we've had to adapt and grow our typical PM skills of market sizing, prioritization, roadmap, and all the product vision and strategy that accompanies that. It's definitely a good transition and is making our product teams stronger.
When looking at new PM hires, crucial skills are being able to identify market (customer) needs, validate that with strong data, and prioritize requirements. It requires working closely with engineering, UX, marketing, and upper management. Especially when communicating with VP and Director level folks, being able to summarize the vision and course in a few words and justifying it with projects of growth in users or revenue is absolutely crucial.
I joined as QE over 12 years ago. By taking a lead in online forums and a growing social network system, I put myself in contact with a lot more users than product management at the time was reaching. As my knowledge of the product and market space grew, I began making more product decisions.
When I first took the PM role for the product, PM was more of an evangelist role in our group. As our group became more data-driven, we've had to adapt and grow our typical PM skills of market sizing, prioritization, roadmap, and all the product vision and strategy that accompanies that. It's definitely a good transition and is making our product teams stronger.
When looking at new PM hires, crucial skills are being able to identify market (customer) needs, validate that with strong data, and prioritize requirements. It requires working closely with engineering, UX, marketing, and upper management. Especially when communicating with VP and Director level folks, being able to summarize the vision and course in a few words and justifying it with projects of growth in users or revenue is absolutely crucial.
PM @ a mid-size startup (been one for 5 years).
Skills:
- Be able to sympathize with your users (and be able to translate their pain into actionable steps that build toward your company's bigger goal)
- Be a communicator. You need to be able to write help documents, update emails, epics, stories, etc. Verbally, you should be able (and want!) to get up in front of your company and evangelize the work you're doing.
- Be a junior project manager. Even if you have project people in your company, you need to keep the trains running. Sometimes that means you've gotta be a dick to people too.
- Demonstrate deep understanding of your product. You're going to have to make tradeoffs and compromises along the way and knowing the landscape of your product (both from the user's perspective and the technical perspective) helps you make better decisions.
- Be able to prioritize. This one is tough to demonstrate, but good PMs know how to effectively take a long list of requirements or stories and prioritize them based on what will drive the most value
- Be able to think big. It's easy to go for incremental wins, but you've really got to be able to take the long view of your product. Your customers, sales team, and engineers will all want to do things that aren't part of your product's vision and you've got to know that.
Background: I was a history major in college. Almost did a PhD. I've always had an interest in coding -- taught myself Java, PHP, MySQL. When I finally got serious about having a career, I joined a company as a member of their marketing team. My 'programming' background made me the natural lead for talking to our tech team. Eventually, they changed my title to product manager and I was in.
Skills:
- Be able to sympathize with your users (and be able to translate their pain into actionable steps that build toward your company's bigger goal)
- Be a communicator. You need to be able to write help documents, update emails, epics, stories, etc. Verbally, you should be able (and want!) to get up in front of your company and evangelize the work you're doing.
- Be a junior project manager. Even if you have project people in your company, you need to keep the trains running. Sometimes that means you've gotta be a dick to people too.
- Demonstrate deep understanding of your product. You're going to have to make tradeoffs and compromises along the way and knowing the landscape of your product (both from the user's perspective and the technical perspective) helps you make better decisions.
- Be able to prioritize. This one is tough to demonstrate, but good PMs know how to effectively take a long list of requirements or stories and prioritize them based on what will drive the most value
- Be able to think big. It's easy to go for incremental wins, but you've really got to be able to take the long view of your product. Your customers, sales team, and engineers will all want to do things that aren't part of your product's vision and you've got to know that.
Background: I was a history major in college. Almost did a PhD. I've always had an interest in coding -- taught myself Java, PHP, MySQL. When I finally got serious about having a career, I joined a company as a member of their marketing team. My 'programming' background made me the natural lead for talking to our tech team. Eventually, they changed my title to product manager and I was in.
I actually did find a place with junior product manager positions. I was working in QA and impressed some of the product managers, so they asked if I wanted to transfer to their department as an assistant product manager. I made the transfer and over the next 2 years I helped out on basically all the different parts of a product lifecycle, but was never the actual PM of any particular thing.
Last year they started giving me smaller, low profile products of my own to manage, and at this point I'm full into it.
I'm not the only one, either. One girl started at age 23 as an administrative assistant and after proving herself capable they kept giving her more stuff until now she's a full blown product manager at age 29. We actually do this pretty often because our current management takes the stance that it's easier to train smart people into the job over the course of a couple years than it is to find good people with relevant experience who are willing to relocate here (I'm in Shenzhen).
Last year they started giving me smaller, low profile products of my own to manage, and at this point I'm full into it.
I'm not the only one, either. One girl started at age 23 as an administrative assistant and after proving herself capable they kept giving her more stuff until now she's a full blown product manager at age 29. We actually do this pretty often because our current management takes the stance that it's easier to train smart people into the job over the course of a couple years than it is to find good people with relevant experience who are willing to relocate here (I'm in Shenzhen).
Got there (although I never feel like I'm "there", always trying to improve) after 2 years of grunt work, a little bit of career planning, and a lot of luck. I'm currently a PM in a global trade software vendor.
After working in the same industry for 2 years in an entry level operational capacity, I was headhunted by my current company who was looking to build out product in that area. Although I was very unmotivated during college and my degree in cognitive psychology is worth the paper it's printed on, I had programming experience and was self-learning on web development at the time. A combination of basic understanding of systems and software development, deep industry operational experience, and obvious enthusiasm for the job was enough to get hired.
While there are some direct paths to Product Management (often Business Analyst), most I've met seem to come from operations or development depending on the industry.
My advice for all of us that weren't top 1% at elite colleges and thus don't qualify for the PM path straight out of school is:
- Folks that know and care about the Tech AND the Business are unicorns are valuable and unique. Many technical folks I've worked care more about the stack they work with than the business problems that will make the company money. Many functional folks don't care about the tech. Pick an industry and work in a dev or operational capacity while learning the other side of it and absorbing excessive amounts of domain knowledge.
- Put yourself out there (LinkedIn, Medium, HN, whatever) as a domain expert.
- It's easier to make a horizontal move: another role in the same industry or the same role in another industry.
- Not everyone will be happy as a PM. There can be a lot of pressure to deliver yet you often don't personally implement anything. Communication skills are more important than technical skills.
After working in the same industry for 2 years in an entry level operational capacity, I was headhunted by my current company who was looking to build out product in that area. Although I was very unmotivated during college and my degree in cognitive psychology is worth the paper it's printed on, I had programming experience and was self-learning on web development at the time. A combination of basic understanding of systems and software development, deep industry operational experience, and obvious enthusiasm for the job was enough to get hired.
While there are some direct paths to Product Management (often Business Analyst), most I've met seem to come from operations or development depending on the industry.
My advice for all of us that weren't top 1% at elite colleges and thus don't qualify for the PM path straight out of school is:
- Folks that know and care about the Tech AND the Business are unicorns are valuable and unique. Many technical folks I've worked care more about the stack they work with than the business problems that will make the company money. Many functional folks don't care about the tech. Pick an industry and work in a dev or operational capacity while learning the other side of it and absorbing excessive amounts of domain knowledge.
- Put yourself out there (LinkedIn, Medium, HN, whatever) as a domain expert.
- It's easier to make a horizontal move: another role in the same industry or the same role in another industry.
- Not everyone will be happy as a PM. There can be a lot of pressure to deliver yet you often don't personally implement anything. Communication skills are more important than technical skills.
Actually, there are "junior product" positions at many large tech companies. They're called "APM programs" (the A is for associate) and tend to hire new graduates with engineering backgrounds. Hires are rotated through multiple projects and usually given a lot of mentorship. I believe the first such program was created by Marissa Mayer at Google, and other companies later emulated it in an attempt to recapture its success. The current programs I know of are:
Google | Facebook | Uber | Yahoo | Twitter | Yelp | LinkedIn | IBM
There may be others that I haven't heard of, so feel free to respond with more. Google and Facebook are the big two; the others only accept single-digit candidates per year. Many of these programs are extremely new. (In fact, Twitter's is so new that it has no graduates yet, as far as I know).
Source: I'm a college senior with an engineering degree. I have applied to many of these positions.
Google | Facebook | Uber | Yahoo | Twitter | Yelp | LinkedIn | IBM
There may be others that I haven't heard of, so feel free to respond with more. Google and Facebook are the big two; the others only accept single-digit candidates per year. Many of these programs are extremely new. (In fact, Twitter's is so new that it has no graduates yet, as far as I know).
Source: I'm a college senior with an engineering degree. I have applied to many of these positions.
I started out as an engineer. But, I built tons of side projects and studied Product Management to hone my skills. Do lots of user testing and analytics. Show you can understand a user's problems and have empathy for the user. Practice solving those problems with simple, understandable UX. Then, take this ammunition and lobby hard to PM leaders. I put together a compelling presentation to a PM director at my corporate job and they gave me a chance with a PM "rotation." It's not the easiest of transitions, but you'll learn a ton. If you do well, they might put you in a full time entry level position. I took a pay cut. Make sure it's what you are passionate about. I miss engineering but love strategic problem solving and the magic that comes with PM. But overall, you have to be aggressive. Learn the skills and lobby hard. Go get it!
Director, Product at 500 person profitable non-startup company.
I got my BS in Cognitive Science and HCI. I initially worked at Cisco setting up a beta testing program for Linksys consumer products. I transitioned from there into UX design and moved to DIRECTV to do it full time. I quickly realized there that design was an idea factory to see what sticked with upper management, not necessarily users. Product management would be the happy medium where I could design a nice experience while also satisfying business & technical needs. I pursued my MBA and created my own PM internship at a Series A startup during the summer between my 2 years. I got more into entrepreneurship and declined some seed funding to go with a Head of Product position following B School. It was a flop within a couple months due to relationship issues with a hot headed boss. I then took an Associate Product Manager position and pushed back into doing my own startup. That failed so I got back into PM, promoted to Director within a year and hear I am.
A PM needs many skills but certain ones will get you in the door: 1. Analytics: Since you haven't developed a gut yet for the industry, you need to understand data & numbers. Metrics, visualizations, statistics, etc. This is especially important if you want to own P&L, get in front of management, etc.
2. Design intuition: What can be honed prior to getting into PM is knowing good design from bad design. Learn how to make critiques but also know what would work better than the current iteration.
3. Productivity & Organization: Project management is just a small piece of what's necessary. You need to have everything figured out, organized, and be able to answer questions of what's a priority, what's done, etc.
4. Hold your own: You need conviction and backbone to push new ideas and initiatives into an organization. You'll need to be armed with justification but also have confidence that it is in the user's best interest.
Best of luck!
I got my BS in Cognitive Science and HCI. I initially worked at Cisco setting up a beta testing program for Linksys consumer products. I transitioned from there into UX design and moved to DIRECTV to do it full time. I quickly realized there that design was an idea factory to see what sticked with upper management, not necessarily users. Product management would be the happy medium where I could design a nice experience while also satisfying business & technical needs. I pursued my MBA and created my own PM internship at a Series A startup during the summer between my 2 years. I got more into entrepreneurship and declined some seed funding to go with a Head of Product position following B School. It was a flop within a couple months due to relationship issues with a hot headed boss. I then took an Associate Product Manager position and pushed back into doing my own startup. That failed so I got back into PM, promoted to Director within a year and hear I am.
A PM needs many skills but certain ones will get you in the door: 1. Analytics: Since you haven't developed a gut yet for the industry, you need to understand data & numbers. Metrics, visualizations, statistics, etc. This is especially important if you want to own P&L, get in front of management, etc.
2. Design intuition: What can be honed prior to getting into PM is knowing good design from bad design. Learn how to make critiques but also know what would work better than the current iteration.
3. Productivity & Organization: Project management is just a small piece of what's necessary. You need to have everything figured out, organized, and be able to answer questions of what's a priority, what's done, etc.
4. Hold your own: You need conviction and backbone to push new ideas and initiatives into an organization. You'll need to be armed with justification but also have confidence that it is in the user's best interest.
Best of luck!
In my book, The Product Manager's Desk Reference (2e), the Introductory Chapter is titled: The Accidental Profession. Everyone comes to PM from other disciplines... can't get a degree in it.
Plus, the definition of Product Management varies... which it shouldn't. Product Management is the business management of products. Product managers own those businesses across their life cycles. They are responsible for harnessing market insights, formulating strategy, determining where to invest, overseeing development, ensuring products are introduced/released on time, and tracking financial and business contributions.
They need to earn credibility so they can influence others, think strategically, and have sufficient business and financial acumen.
In a nutshell, it's a CEO/GM "MINDSET" that helps product managers be great product managers.
Plus, the definition of Product Management varies... which it shouldn't. Product Management is the business management of products. Product managers own those businesses across their life cycles. They are responsible for harnessing market insights, formulating strategy, determining where to invest, overseeing development, ensuring products are introduced/released on time, and tracking financial and business contributions.
They need to earn credibility so they can influence others, think strategically, and have sufficient business and financial acumen.
In a nutshell, it's a CEO/GM "MINDSET" that helps product managers be great product managers.
I have a BS in computer science and a MS in human-computer interaction. Basically, my specialty is wearing many hats in order to get at the needs of the user. I started out as a junior dev, but always tried to get out in the field and talk to users. It was a natural shift to take on a product role.
Senior PM at [Open Source Enterprise Software Company]
Degree in EE --> Internship as Program Manager at Microsoft --> Moved into enterprise products --> Moved to smaller company for larger scope.
Unlike development, it's quite difficult to create small assignments for product managers that is not trivial except at large companies. A key skill in PM is being able to see the complete picture (i.e. Market, Industry, Company, Organization, Team, Person and the interactions between all these different groups) in order to make the right trade-offs for a product.
The best advice I got was from a panel done by Scott Wiltamuth (then PM director of VS) who mentioned that PM is an apprentice discipline. The only way to learn is by sitting and watching someone else who is very good at it and learn from them.
Degree in EE --> Internship as Program Manager at Microsoft --> Moved into enterprise products --> Moved to smaller company for larger scope.
Unlike development, it's quite difficult to create small assignments for product managers that is not trivial except at large companies. A key skill in PM is being able to see the complete picture (i.e. Market, Industry, Company, Organization, Team, Person and the interactions between all these different groups) in order to make the right trade-offs for a product.
The best advice I got was from a panel done by Scott Wiltamuth (then PM director of VS) who mentioned that PM is an apprentice discipline. The only way to learn is by sitting and watching someone else who is very good at it and learn from them.
I started off as a developer... but not a terribly good one. Got to know our product inside and out... and as the company grew my role transitioned into product owner sort of organically... I found that I was pretty good at writing requirements (at least avoiding some of the pitfalls that non-devs made when writing requirements), and running meetings, and communicating with a variety of teams in the organization (and nicely saying, "No," to a variety of teams) ... and it all evolved from there. I liked the work more since I got more praise at it than I ever got for doing dev work. 20 years later... I've done product / project / process / program... a bunch of P. Manager roles...
It helps to be interested in a lot of things. Understand enough about things at the 50,000 foot view level... Helps to listen to a lot of people -- and care about their success. Learn all you can about as much as you can. If you can't code a bit... you'll have a hard time communicating what you really want to the developers (there's just no way to write down every possible requirement in every ticket). Same goes for every other discipline... QA, UX research, DevOps, marketing, business development, etc... you want to know as much as you can about all of these things so you can build the right process and pick the right focus for your team and your audience.
* Product Managers: Who Are These 'Mini-CEOs' And What Do They Do? || http://thenextweb.com/insider/2013/10/12/product-managers-mi...
* How to Hire a Product Manager - The classic essay on the role of product management - Ken Norton || https://www.kennorton.com/essays/productmanager.html
* Agile Product Ownership in a Nutshell - YouTube || https://www.youtube.com/watch?v=502ILHjX9EE
It helps to be interested in a lot of things. Understand enough about things at the 50,000 foot view level... Helps to listen to a lot of people -- and care about their success. Learn all you can about as much as you can. If you can't code a bit... you'll have a hard time communicating what you really want to the developers (there's just no way to write down every possible requirement in every ticket). Same goes for every other discipline... QA, UX research, DevOps, marketing, business development, etc... you want to know as much as you can about all of these things so you can build the right process and pick the right focus for your team and your audience.
* Product Managers: Who Are These 'Mini-CEOs' And What Do They Do? || http://thenextweb.com/insider/2013/10/12/product-managers-mi...
* How to Hire a Product Manager - The classic essay on the role of product management - Ken Norton || https://www.kennorton.com/essays/productmanager.html
* Agile Product Ownership in a Nutshell - YouTube || https://www.youtube.com/watch?v=502ILHjX9EE
One key thing I did besides work as a developer and manager in the industry for decades: I took a class from Pragmatic Marketing. http://pragmaticmarketing.com/
PM @ Google, before that PM @ Twitter for 2 years. Before that CEO/Founder of a SaaS startup.
Did a BA in Anthropology & English. Learned to write, think clearly, and communicate effectively.
Moved to China, founded a company which failed but gave me the entrepreneurial bug and the realization that I didn't know nearly as much CS as I thought I did.
Went back to school, did a Bachelors of Computer Science w/ Math minor. Learned to think systematically & rigorously, how computers work, a bit of ML/algorithms/etc, and how to code.
Applied to Google APM program. Thought it would be an ideal job before founding a company. Didn't get in.
Founded a company with my best friend, who had a Masters in Computer Engineering and had worked in industry. Spent the first year coding everyday, all our first employees were engineers. Learned to write real software and work with an engineering team.
Transitioned into the CEO role in practice. This happened because my co-founder and I had very different motivations. He wanted to build great systems (and not have to go to meetings / talk to customers). I just wanted to do whatever was needed to move the business forward, I was equally happy coding or talking to investors / taking meetings. Learned (through multiple failings) how to think about markets, interview customers, how to motivate and lead, build realistic roadmaps, raise money, do sales.
After 5 years, sold my company as a 1st base hit exit. I had no problem getting mid-career PM interviews, despite having never been 'officially'a PM. Focused on big scale consumer because I wanted maximize my leverage/impact.
Junior positions? See todd_sherman's response (Hi Todd!).
Skills – well covered elsewhere. The short version is "Get the right things built & shipped." To do that, you need to know (1) what the right things are (user problems, strategy, markets, corporate politics, etc) and (2) get them built & shipped (working with eng & design, leadership, resourcing, more politics). It's harder than it sounds, there are many many more wrong things than right things (and many wrong things can sound pretty right).
I'm sure I'm biased, but I think founding a company is an ideal pre-PM curriculum. When big tech co's acquire companies, the CEOs almost always become PMs, for good reason. This knowledge changes the risk equation as a founder, being a PM at a great company is a pretty awesome backup plan.
Did a BA in Anthropology & English. Learned to write, think clearly, and communicate effectively.
Moved to China, founded a company which failed but gave me the entrepreneurial bug and the realization that I didn't know nearly as much CS as I thought I did.
Went back to school, did a Bachelors of Computer Science w/ Math minor. Learned to think systematically & rigorously, how computers work, a bit of ML/algorithms/etc, and how to code.
Applied to Google APM program. Thought it would be an ideal job before founding a company. Didn't get in.
Founded a company with my best friend, who had a Masters in Computer Engineering and had worked in industry. Spent the first year coding everyday, all our first employees were engineers. Learned to write real software and work with an engineering team.
Transitioned into the CEO role in practice. This happened because my co-founder and I had very different motivations. He wanted to build great systems (and not have to go to meetings / talk to customers). I just wanted to do whatever was needed to move the business forward, I was equally happy coding or talking to investors / taking meetings. Learned (through multiple failings) how to think about markets, interview customers, how to motivate and lead, build realistic roadmaps, raise money, do sales.
After 5 years, sold my company as a 1st base hit exit. I had no problem getting mid-career PM interviews, despite having never been 'officially'a PM. Focused on big scale consumer because I wanted maximize my leverage/impact.
Junior positions? See todd_sherman's response (Hi Todd!).
Skills – well covered elsewhere. The short version is "Get the right things built & shipped." To do that, you need to know (1) what the right things are (user problems, strategy, markets, corporate politics, etc) and (2) get them built & shipped (working with eng & design, leadership, resourcing, more politics). It's harder than it sounds, there are many many more wrong things than right things (and many wrong things can sound pretty right).
I'm sure I'm biased, but I think founding a company is an ideal pre-PM curriculum. When big tech co's acquire companies, the CEOs almost always become PMs, for good reason. This knowledge changes the risk equation as a founder, being a PM at a great company is a pretty awesome backup plan.
Hey!
I started as a trainer/implementation person- and ended up doing so at a startup. The CEO was the product manager when I started - but when the time came to make that into a full time role, I had a good grasp of the customers and what they wanted (due to being on the front lines) and I got the job. Product Managers can come from anywhere - get in the door as a support person and work your way up. The key is understanding what customers want.
Many companies have Product Analysts or Associate Product Manager positions that feed into Product Manager positions.
Product Management can be relentless. You need to know everything that is going everywhere, and react to it to accomplish your goals.
Many companies have Product Analysts or Associate Product Manager positions that feed into Product Manager positions.
Product Management can be relentless. You need to know everything that is going everywhere, and react to it to accomplish your goals.
Assuming we're talking about product managers for software/app products:
I'd say the "junior product" position is probably a frontend developer. You're making a lot of small decisions developing a frontend, and you develop a taste for it. Once you have taste, you really start contributing to the overall thought behind the product. That's when you become a reasonable hire as product manager.
As for me? Well, I was hired as a product manager after being what amounted to a "full stack" developer for years and years at a small (still smallish) startup. Having said that, it really ended up being much more of a project management role than anything else.
I'd say the "junior product" position is probably a frontend developer. You're making a lot of small decisions developing a frontend, and you develop a taste for it. Once you have taste, you really start contributing to the overall thought behind the product. That's when you become a reasonable hire as product manager.
As for me? Well, I was hired as a product manager after being what amounted to a "full stack" developer for years and years at a small (still smallish) startup. Having said that, it really ended up being much more of a project management role than anything else.
Product Manager @ IDXBroker (Real Estate Saas)
Background - Worked in IT/Systems Management for 10 years and eventually moved on to consulting on sites and webapps. Started as UI/UX Dev role at IDX and quickly moved into the Product Manager role. Communication is the biggest part of the job, with linking up projects and managing resources/timelines also taking up a lot of time. You're generally going to be the glue between Marketing/Sales/Support/Business so being knowledgable AND approachable are must have skills. The product is your baby and so you have a huge amount of responsibility on your shoulders. Vision and execution are on you.
Background - Worked in IT/Systems Management for 10 years and eventually moved on to consulting on sites and webapps. Started as UI/UX Dev role at IDX and quickly moved into the Product Manager role. Communication is the biggest part of the job, with linking up projects and managing resources/timelines also taking up a lot of time. You're generally going to be the glue between Marketing/Sales/Support/Business so being knowledgable AND approachable are must have skills. The product is your baby and so you have a huge amount of responsibility on your shoulders. Vision and execution are on you.
I've been a product manager for about 2 years, coming from a development background, I suggest getting as much technical background as possible and a nice helping of people skills.
It's been said before but the PM is mainly a servant and facilitator, and it helps a lot if you know what you're talking about (we have a PM here that confuses VPNs with DNS, doesn't know how to report bugs, etc.)
IMHO, getting to be a PM is mostly demonstrating that you're dependable in a lower level position and showing that you have enough knowledge/leadership skills to get the job done.
It's been said before but the PM is mainly a servant and facilitator, and it helps a lot if you know what you're talking about (we have a PM here that confuses VPNs with DNS, doesn't know how to report bugs, etc.)
IMHO, getting to be a PM is mostly demonstrating that you're dependable in a lower level position and showing that you have enough knowledge/leadership skills to get the job done.
PM at a startup.
I guess I could be considered a "junior PM" as I have less than a year of official PM experience. I started off as employee #2 in our US office. My main role was marketing but I worked closely with our designers and engineers throughout the years (giving design feedback, writing copy, etc.). I also led the effort of redesigning of our website, and worked directly with a designer and an engineer throughout that process. So our CEO and VP of Product knew what I was capable of. When the PM opportunity came up internally, I made the switch.
I guess I could be considered a "junior PM" as I have less than a year of official PM experience. I started off as employee #2 in our US office. My main role was marketing but I worked closely with our designers and engineers throughout the years (giving design feedback, writing copy, etc.). I also led the effort of redesigning of our website, and worked directly with a designer and an engineer throughout that process. So our CEO and VP of Product knew what I was capable of. When the PM opportunity came up internally, I made the switch.
I work for a software company in the product management and product space, and we do a ton of research on this.
We recently published the results from our annual survey of 150 product managers:
https://cdn2.hubspot.net/hubfs/429921/Content/2017%20PM%20In...
We’re also publishing a pretty surprising article in the next couple weeks about what separates product leaders from product managers.
P.S. We see plenty of "junior product" positions.
We recently published the results from our annual survey of 150 product managers:
https://cdn2.hubspot.net/hubfs/429921/Content/2017%20PM%20In...
We’re also publishing a pretty surprising article in the next couple weeks about what separates product leaders from product managers.
P.S. We see plenty of "junior product" positions.
What is the pretty surprising article have that will surprise all of us?
Almost every PM I've met has an odd/alternative background but the consistent traits I see are:
1. Curiosity
2. The ability to think in a structured/organized way
3. A clear understanding of users, their problems, and how to solve those problems
4. Ability to understand coworkers and motivate or influence without authority
I would argue that the above aspects can come from any discipline. I've recruited Pm's (via internal transfer) who worked in accounting/finance as well as one who worked a supply chain position.
Regarding my path, i also didn't follow a standard trajectory. I had been building websites (sometimes programing, sometimes writing content) with friends for a few years in college as a hobby. I stopped attending college and began a 4yr career as a professional gamer. During this time, I continued to work on side projects with friends, usually in an 'editor in chief' capacity for a small blog or website.
When my pro gaming stint ended (short answer: it was not a consistent enough income stream as most revenue came from tournaments), I was offered a job as community manager of one of the tournaments I competed in. They hired me because of my regular posts about the rules and games and felt I would be good at representing the community's needs. I went back to school (studying creative writing) and worked this remotely.
From here, a friend who i met via working as community manager recommended me from an open editor in chief position at a small (unfunded) startup. In my first meeting, they showed me the redesign they were working on and I asked a lot of questions about their thought process and why they did certain things that didn't make sense to me. The designers loved this feedback (they had never received anything actionable before) and we ended up meeting regularly. This company was acquired (small talent acquisition) and the CEO of the new company was excellent at mentoring people and quickly told me (based on what I was already doing) that I should be a PM.
In summary.. The best way to become a PM is to start doing it. Find side projects and contribute however you can (writing, coding, design, customer support, etc) and while you're there, ask lots of questions to try to deeply understand the product, the users, and the decisions that the organizers take.
Fundamentally you want to answer (or help them answer if they can't) three questions: 1. Why does this product exist in the world? 2. What does success look like? 3. How do we get there?
Happy to do a 20m call if you have further questions, my email is in my profile.
I would argue that the above aspects can come from any discipline. I've recruited Pm's (via internal transfer) who worked in accounting/finance as well as one who worked a supply chain position.
Regarding my path, i also didn't follow a standard trajectory. I had been building websites (sometimes programing, sometimes writing content) with friends for a few years in college as a hobby. I stopped attending college and began a 4yr career as a professional gamer. During this time, I continued to work on side projects with friends, usually in an 'editor in chief' capacity for a small blog or website.
When my pro gaming stint ended (short answer: it was not a consistent enough income stream as most revenue came from tournaments), I was offered a job as community manager of one of the tournaments I competed in. They hired me because of my regular posts about the rules and games and felt I would be good at representing the community's needs. I went back to school (studying creative writing) and worked this remotely.
From here, a friend who i met via working as community manager recommended me from an open editor in chief position at a small (unfunded) startup. In my first meeting, they showed me the redesign they were working on and I asked a lot of questions about their thought process and why they did certain things that didn't make sense to me. The designers loved this feedback (they had never received anything actionable before) and we ended up meeting regularly. This company was acquired (small talent acquisition) and the CEO of the new company was excellent at mentoring people and quickly told me (based on what I was already doing) that I should be a PM.
In summary.. The best way to become a PM is to start doing it. Find side projects and contribute however you can (writing, coding, design, customer support, etc) and while you're there, ask lots of questions to try to deeply understand the product, the users, and the decisions that the organizers take.
Fundamentally you want to answer (or help them answer if they can't) three questions: 1. Why does this product exist in the world? 2. What does success look like? 3. How do we get there?
Happy to do a 20m call if you have further questions, my email is in my profile.
> In summary.. The best way to become a PM is to start doing it.
This is great practical advice. If you're trying to cross over within a company, put yourself in the line of opportunities. Tell your boss to look out for new initiatives where you can contribute from the beginning. Try to get yourself invited to new meetings. Offer actionable advice on making current products better. And never neglect your day job when working on your side projects. Otherwise you'll be perceived as someone who dreams big but can't get things done.
This is great practical advice. If you're trying to cross over within a company, put yourself in the line of opportunities. Tell your boss to look out for new initiatives where you can contribute from the beginning. Try to get yourself invited to new meetings. Offer actionable advice on making current products better. And never neglect your day job when working on your side projects. Otherwise you'll be perceived as someone who dreams big but can't get things done.
Forgot to add - many larger companies offer a junior pm program to help people transition into a PM role. I work at oculus and we participate in Facebook's 'rotational pm (rpm)' program.
Applicants have little to no product experience and are sometimes right out of college or other times come from different fields or backgrounds. Once hired, rpm's rotate between a few teams and are assigned a full time PM mentor who works alongside their manager to set them up for success.
I believe Google has something similar as well.
Applicants have little to no product experience and are sometimes right out of college or other times come from different fields or backgrounds. Once hired, rpm's rotate between a few teams and are assigned a full time PM mentor who works alongside their manager to set them up for success.
I believe Google has something similar as well.
I've spent 3 years as an associate in a VC firm. I graduated in computer engineering. And I was invited by the CEO of a rapid growing company (www.inlocomedia.com) to be a product manager of their new Data products.
I think the tech background is important, but the most important thing is to be able to talk to all stakeholders. As a product manager you will have many interfaces with marketing, management, operations, biz dev, and your team (the engineers). You have to be able to communicate well with everybody and provide context and value.
I think the tech background is important, but the most important thing is to be able to talk to all stakeholders. As a product manager you will have many interfaces with marketing, management, operations, biz dev, and your team (the engineers). You have to be able to communicate well with everybody and provide context and value.
I previously worked in print design, web design, content management, and photography. I’d been paid to write, design, take photos, develop, teach, edit, manage projects and people, launch publications, improve content quality, and grow audiences. I was a user of the website I now work for before I was an employee. I was hired to run content but I was interested in every part of the organization and found myself speaking up about design and product while being a fierce defender of the user’s perspective. Product management is my dream job that I never even knew existed. It allows me to leverage my seemingly total mess of random skills in a focused and productive way. It presses all the right buttons in my brain and I love the challenges it brings me every day.
Product managers should have the following skills: 1. A strong grasp of the industry they operate in on a macro and micro level. What has been done? What hasn’t? Where is the industry going? What do we need to do to keep up with the competition? What can we do that blows past what anyone else is doing? 2. The ability to speak as a user or potential user. Do you actually use the product? Can you put yourself in a place to experience the same struggles and frustrations and your users? Can you see the perspectives of those who are currently unwilling to adopt your product? Can you wrangle all of this into a product roadmap optimized for maximum impact? 3. The ability to speak the language and gain the respect of everyone on the project team. Can you speak from a place of authority to a group of designers and developers looking for leadership? Can you spot holes in the user flows presented by your designers, understand the technical hurdles that your developers are telling you stand in the way of success, and call out product copy that feels off brand all at once as requests and problems come at you from every angle? 4. Above all: the ability to make decisions when no one else can or will. Product management is about decision making. When everyone has opposing ideas, when the data is inconclusive and doesn’t give you the magical clear path forward you hoped for, when everyone looks to you for what to do next, can you lead the way? When there’s no clear answer, can you set up the framework and tests necessary to get to one? When your organization can’t make decisions, it can’t build a coherent strategy, it can’t make bets on the future, and it can’t solve big problems. Can you take on that responsibility?
Product managers should have the following skills: 1. A strong grasp of the industry they operate in on a macro and micro level. What has been done? What hasn’t? Where is the industry going? What do we need to do to keep up with the competition? What can we do that blows past what anyone else is doing? 2. The ability to speak as a user or potential user. Do you actually use the product? Can you put yourself in a place to experience the same struggles and frustrations and your users? Can you see the perspectives of those who are currently unwilling to adopt your product? Can you wrangle all of this into a product roadmap optimized for maximum impact? 3. The ability to speak the language and gain the respect of everyone on the project team. Can you speak from a place of authority to a group of designers and developers looking for leadership? Can you spot holes in the user flows presented by your designers, understand the technical hurdles that your developers are telling you stand in the way of success, and call out product copy that feels off brand all at once as requests and problems come at you from every angle? 4. Above all: the ability to make decisions when no one else can or will. Product management is about decision making. When everyone has opposing ideas, when the data is inconclusive and doesn’t give you the magical clear path forward you hoped for, when everyone looks to you for what to do next, can you lead the way? When there’s no clear answer, can you set up the framework and tests necessary to get to one? When your organization can’t make decisions, it can’t build a coherent strategy, it can’t make bets on the future, and it can’t solve big problems. Can you take on that responsibility?
Companies are looking for experience managing a product across many projects. If you don't have that (which nobody does when they start out) show that you have determination to solve higher level problems then making software work. Did a product you worked on solve a real problem and how were you a part of solving it? Were you able to grow monthly active users or other metrics that a C-level can turn into profits for the business.
My career was like support engineer->developer->project manager->product manager at the same company. Every step forward was initiated by a "global manager". Amazingly every time I felt bored and looked for a new job, I received an email that said something like "would you like to take new responsibilities? Here is what we offer..". 15 years passed like that. I am not even sure if I can quit now.
PM at a small software company.
No technical background. Dropped into the role without any official role or responsibilities five years ago.
I contribute to pretty much every part of the business - strategy, hiring, sales, project management, support, testing, design and even some development.
I could describe my day-to-day as "keeping everyone happy".
If you agree that the overarching reason for a Product Managers existence is to 'Facilitate the growth of the business via influence and interaction with the various departments', then I'd say the skills required exist in a sort of circle..
People skills >> Business skills >> Technical skills >> People skills >> Business skills.. and so on.
People skills >> Business skills >> Technical skills >> People skills >> Business skills.. and so on.
> There aren't "junior product" positions.
I don't know much about this area, but I'm pretty sure there are companies with such positions. In particular, I've seen videos by Adobe with statements from people labelled with "junior product manager X" (X being one of their products). Not sure what carreer path brought them there though.
I don't know much about this area, but I'm pretty sure there are companies with such positions. In particular, I've seen videos by Adobe with statements from people labelled with "junior product manager X" (X being one of their products). Not sure what carreer path brought them there though.
Customer Experience/Support was my main background. It really helps to understand a product when you support it first hand. Even when I was a PM, I devoted some time listening to support calls. Next, I went into QA/QE which was also useful.
Skills:
- Be a problem solver and work-around thinker
- Know when to say no and to whom
- Be a UX minded person
- Do not over-rely on numbers/data
- Be humble
Skills:
- Be a problem solver and work-around thinker
- Know when to say no and to whom
- Be a UX minded person
- Do not over-rely on numbers/data
- Be humble
Head of Product @ Stormpath
It doesn't really matter where you start, as long as you can relate to the product and its customers. I've seen great PM from every beginning. My beginning was a normal comp sci background -> dev -> customer success manager (any support role is a great segway into product management role) -> PM. Having managed many PMs, it boils down to this:
Can you be an advocate for your customer for your product, regardless of intercompany demands?
Can you communicate your vision for what needs to be built effectively across the whole company?
Those are the two main skills that I try to distil for any PM that I hire. There is a 3rd which I call the auxiliary skill (these can be taught easily, hence auxiliary).
How do you validate your assumptions, remove cognitive biases to come to the best decision about the priority on what should be built when?
And a fourth, which comes down to background and personality:
Can you be a swiss army knife and help wherever the team needs you?
The product I currently manage is a developer tool, so taking a look at an example based on the 4 points:
1. Can you relate to developer pain points, market problems with identity, create great developer experience and understand where there are holes in the current product?
2. How can you use the tools at your disposal to communicate what we need to build to the engineering team, marketing, and executives. Technical and non-technical folks alike, even for a technical product that is sold to devs.
3. How can you manage feedback / signals from sales, developer evangelism, customer asks, and visionaries to create a roadmap
4. Demonstrate how you have needed to step out of your comfort zone to get the job done.
When interviewing, having a developer background is a must (but it is only a must because my product is currently catering to the developer persona), but replace a developer product with a dental product that is sold to dentists. That hiring manager is going to want someone that more than likely understands dentists and their pain points that the software is currently solving for. They could come from, office manager, dentist moving to software (it happens), someone from the insurance industry... you see the point.
Hope this helps, I'm always happy to help and advise. Snag my twitter handle from the profile and shoot me a DM.
It doesn't really matter where you start, as long as you can relate to the product and its customers. I've seen great PM from every beginning. My beginning was a normal comp sci background -> dev -> customer success manager (any support role is a great segway into product management role) -> PM. Having managed many PMs, it boils down to this:
Can you be an advocate for your customer for your product, regardless of intercompany demands?
Can you communicate your vision for what needs to be built effectively across the whole company?
Those are the two main skills that I try to distil for any PM that I hire. There is a 3rd which I call the auxiliary skill (these can be taught easily, hence auxiliary).
How do you validate your assumptions, remove cognitive biases to come to the best decision about the priority on what should be built when?
And a fourth, which comes down to background and personality:
Can you be a swiss army knife and help wherever the team needs you?
The product I currently manage is a developer tool, so taking a look at an example based on the 4 points:
1. Can you relate to developer pain points, market problems with identity, create great developer experience and understand where there are holes in the current product?
2. How can you use the tools at your disposal to communicate what we need to build to the engineering team, marketing, and executives. Technical and non-technical folks alike, even for a technical product that is sold to devs.
3. How can you manage feedback / signals from sales, developer evangelism, customer asks, and visionaries to create a roadmap
4. Demonstrate how you have needed to step out of your comfort zone to get the job done.
When interviewing, having a developer background is a must (but it is only a must because my product is currently catering to the developer persona), but replace a developer product with a dental product that is sold to dentists. That hiring manager is going to want someone that more than likely understands dentists and their pain points that the software is currently solving for. They could come from, office manager, dentist moving to software (it happens), someone from the insurance industry... you see the point.
Hope this helps, I'm always happy to help and advise. Snag my twitter handle from the profile and shoot me a DM.
Product Manager vs. Project Manager: https://www.mockplus.com/blog/post/the-project-manager-vs-pr...
Threads like this is why I keep checking HN. Thanks to the people who responded with in-depth answers.
I recommend reading "cracking the pm interview"
Then try to find a job either in product management or in a related field e.g. development, consulting, marketing, customer success (not QA or documentation)...
source: I'm a manager of PM (product management)
Then try to find a job either in product management or in a related field e.g. development, consulting, marketing, customer success (not QA or documentation)...
source: I'm a manager of PM (product management)
I've done a lot of product management without technically being one by title. I think one important skill is being able to have a good rapport with engineering. When that link is broken, a lot of tension arises.
Where it has always been confusing to me is what is difference between product manager and product marketing manager? It appears organizations views and expectations on this vary wildly as well.
Junior positions I think not, especially as a Product Manager (well depending the size of your structure) is supposed to have lots of contacts, all the time, even when he's overloaded with tasks.
I know I wasn't in the same role, just mentionning what I witnessed regarding Product Managers where I worked in the past.. Having been a Product Owner for a couple of years in a 10k+ employees international company, just to name a few guys you need to meet regularly for the sake of your product, from makers to users :
Developpers teams, QA teams, Product Support Teams, Marketing teams, Finance teams, Sales teams (Global, Regional), Delivery teams (Global, Regional), Training teams (See a trend here?), Customers (from time to time, not counting support escalations).
Out of these exchanges you get your product needs and issues which you need to rationalise, plan and translate into features and fixes, plan a macro and micro roadmap including slightly-expected hotfixes, service packs, long term roadmap (to give your customers a sense of what's coming - up to 5y forecast sometimes), adding also various compliance rules on top of this (depending the market) and a frosting made of turn over rates plus international culture complexity.
Of course what I'm mentionning is not the whole world, but as far as I can tell it's a good picture of what you can expect from someone doing decent international product management.
Therefore, a junior Product Manager would be pretty much difficult to pull, unless you're hiring people who had the opportunity to cross the intellectual and business bridges (consumer/producer/user/support) a couple of times in their carreer (imagine yourself drafting your new product roadmap while travelling a plane to show up on site on a Friday in a customer's office to defend your product against a missing/crippling feature and try to propose a mitigation plan with the help of the local delivery team).
A Product Manager is in a sense a one man band, half Project Manager, half Architect, Salesman, Support Manager, Training manager, end user, customer, etc.
So, Junior without someone to back you up, I don't think so. Junior without having some experience of the Trenches, hardly, as you can easily be reckless toward the teams mentionned above and also miss some red flags ("ivory tower" syndrome).
If you find such an opportunity, be wary on the context and the expected work. This role can be more stressing and alienating than being a Project Manager because you are supposed to represent a Product in any aspect of it.
I know I wasn't in the same role, just mentionning what I witnessed regarding Product Managers where I worked in the past.. Having been a Product Owner for a couple of years in a 10k+ employees international company, just to name a few guys you need to meet regularly for the sake of your product, from makers to users :
Developpers teams, QA teams, Product Support Teams, Marketing teams, Finance teams, Sales teams (Global, Regional), Delivery teams (Global, Regional), Training teams (See a trend here?), Customers (from time to time, not counting support escalations).
Out of these exchanges you get your product needs and issues which you need to rationalise, plan and translate into features and fixes, plan a macro and micro roadmap including slightly-expected hotfixes, service packs, long term roadmap (to give your customers a sense of what's coming - up to 5y forecast sometimes), adding also various compliance rules on top of this (depending the market) and a frosting made of turn over rates plus international culture complexity.
Of course what I'm mentionning is not the whole world, but as far as I can tell it's a good picture of what you can expect from someone doing decent international product management.
Therefore, a junior Product Manager would be pretty much difficult to pull, unless you're hiring people who had the opportunity to cross the intellectual and business bridges (consumer/producer/user/support) a couple of times in their carreer (imagine yourself drafting your new product roadmap while travelling a plane to show up on site on a Friday in a customer's office to defend your product against a missing/crippling feature and try to propose a mitigation plan with the help of the local delivery team).
A Product Manager is in a sense a one man band, half Project Manager, half Architect, Salesman, Support Manager, Training manager, end user, customer, etc.
So, Junior without someone to back you up, I don't think so. Junior without having some experience of the Trenches, hardly, as you can easily be reckless toward the teams mentionned above and also miss some red flags ("ivory tower" syndrome).
If you find such an opportunity, be wary on the context and the expected work. This role can be more stressing and alienating than being a Project Manager because you are supposed to represent a Product in any aspect of it.
As an Associate PM moving into full ownership of a product i.e. full PM role, this is the most accurate description of the job I've seen yet. I like to describe the job as sitting in between the cross functional areas (Marketing, Sales, Dev, Exec/Management, Finance, and a whole lot of more logistical groups) to: 1. Own and sculpt the product roadmap and vision by working across the functional groups and 2. Keep everyone on track for the goal and vision of the product. It means supporting sales, leading roadmap discussions, haggling with development, defending development from Sales, using Sales as an information source to go to Marketing, dictating a plan to Marketing, and making sure it all aligns with your vision for the product. Above all, it's owning the P/L and being on the hook when something good or bad happens.
That said, I've seen PM roles differ a lot between companies, culture and products, such that a cloud-startup product PM may have a VERY different role than an on-premise software enterprise PM. For example, I have minimal development experience but have yet to see it as a serious impediment to working with my team.
Glad to see that my understanding was correct, also congratulations on the new role :)
If I may give you one huge hint on your product's SWOT at least functionally speaking and especially in a global market: Ask your delivery teams, basically they're your eyes and ears on the harsh reality of the trenches.
After being a Product Owner I became a Global Delivery Consultant, and you can't imagine how much insight you get from the guys if you find the right mean.
Personally the best approach I took was a give and take quarterly worldwide meeting with the delivery experts and their top management to list the good the bad and the ugly from their own perspective (in any aspect of the product) while product management was providing insights on what was coming and a light update on the looks of the ongoing development schedule.
I can guarantee you that 3 Regional Delivery Heads telling you that feature XXX must be reworked is invaluable info and something you can't get from sales, support teams or even your own feeling. Added bonus: They will provide you with realistic business scenarios and expected behaviors and would be interested in taking part of the validation process for you.
Likewise, delivery guys will be more relaxed as they will be aware of the development fitness ahead of the official schedule and therefore won't sale features at risk (they're in projects all the time, they have to deal with the unexpected on a daily basis).
Because Delivery Teams are the closest to the product they are the first ones to proof it, support it and also bridge all the gaps for your customers. The rest is only paperwork and planning.
If I may give you one huge hint on your product's SWOT at least functionally speaking and especially in a global market: Ask your delivery teams, basically they're your eyes and ears on the harsh reality of the trenches.
After being a Product Owner I became a Global Delivery Consultant, and you can't imagine how much insight you get from the guys if you find the right mean.
Personally the best approach I took was a give and take quarterly worldwide meeting with the delivery experts and their top management to list the good the bad and the ugly from their own perspective (in any aspect of the product) while product management was providing insights on what was coming and a light update on the looks of the ongoing development schedule.
I can guarantee you that 3 Regional Delivery Heads telling you that feature XXX must be reworked is invaluable info and something you can't get from sales, support teams or even your own feeling. Added bonus: They will provide you with realistic business scenarios and expected behaviors and would be interested in taking part of the validation process for you.
Likewise, delivery guys will be more relaxed as they will be aware of the development fitness ahead of the official schedule and therefore won't sale features at risk (they're in projects all the time, they have to deal with the unexpected on a daily basis).
Because Delivery Teams are the closest to the product they are the first ones to proof it, support it and also bridge all the gaps for your customers. The rest is only paperwork and planning.
Thanks for the advice, really appreciate the guidance. I hadn't thought too much of Delivery as a source of feedback, but given what you mentioned I see real value in doing so.
Those of you who are Platform Product Managers, can you talk about how it is different from traditional product management and the additional complexity involved?
Hey, just curious where you live? My consulting company does product management consulting, and I get feeds on PM jobs automagically. Anyway, here in the greater Toronto area, there are junior(ish) marketing positions labelled as "Product Manager" fairly regularly.
What I want to know is this: where does the "authority" of this subject come from? Like, at what point do things like the title of "PM", become authority?
Is it schools? Is it Harvard? I mean, seriously .. wtf..
Is it schools? Is it Harvard? I mean, seriously .. wtf..
Context: Was product guy at Google (built a few cloud products, did some work in the open source ecosystem), now CEO of a startup.
Background: I don't think I picked product management, it sort of picked me. When I was a really junior engineer I worked in a small team environment with much more senior engineers. We didn't have product management support, so someone needed to talk to the customer and figure out what they needed, and then later have the hard conversation when we were slipping our date. That ended up being me. Someone needed to document what we were doing, that was me. At the end of the day when we had little management support, someone had to represent the needs of the team and hold the team together during an aggressive corporate downsizing. The team looked to me to do that. I sort of drifted into this role without ever being asked to do it. I loved coding, but turns out I liked solving business problems just as much. My path to proper product management went through program management at Microsoft which was a bit of a half-way house. Good customer passion but more focused on execution than on the health of the business.
This doesn't directly answer your question, but I hope is helpful: what are the attributes I have seen of successful PMs? * Have good technical instincts. You don't necessarily have to code well but you need to smell credible to engineers and not have them flip the bozo bit on you. I watched a product guy argue that we should figure out how to reduce latency between global data centers and then someone kindly point out that speed of light was the problem at hand, and we really couldn't do much about it. Don't be that guy, you will never come back from that point. * Champion the customer. Product managers have to really 'get' their product deeply, understand it, use it, live with it. They need to be able to see it they way a customer sees it and represent the hiezen-customer to the team. The primary work product of the PM is the PRD (product requirements document) and the customer should shine through. * Own your business. It isn't enough to build neat technology, that people love, but if no one knows about it or you can't sell it you are wasting your time. Know your sales people, know your marketing strategy, understand the pricing model. Make sure they all get what the product does and is good for. * Be the janitor before you try to be the CEO. There are a million things a team needs to do. The product manager needs to fill the gaps. Win by doing the things the engineers can't or don't want to do, but don't 'wall paper' over problems with the team structure. Remember however that doing a gap job well indefinitely gets in the way of creating high functioning teams. You need to work your way out of a gap filling job. * Knowledge is currency. To lead, you have to have something and see something the engineers don't. Understand your competition, use their products, speak to a lot of customers, bring that knowledge back to the team and they will start to trust you. * Stay out of execution: you are not a project manager. The eng function should not be babies, they need to hire their own project managers to run their scrums, organize execution, etc. If things go well for your product you are going to be talking to customers, negotiating partnerships, etc just as the team starts to hit an inflection curve in execution, you can't afford to be trapped in the office running their processes.
Hope that helps.
Background: I don't think I picked product management, it sort of picked me. When I was a really junior engineer I worked in a small team environment with much more senior engineers. We didn't have product management support, so someone needed to talk to the customer and figure out what they needed, and then later have the hard conversation when we were slipping our date. That ended up being me. Someone needed to document what we were doing, that was me. At the end of the day when we had little management support, someone had to represent the needs of the team and hold the team together during an aggressive corporate downsizing. The team looked to me to do that. I sort of drifted into this role without ever being asked to do it. I loved coding, but turns out I liked solving business problems just as much. My path to proper product management went through program management at Microsoft which was a bit of a half-way house. Good customer passion but more focused on execution than on the health of the business.
This doesn't directly answer your question, but I hope is helpful: what are the attributes I have seen of successful PMs? * Have good technical instincts. You don't necessarily have to code well but you need to smell credible to engineers and not have them flip the bozo bit on you. I watched a product guy argue that we should figure out how to reduce latency between global data centers and then someone kindly point out that speed of light was the problem at hand, and we really couldn't do much about it. Don't be that guy, you will never come back from that point. * Champion the customer. Product managers have to really 'get' their product deeply, understand it, use it, live with it. They need to be able to see it they way a customer sees it and represent the hiezen-customer to the team. The primary work product of the PM is the PRD (product requirements document) and the customer should shine through. * Own your business. It isn't enough to build neat technology, that people love, but if no one knows about it or you can't sell it you are wasting your time. Know your sales people, know your marketing strategy, understand the pricing model. Make sure they all get what the product does and is good for. * Be the janitor before you try to be the CEO. There are a million things a team needs to do. The product manager needs to fill the gaps. Win by doing the things the engineers can't or don't want to do, but don't 'wall paper' over problems with the team structure. Remember however that doing a gap job well indefinitely gets in the way of creating high functioning teams. You need to work your way out of a gap filling job. * Knowledge is currency. To lead, you have to have something and see something the engineers don't. Understand your competition, use their products, speak to a lot of customers, bring that knowledge back to the team and they will start to trust you. * Stay out of execution: you are not a project manager. The eng function should not be babies, they need to hire their own project managers to run their scrums, organize execution, etc. If things go well for your product you are going to be talking to customers, negotiating partnerships, etc just as the team starts to hit an inflection curve in execution, you can't afford to be trapped in the office running their processes.
Hope that helps.
Omada Health, for one, hires junior PMs.
[deleted]
Currently PM on Firefox, formerly PM at NPR Digital and other past companies. Breaking in to PM is hard because it's such a squishy a role, and therefore hard for hiring directors to know they’re getting someone who can deliver. There's general agreement on what engineers, UX, analysts do (and how to screen them in hiring). Companies hiring for PM want something harder to quantify: people with a demonstrated track record of getting things done. The best way to ensure that is to 1. hire an internal candidate in another role with a demonstrated track record, 2. Hire someone who was a successful PM elsewhere. Some companies (or some roles) specifically look for MBAs in roles that require more market or pricing analysis.
Breaking in as an MBA is one way for positions that prefer it. The other, more common way is to come into PM from another role. I was a mediocre developer, but a great generalist. I bounced around a lot of ENG roles and shipped a lot of stuff. I was deeply interested in how things got used by real people. I went to research. My first true PM role at a dotcom had a job title of "Producer" (a lot of folks came from media and imported the title). I worked for a Fortune 500 CMO and watched every aspect of the consumer experience. I've come to really really love the role.
My .02 on how the role should work: PM is about service. You are in service to your team, to your execs, as you build for the user. You lead the process of defining the product but you also carry water and do whatever it takes to ship. You carry the narrative and the vision for the team not because wrote it (sometimes you do), not because you're a visionary (sometimes you are). You carry it because as a practical matter, you are the only person on the team who can, because everyone else is building and in the weeds. You're the one person with the luxury to look around. You are the voice of whomever isn't in the room. The team gets the credit when you succeed, but you get the blame when you fail. This “single, wringable neck" philosophy hasn’t been the official policy at places I’ve worked, but it keeps one humble. Especially since as a PM you will mostly rely on soft-power, which is the most powerful kind if you can convince your teams and execs to trust and follow you.
(EDIT: adding a few soft-skills )
Communication: the most important PM skill. You'll write a ton of briefs. You must to be clear. You also need to be good at verbal communication. You're a storyteller, you'll pitch and ask to be greenlit. You have to fight for resources or to keep your project alive. You need to get ahead of bad news and also remember to trumpet your team's successes.
Empathy: it goes with the service mentality. The user doesn't live in Silicon Valley, they barely understand how their PC/phone works. They're important, they're human, and they have needs. You also need to be empathetic to your teammates, if you want the most out of them.
Discipline: PM's generally overindex on blue-sky thinking, may struggle with discipline. You often have to kill your baby to ship on time.
Breaking in as an MBA is one way for positions that prefer it. The other, more common way is to come into PM from another role. I was a mediocre developer, but a great generalist. I bounced around a lot of ENG roles and shipped a lot of stuff. I was deeply interested in how things got used by real people. I went to research. My first true PM role at a dotcom had a job title of "Producer" (a lot of folks came from media and imported the title). I worked for a Fortune 500 CMO and watched every aspect of the consumer experience. I've come to really really love the role.
My .02 on how the role should work: PM is about service. You are in service to your team, to your execs, as you build for the user. You lead the process of defining the product but you also carry water and do whatever it takes to ship. You carry the narrative and the vision for the team not because wrote it (sometimes you do), not because you're a visionary (sometimes you are). You carry it because as a practical matter, you are the only person on the team who can, because everyone else is building and in the weeds. You're the one person with the luxury to look around. You are the voice of whomever isn't in the room. The team gets the credit when you succeed, but you get the blame when you fail. This “single, wringable neck" philosophy hasn’t been the official policy at places I’ve worked, but it keeps one humble. Especially since as a PM you will mostly rely on soft-power, which is the most powerful kind if you can convince your teams and execs to trust and follow you.
(EDIT: adding a few soft-skills )
Communication: the most important PM skill. You'll write a ton of briefs. You must to be clear. You also need to be good at verbal communication. You're a storyteller, you'll pitch and ask to be greenlit. You have to fight for resources or to keep your project alive. You need to get ahead of bad news and also remember to trumpet your team's successes.
Empathy: it goes with the service mentality. The user doesn't live in Silicon Valley, they barely understand how their PC/phone works. They're important, they're human, and they have needs. You also need to be empathetic to your teammates, if you want the most out of them.
Discipline: PM's generally overindex on blue-sky thinking, may struggle with discipline. You often have to kill your baby to ship on time.
PM @ Canonical, I'm responsible for the Ubuntu Operating System.
Great thread! Your responses have taught me quite a bit about our industry!
My background: * I earned a B.S. from Texas A&M University in Computer Engineering and Mathematics (2001).
* After an internship, I joined IBM's Linux Technology Center in Austin, Texas -- a key part of IBM's billion dollar bet on Linux, working mostly on security technologies (including eCryptfs, still co-maintaining), and eventually becoming an IBM Master Inventor creating 75 patents, which I mostly disavow, except for QWERsive (aka Swype) which I still love :-)
* I spent one of those years for IBM, staffed on site at Red Hat in Boston (2005), building bridges between IBM's strategic initiatives and Red Hat's Linux distribution. This was 100% travel, somewhat lonely work, "in the field", but extremely formative in understanding the integral relationship between "kickass open source engineering", and "meeting business objectives". I learned, "never turn down a combat mission". Field experience is super rewarding.
* After 7+ years at IBM, I joined Canonical in (February 2008), at the formation of the engineering team which created The Ubuntu Server. Canonical was less than 100 people at the time, and we didn't have health care insurance or a 401(k) plan. Everyone worked from home; it was a scary, fun, exciting, thrilling time, no doubt! Besides helping bring Ubuntu into the public and private cloud, I also got to create some really cool technology, like Ubuntu's Encrypted Home Directories, Byobu, and a handful of other open source utilities. The lesson here was how important it is to get useful code into the hands of as many people as possible and then iterate quickly!
* I resisted moving into an engineering management role for way too long, but eventually did, and loved it! I came to learn that managing software engineers is fundamentally an extension of hacking code all by yourself, except your colleagues are your functions and libraries and compiliers and monitors and IDEs and test suites and so on. It's amazing how much more a well run team can accomplish, than a single lone engineer.
* I left Canonical after 4 years in (November 2011) to become the CTO of a venture funded startup called Gazzang. Gazzang's key technology (encryption of big data for health care companies) was largely based on the eCryptfs encrypted filesystem and utilities that I had co-authored and co-maintained for several years. Let me tell you, that it's amazing when a hobby, or an open source project that you enjoy hacking on, presents job opportunities. The wonder of open source. Your github/launchpad/stackexchange is your resume. I designed and implemented a key manager for Gazzang, which was eventually acquired by Cloudera.
* And finally, that brings me to product management... In July of 2013, I re-joined Canonical, reporting directly to the head of product management, Canonical's own founder/owner/billioniare/afronaut-space-tourist, Mark Shuttleworth, who invited me back to Canonical to lead product and strategy around Ubuntu itself, and design how Ubuntu fits into the world of containers (Kubernetes, Docker, LXD), cloud (AWS, Google, Azure, OpenStack, baremetal) all the way to the world of connected devices and IoT.
Product Management, for me, sits in the cross-section of engineering, sales, and marketing. I'll describe, in my opinion, a Product Manager's must-have skills in this way:
* 8am, from your hotel room, join a conference call with a journalist, explaining the intracasies of a press release announcing a new product offering
* 9am, lead a video conference with your engineering developers, diving into a shared screen session command line environment, looking at code and design, sharing insight from your experience in the field
* 10am, mic up and take the stage to deliver a conference presentation (keynote, if you're lucky) where you live demo some crazy risky beta features that probably won't quite work perfectly, in which case you recover gracefully and confidently move on
* 11am, spend some time with really sharp people, after your talk, where you answer the really tough questions some people were polite enough not to assail you with on the keynote stage
* Noon, lunch with the bizdev director of a collaborator/competitor in your market, and negiotate a partnership that works for both of you, send your 3-key asks by email from your phone before the end of the meeting
* 1pm, help your sales VP in the big meeting she scheduled for you, with the CTO of a Fortune 500 company who literally wrote the book on Internet Security, and sell them your encryption product (true story)
* 2pm, interview a potential new-hire, this particularly critical in a startup -- A players hire A players, while B players hire C players
* 3pm, write a thoughtful blog post, with unique insight on a real problem, demonstrating both the "how" and "why" around a solution, in well-written English, with a catchy title and clean graphics (demos, examples, etc)
* 4pm, create a slide deck that your sales engineering team uses to sell the new product you briefed the journalist on earlier today (should have been done weeks ago, but hey....)
* 5pm, competitively analyze the competitor's product in your space, actually using their product (or browsing their code) and document your findings and share with your team
* Flight home, hack on some code from your ~/ideas/* directory, that you've noodling over all week. Critically, get it into some minimally working state, by the end of the flight, or else you'll never come back to it
Hope that helps.
Cheers!
@dustinkirkland
Great thread! Your responses have taught me quite a bit about our industry!
My background: * I earned a B.S. from Texas A&M University in Computer Engineering and Mathematics (2001).
* After an internship, I joined IBM's Linux Technology Center in Austin, Texas -- a key part of IBM's billion dollar bet on Linux, working mostly on security technologies (including eCryptfs, still co-maintaining), and eventually becoming an IBM Master Inventor creating 75 patents, which I mostly disavow, except for QWERsive (aka Swype) which I still love :-)
* I spent one of those years for IBM, staffed on site at Red Hat in Boston (2005), building bridges between IBM's strategic initiatives and Red Hat's Linux distribution. This was 100% travel, somewhat lonely work, "in the field", but extremely formative in understanding the integral relationship between "kickass open source engineering", and "meeting business objectives". I learned, "never turn down a combat mission". Field experience is super rewarding.
* After 7+ years at IBM, I joined Canonical in (February 2008), at the formation of the engineering team which created The Ubuntu Server. Canonical was less than 100 people at the time, and we didn't have health care insurance or a 401(k) plan. Everyone worked from home; it was a scary, fun, exciting, thrilling time, no doubt! Besides helping bring Ubuntu into the public and private cloud, I also got to create some really cool technology, like Ubuntu's Encrypted Home Directories, Byobu, and a handful of other open source utilities. The lesson here was how important it is to get useful code into the hands of as many people as possible and then iterate quickly!
* I resisted moving into an engineering management role for way too long, but eventually did, and loved it! I came to learn that managing software engineers is fundamentally an extension of hacking code all by yourself, except your colleagues are your functions and libraries and compiliers and monitors and IDEs and test suites and so on. It's amazing how much more a well run team can accomplish, than a single lone engineer.
* I left Canonical after 4 years in (November 2011) to become the CTO of a venture funded startup called Gazzang. Gazzang's key technology (encryption of big data for health care companies) was largely based on the eCryptfs encrypted filesystem and utilities that I had co-authored and co-maintained for several years. Let me tell you, that it's amazing when a hobby, or an open source project that you enjoy hacking on, presents job opportunities. The wonder of open source. Your github/launchpad/stackexchange is your resume. I designed and implemented a key manager for Gazzang, which was eventually acquired by Cloudera.
* And finally, that brings me to product management... In July of 2013, I re-joined Canonical, reporting directly to the head of product management, Canonical's own founder/owner/billioniare/afronaut-space-tourist, Mark Shuttleworth, who invited me back to Canonical to lead product and strategy around Ubuntu itself, and design how Ubuntu fits into the world of containers (Kubernetes, Docker, LXD), cloud (AWS, Google, Azure, OpenStack, baremetal) all the way to the world of connected devices and IoT.
Product Management, for me, sits in the cross-section of engineering, sales, and marketing. I'll describe, in my opinion, a Product Manager's must-have skills in this way:
* 8am, from your hotel room, join a conference call with a journalist, explaining the intracasies of a press release announcing a new product offering
* 9am, lead a video conference with your engineering developers, diving into a shared screen session command line environment, looking at code and design, sharing insight from your experience in the field
* 10am, mic up and take the stage to deliver a conference presentation (keynote, if you're lucky) where you live demo some crazy risky beta features that probably won't quite work perfectly, in which case you recover gracefully and confidently move on
* 11am, spend some time with really sharp people, after your talk, where you answer the really tough questions some people were polite enough not to assail you with on the keynote stage
* Noon, lunch with the bizdev director of a collaborator/competitor in your market, and negiotate a partnership that works for both of you, send your 3-key asks by email from your phone before the end of the meeting
* 1pm, help your sales VP in the big meeting she scheduled for you, with the CTO of a Fortune 500 company who literally wrote the book on Internet Security, and sell them your encryption product (true story)
* 2pm, interview a potential new-hire, this particularly critical in a startup -- A players hire A players, while B players hire C players
* 3pm, write a thoughtful blog post, with unique insight on a real problem, demonstrating both the "how" and "why" around a solution, in well-written English, with a catchy title and clean graphics (demos, examples, etc)
* 4pm, create a slide deck that your sales engineering team uses to sell the new product you briefed the journalist on earlier today (should have been done weeks ago, but hey....)
* 5pm, competitively analyze the competitor's product in your space, actually using their product (or browsing their code) and document your findings and share with your team
* Flight home, hack on some code from your ~/ideas/* directory, that you've noodling over all week. Critically, get it into some minimally working state, by the end of the flight, or else you'll never come back to it
Hope that helps.
Cheers!
@dustinkirkland
I'm not a Product Manager, but my spouse is (she would say Product Owner). Here's how she got to it.
In the 1990s, she graduated with a MA in Chinese Pedagogy to go with her BA in Art/Chinese Civ, and taught college for a couple of years. Terrible job, terrible pay. Eventually, there was a state budget hiccup and both of her jobs at two different schools disappeared the same day. So we moved to a bigger city (Minneapolis). Back then, anyone who could figure out which end of the mouse pointed up could get an IT job, so she got on as a tech writer for an airline.
9/11 killed her airline job, so she moved on to an e-commerce dotcom that happened to survive and thrive, moving through many different roles there. She went from tech writing to business analyst to project management etc, and eventually wound up in product ownership. After 13 years there, the company was bought out, and she (along with most of the other old-timers) were laid off.
When that happened, what she had going was deep domain expertise in a very narrow field - international e-commerce, mostly payments processing. Around here, there are just a handful of employers who need that, but those who need it really need it. After some months of searching, she was picked up by another local company, and she's happy as a clam now handling internal payment products for a company in another line of business (online testing) that has diverse payment requirements and an international presence.
Lessons learned... first, she describes her job as a translator who speaks various forms of geek. She's not a programmer, and not an accountant, but she understands both well enough to translate between them, so the programmers understand what the accountants actually need, and the accountants understand what the programmers can actually deliver. That master's degree in language pedagogy was actually useful!
Next, she has specific domain knowledge. She knows her field at a shocking level of detail. If you need someone who can explain how refunds for online payments work in Germany, she can! (German law is unusual and troublesome to code around.) She understands the industry, understands the market, and understands the customer. This isn't something that can be learned in college! It's the result of over 15 years in a specific field, in diverse roles.
She has worked her way up through jobs of increasing responsibility, and she worked in a business that grew rapidly for a long time. It gave her a lot of opportunities that might not happen in a more static company, or job-hopping across companies (which tends to make your skills generic).
And finally, she's learned to do budgeting and project planning in a macro rather than micro sense. She plans things in terms of months or years, as opposed to the day-to-day focus of a project manager.
But yeah... domain expertise. There is no substitute for that. Learn intimate details of a specific thing that is valuable.
In the 1990s, she graduated with a MA in Chinese Pedagogy to go with her BA in Art/Chinese Civ, and taught college for a couple of years. Terrible job, terrible pay. Eventually, there was a state budget hiccup and both of her jobs at two different schools disappeared the same day. So we moved to a bigger city (Minneapolis). Back then, anyone who could figure out which end of the mouse pointed up could get an IT job, so she got on as a tech writer for an airline.
9/11 killed her airline job, so she moved on to an e-commerce dotcom that happened to survive and thrive, moving through many different roles there. She went from tech writing to business analyst to project management etc, and eventually wound up in product ownership. After 13 years there, the company was bought out, and she (along with most of the other old-timers) were laid off.
When that happened, what she had going was deep domain expertise in a very narrow field - international e-commerce, mostly payments processing. Around here, there are just a handful of employers who need that, but those who need it really need it. After some months of searching, she was picked up by another local company, and she's happy as a clam now handling internal payment products for a company in another line of business (online testing) that has diverse payment requirements and an international presence.
Lessons learned... first, she describes her job as a translator who speaks various forms of geek. She's not a programmer, and not an accountant, but she understands both well enough to translate between them, so the programmers understand what the accountants actually need, and the accountants understand what the programmers can actually deliver. That master's degree in language pedagogy was actually useful!
Next, she has specific domain knowledge. She knows her field at a shocking level of detail. If you need someone who can explain how refunds for online payments work in Germany, she can! (German law is unusual and troublesome to code around.) She understands the industry, understands the market, and understands the customer. This isn't something that can be learned in college! It's the result of over 15 years in a specific field, in diverse roles.
She has worked her way up through jobs of increasing responsibility, and she worked in a business that grew rapidly for a long time. It gave her a lot of opportunities that might not happen in a more static company, or job-hopping across companies (which tends to make your skills generic).
And finally, she's learned to do budgeting and project planning in a macro rather than micro sense. She plans things in terms of months or years, as opposed to the day-to-day focus of a project manager.
But yeah... domain expertise. There is no substitute for that. Learn intimate details of a specific thing that is valuable.
[deleted]
I'm not a product manager. From my experience there are 2 types of product managers, and people got into these 2 types in 2 different way.
1. Former project manager gets product manager title as a symbolic promotion
2. A marketing guy simply begins calling himself as one. Well, marketing guys like to change their titles to whatever position is now trendy.
On the 1st type: no problem with those. A good project manager always knows what the project is about, so he knows the product by default even if managing product features is outside his ordination.
1. Former project manager gets product manager title as a symbolic promotion
2. A marketing guy simply begins calling himself as one. Well, marketing guys like to change their titles to whatever position is now trendy.
On the 1st type: no problem with those. A good project manager always knows what the project is about, so he knows the product by default even if managing product features is outside his ordination.