3 ms·

I go to Wharton, and can weigh in from an inside perspective. There's a lot of interest for tech generally, and PM role is probably the most coveted one. This i

I go to Wharton, and can weigh in from an inside perspective. There's a lot of interest for tech generally, and PM role is probably the most coveted one. This is because most companies favor people with a background in technology (or at the very least a passion for technology). You might be able to get a job/internship in a tech company in Ops, BizDev, Corporate Strategy or Finance with a whole lot of background in tech, but PM roles definitely require one.

stvswn 11y ago
Also went to Wharton, and I'm a PM. My background was only a CS minor as an undergrad (8 years ago) and that I taught myself Rails in order to attempt a startup. This demonstrated a propensity for software but is completely useless practically. I've learned almost everything on the job. I use my MBA for: statistics (I'm stronger here than most SWEs), marketing, communication skills, and understanding business use cases. Watching very effective PMs, I think soft skills (leadership, communications) are more highly correlated with success than "technical prowess." The ability to grok technical concepts is kind of table stakes, but being very technically talented isn't necessary (and such talent would probably be wasted).
- sologoub 11y ago
  Great perspective! From my own experience, having a strong grasp of the overall architecture and implications thereof is very important, however, thinking that you can do better than the Engineering team or that you know how that system should be designed is a liability. Collaboration is the name of the game.
  - stvswn 11y ago
    Right, I don't mean to imply that technical knowledge isn't central to the job. It is. But it can be learned. A lot of engineers on this thread might not realize that within MBA programs, the word is out -- "don't even try to be a PM, you need a technical background." As if "coding" is something ultra-intimidating and therefore if you can't already do it, you can't be a PM. My company has a reputation for this constraint, like we only hire people who were full-time SWEs in a past life. It's simply not true. Once you get here, though, you have to understand the technical architecture, for sure. But being a PM isn't alone among careers, here -- most careers have a steep learning curve when you're starting out.
- MaxScheiber 11y ago
  I recently graduated from the Wharton / SEAS undergraduate dual-degree program. I can't currently think of any PMs that didn't have a technical background. I completely agree that being able to grok technical concepts is necessary, and that being a good software developer isn't. However, it is pretty difficult for someone to grok technical concepts in a way that can add value to software engineers without some soft of software engineering or computer science background. I haven't been able to think of a better way to pick up the technical context than to actually program. The banking analogy is the stereotype of the "clueless" MBA associate who didn't put in the two years as an analyst, can't build models, and therefore doesn't add much value to his or her analysts. In other words, I submit that it is significantly easier to fully understand the architecture, as sologoub is referring to, with a technical background. It seems like your CS minor and Rails experience gave you the necessary background, which supplements the soft skills that PMs also need. A lot of my friends and peers who were "interested in technology" but did not understand software engineering took jobs as PMMs, venture capital analysts, or investment banking analysts on a TMT desk. I think this makes sense; I can't see them being very good in a PM role. It wouldn't surprise me if this were somewhat different for MBAs, though.
- BrandonWatson 11y ago
  Dating myself. I too was a Engineering and Wharton grad...20 years ago. Yeesh. I found my way into a Product Management internship in 1994 by luck and happenstance. The honest assessment of the recruiter was "you are too technical for marketing, and not technical enough to test or write code." There's some truth to that. As someone who has been in product management my entire career, in my own VC funded startup, MSFT, AMZN, now ORCL (was part of a small company ORCL bought), spanning HW and SW, Cloud, and mobile phones, enterprise and consumer, I posit the following from my own personal experience. I try to simplify things to make it easy for people to understand. Product managers need to worry about "the what, and the why, and sometimes the how". In smaller companies, where they are also managing scrums, etc, they can focus on the "when" but as companies grow, and more specialized program managers exist, or engineering leaders are more actively engaged in this part of the product lifecycle, they can worry about this less. It irks me when I meet product managers who haven't written code, or don't try to prototype things. Ideas are cheap. I am not a great coder. I joke that me and code is like a kid and a hand grenade. At first glance it's cute, but it will get messy when the thing explodes. The best way to improve on a SW based idea is to show a hacker/developer crappy code. They can't help themselves but to try and improve it. Selling the vision has as much to do with the idea as it does with your ability to empathize with the customer need and pull together something into a cohesive thing that can be touched. Code always wins. Your job, as the product manager, is to shepherd the idea/vision through to completion. That vision must be viable. You must not be in love with your idea. You must be in love with solving a customer problem. Engineers sometimes get stuck on the solve. Great product managers focus on the problem, and refine it with simplicity. If you cannot answer "what" and "why" you are not doing your job.

stvswn 11y ago

Also went to Wharton, and I'm a PM. My background was only a CS minor as an undergrad (8 years ago) and that I taught myself Rails in order to attempt a startup. This demonstrated a propensity for software but is completely useless practically. I've learned almost everything on the job. I use my MBA for: statistics (I'm stronger here than most SWEs), marketing, communication skills, and understanding business use cases. Watching very effective PMs, I think soft skills (leadership, communications) are more highly correlated with success than "technical prowess." The ability to grok technical concepts is kind of table stakes, but being very technically talented isn't necessary (and such talent would probably be wasted).

sologoub 11y ago
Great perspective! From my own experience, having a strong grasp of the overall architecture and implications thereof is very important, however, thinking that you can do better than the Engineering team or that you know how that system should be designed is a liability. Collaboration is the name of the game.
- stvswn 11y ago
  Right, I don't mean to imply that technical knowledge isn't central to the job. It is. But it can be learned. A lot of engineers on this thread might not realize that within MBA programs, the word is out -- "don't even try to be a PM, you need a technical background." As if "coding" is something ultra-intimidating and therefore if you can't already do it, you can't be a PM. My company has a reputation for this constraint, like we only hire people who were full-time SWEs in a past life. It's simply not true. Once you get here, though, you have to understand the technical architecture, for sure. But being a PM isn't alone among careers, here -- most careers have a steep learning curve when you're starting out.
MaxScheiber 11y ago
I recently graduated from the Wharton / SEAS undergraduate dual-degree program. I can't currently think of any PMs that didn't have a technical background. I completely agree that being able to grok technical concepts is necessary, and that being a good software developer isn't. However, it is pretty difficult for someone to grok technical concepts in a way that can add value to software engineers without some soft of software engineering or computer science background. I haven't been able to think of a better way to pick up the technical context than to actually program. The banking analogy is the stereotype of the "clueless" MBA associate who didn't put in the two years as an analyst, can't build models, and therefore doesn't add much value to his or her analysts. In other words, I submit that it is significantly easier to fully understand the architecture, as sologoub is referring to, with a technical background. It seems like your CS minor and Rails experience gave you the necessary background, which supplements the soft skills that PMs also need. A lot of my friends and peers who were "interested in technology" but did not understand software engineering took jobs as PMMs, venture capital analysts, or investment banking analysts on a TMT desk. I think this makes sense; I can't see them being very good in a PM role. It wouldn't surprise me if this were somewhat different for MBAs, though.
BrandonWatson 11y ago
Dating myself. I too was a Engineering and Wharton grad...20 years ago. Yeesh. I found my way into a Product Management internship in 1994 by luck and happenstance. The honest assessment of the recruiter was "you are too technical for marketing, and not technical enough to test or write code." There's some truth to that. As someone who has been in product management my entire career, in my own VC funded startup, MSFT, AMZN, now ORCL (was part of a small company ORCL bought), spanning HW and SW, Cloud, and mobile phones, enterprise and consumer, I posit the following from my own personal experience. I try to simplify things to make it easy for people to understand. Product managers need to worry about "the what, and the why, and sometimes the how". In smaller companies, where they are also managing scrums, etc, they can focus on the "when" but as companies grow, and more specialized program managers exist, or engineering leaders are more actively engaged in this part of the product lifecycle, they can worry about this less. It irks me when I meet product managers who haven't written code, or don't try to prototype things. Ideas are cheap. I am not a great coder. I joke that me and code is like a kid and a hand grenade. At first glance it's cute, but it will get messy when the thing explodes. The best way to improve on a SW based idea is to show a hacker/developer crappy code. They can't help themselves but to try and improve it. Selling the vision has as much to do with the idea as it does with your ability to empathize with the customer need and pull together something into a cohesive thing that can be touched. Code always wins. Your job, as the product manager, is to shepherd the idea/vision through to completion. That vision must be viable. You must not be in love with your idea. You must be in love with solving a customer problem. Engineers sometimes get stuck on the solve. Great product managers focus on the problem, and refine it with simplicity. If you cannot answer "what" and "why" you are not doing your job.