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.
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.
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.
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.
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).
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)...
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'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'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).
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.
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 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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?
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?
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
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.
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.
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.
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.
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
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.
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.
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 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.
119 comments
[ 4.8 ms ] story [ 290 ms ] threadKey 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.
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.
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.
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.
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)...
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.
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).
hehe, been there... It feels like there must be some structured way to learn on processes, techniques, etc... but there's none :p
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 would like to talk with you about getting into PM as a soon-to-be graduate.
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
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.
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.
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.
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.
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.
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.
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.
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!
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'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.
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
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.
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.
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.
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 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.