Hacker News new | comments | ask | show | jobs | submit login
Ask HN: Where did all the Product Managers go?
47 points by ycskyspeak on June 1, 2014 | hide | past | web | favorite | 51 comments
The trend towards having no Product Managers in an organization seems to be catching on. Stripe does not have PM folks. Nor does Square to an extent. When hired, the work is split between project management and passing the parcel between various departments of the company - engg/release readiness/sales etc. There was a time when Intuit was the shining star of PM training. Are there good product organizations? It seems like most are sales or engineering driven. And will this field even survive in the future?



Comments seems to be confusing Project Management, Product Management and Product Marketing Management. Those specializations don't often exist in small companies, but definitely arise in larger companies.

To the folks denigrating Product Management: it's a very difficult job; and some pretty crappy people get into it when they don't like marketing and can't do software development. That doesn't mean that Product Management is worthless...

As a developer, when you build a software feature, you have to keep in mind how this little or large feature will affect the system in the future: hack it together now or build it for real. Neither track is inherently good/bad, but bad developers pick a path without understanding the near-, mid- and long-term effects.

Having been a good PM [IMO], the real key was the ability to balance product requirements now against their long term affects: spot features we needed to build now to support another in-development feature; prevent features from being built which would hamstring us in the future. I had the good fortune to return to a former employer and see that: investing in a feature had paid off a ton even though the other PMs had opposed building it; my failed request that we not build certain features had, in fact, produced a quagmire in which we discovered a misset-for-years setting which produced a -15% offset in revenue. Anyone can look at a market and say "hey, we need this little Feature X"; the harder part is realizing that the little dropdown required for Feature X is going to fundamentally alter the perception of your product and kill your sales...


> That doesn't mean that Product Management is worthless...

> the real key was the ability to balance product requirements now against their long term affects

The problem is that a lot of companies are structured so that this is impossible for their PMs to accomplish.

Good employees (PMs or otherwise) will always find away to be effective in spite of the organization. However, if product management is too much under the thumb of sales, or if they are too much under the thumb of development and disconnected from sales, they don't have the visibility they need into one end or the other. Further, there will be pressure from their bosses to advocate more for their side.

To me, the best PMs are good mediators. Not only do they know how to schedule requirements and decide scope, they know how to communicate that effectively, and get buy-in from both sales and development with a minimum of squabbling. Because of this, if they're capable of doing their job effectively they don't need sales or development to report directly to them, and likewise they shouldn't be reporting to either sales or development.

If leadership feels the need to put product management under sales or under development, chances are they need to hire new PMs.

I completely agree though that good PMs are rare, exceedingly difficult to hire for, and worth double their weight in gold.


    >The problem is that a lot of companies are structured so that this
    >is impossible for their PMs to accomplish.
Would love to hear more about this since I'm going to be structuring the engineering, and possibly product, teams for the startup I joined...

    >get buy-in from both sales and development
Totally. People often rant about Sales or Marketing or Engineering, but none exists without the other. I think the combination of deep technical skills and a two year tour of duty in Sales (as a Field Applications Engineer) provided me with the ability to pre-understand each sides' concerns and to communicate with each more effectively.

    >If leadership feels the need to put product management under sales
    >or under development, chances are they need to hire new PMs.
Yeah, I've seen this first hand two separate times and the constant refrain from the rest of the company was "why isn't engineering building what our customer's need?" I do wonder if it's possible. Or advisable. Might be something that goes bad no matter how well it starts.


Product Management is its own thing. It doesn't really belong under either of those. Keeping in mind that org charts influence thinking - rightly or wrongly - you'd be putting Product Management in a no-win situation when they're meant to act as intermediaries between engineering and sales.

I'm just joined a startup where Product is its own arm. We sync with Sales and Engineering, but we push products based on smart decisions. It wasn't always that way, from what I hear, and it was a slog to get there, but so far from what I've experienced, it's been well worth it. There's still some work to do, but it's vastly different from orgs I've been in before, where Product fell under something else and had little clout to do what needed to be done.


All of your requirements for a good PM mean that the PM needs to have the skills to be a developer as well. It's probably why some companies aren't hiring for PMs anymore because only an engineer will have the technical foresight required to perform adequately.


    >All of your requirements for a good PM mean that the
    >PM needs to have the skills to be a developer as well.
I somewhat agree. The best PMs I've seen have had technical backgrounds, so a technical background seems necessary, but it is not sufficient. The best PMs have had a deep understanding of customer need, company/product direction, development feasibility. https://news.ycombinator.com/item?id=7830892 said "president of the product" and I think that's nice. Given the invisibility of corporate "presidents", I'd suggest "CEO of the product" since you've got to have the ability to review the smallest issue while considering the long term effects.

Years ago, I was friends with the CEO of an hot CPU startup and I asked him what had most surprised him about his job. He was formerly the VP of a division of a public semiconductor company, so had serious experience. And still he said that he was astounded at the range of questions he got asked: VP of Finance raising some technical accounting issue; VP of Hardware knocking on his door to discuss process nodes and vendors; VP of Software looking for advice on ways to solve a complex problem; HR Director raising sexual harassment policies. Barring the sexual harassment policy, yeah, that sounds about like Product Management [and, yes, you will bump into "revenue recognition" while a PM].

EDIT:

... derp ... I missed this:

    >only an engineer will have the technical foresight
    >required to perform adequately
I think this was covered above, but I did want to address this particularly engineering-centric perspective. There are supremely bad engineers-turned-PMs because they think PM is Eng+[some vague management-y ring they should try to catch]. (There are also supremely bad marketers-turned-PMs... but we all know that...) Don't get lulled into thinking that you can be a good PM merely because you're an engineer. [You'll suck and be frustrated. And companies have huge problems with people doing jobs they shouldn't be doing, so be an awesome engineer/developer and you will be richly rewarded.]

The worst part of being a PM is that you won't be as skilled as your audience. You'll propose features, but you won't be as good at development as the developers who'll develop them, the salespeople who'll sell them, the marketers who'll market them. But you need to be good enough in any domain to call bullshit on any of them because everyone will be a passive-aggressive sand-bagger when they don't like your requests. [Once, as a PM, I proposed a feature and then, since I also had SVN access, built it in 3 hours. Was approached as I was building the feature. The Dir Eng was telling another PM the feature would take 3 days to build. Sand-baggers suck and developers sand-bag, too...]


Even if there aren't people who have "Product Manager" on their business cards there's going to be someone acting as a product manager.

In my possibly overly-simplistic view, PMs should generally focus on what the customer should be able to do, while developers should focus on how it's going to work. Of course, each group needs to be able to understand the position of the other to be useful. I'm worthless as a developer if I have no empathy towards for the customer (i.e. I shouldn't say "we're not going to implement this feature that would be useful to customers because it's too hard"), and PMs are useless if they don't understand the technical constraints of the existing code/infrastructure.

I'd say that PMs are less technical than developers, so developers can do the PM work if necessary (and should be thinking about it a little bit even if there are good PMs).

Project/Program Managers are different. Their job is more focused on making sure all the moving parts of a "project" are coordinated. When it's a small start up there aren't as many moving parts, so it's not a useful role - but in bigger companies it's useful to have someone coordinate between marketing, legal, finance, customer service, etc. And they can make sure everything happens on time.

You run into problems when developers don't care at all about customers, product managers have no sense of what's technically possible or reasonable, and project managers get too hung up on the process and not the final result. Avoid those situations and everyone adds value.


I sense a lot of hostility toward product managers here, and I don't know why. I could understand why, as a developer, someone would not want a bad product manager, but a good one should make a developer's life easier.

Developers are the ones who should be coming up with ideas about HOW to do things. Make something more efficient? Dev. Implement an incredible new technical feature? Dev.

Product Managers are the ones who talk to the customer and steward non-technical vision. They are the bridge between sales people—who are incentivized to say yes to every customer request—and developers—who in most cases do not have the time to be thinking about what a customer might want, doing customer interviews, etc. Product managers are there to avoid the lukewarm tea problem, to adhere to a coherent version of a product, and to help coordinate the many parties who have an interest in seeing a product succeed but who might have different perspectives on what that means.

Some places that have Product Managers (or Product Somethings (editors, gurus, swamis, whatever)): Apple, Google, Dropbox, Box, Evernote, Square (they exist, I know some who fill these roles), Twitter, Facebook, Microsoft, Spotify, and many others. These people not only exist but also are a central communication hub if they are doing their jobs right. Today's shining stars of PM are Apple (for hardware), Google, and Facebook. Everyone wants to hire people away from those teams.

The thing that bothers me about the other comments on this thread is the attitude of superiority that some people are taking: "if you aren't a dev/engineer/technical person, you aren't worth shit." Sure, in some companies, technical ability is all you need. But in most, particularly anything of reasonable size, you need a variety of people. Developers are not lawyers or finance people. In many cases, developers don't want to interview customers or aren't good at it. Developers are GREAT at developing (at least some are, others are complete clowns who have no ideas what they are doing), they chose to develop, but a company is so much more than development.

A great team--across all roles--is what makes a company great, and that includes product managers.


Great comment - totally agree with the hostility point.

The best product managers are like the best point guards in basketball. They see the whole court, deliver the ball right into the hands of the person who can score at the right moment. Unfortunately, most PMs are like characters in Office Space.

My theory about why their aren't many PMs out there: it's a shitty job. I was a PM for around 10 years, but I left it because it's just not a great job in most orgs. More specifically, it is generally a job of "no" as opposed to a job of "yes", and is a job that lacks any real authority in most cases.


What do you now?


"Some places that have Product Managers (or Product Somethings (editors, gurus, swamis, whatever)): Apple, Google, Dropbox, Box, Evernote, Square (they exist, I know some who fill these roles), Twitter, Facebook, Microsoft, Spotify, and many others. These people not only exist but also are a central communication hub if they are doing their jobs right. Today's shining stars of PM are Apple (for hardware), Google, and Facebook. Everyone wants to hire people away from those teams."

Where are you getting your info? Apple has no Product Managers. It has lots of Project Managers and Product Marketing Managers but not Product Managers as you describe them. What products to build (from high level vision down to fine details) is decided by primarily Engineering and Design (for both hw and sw).


Apple has Engineering Program Managers which manage the product build. Sure, vision and design are provided by others, by the EPM (and other titles I'm sure) are communication cruxes.

What products to build is decided by the exec team. What they look like is determined by industrial design. Engineering has little to no say in what actually gets built.

The idea that someone with the title Product Manager is going to be making a final decision on product vision is pretty narrow minded. Google does have Product Managers, but it has many on every product. Just because you are not managing an entire product line does not mean you are not managing product. I think once you get outside Tim Cook and Jony Ive (and maybe a few select others) at Apple, you are too low on the totem pole to be able to make any sort of long term product visioning decision.

Edit: And if you disagree about Apple, fine, I will rescind that example and continue to assert that product managers are very important in most organizations to balance the preferences of many players in trying to make a product a success.


Really you don't know why? Product management is the embodiment of the idea that man should not be allowed to control what he or she makes. It's the idea that the maker's role should be reduced to mere mechanical typists because we have all these other people that so badly want to be in control and make all the decisions, but dammit they just can't be bothered and are too important to do all the difficult parts like actually making the thing. Not surprisingly, everyone except engineers likes this idea.


I think your product managers are doing it all wrong. They should be showing up with "this is the problem we've identified" and asking how the makers can solve it. Product management looses out big when they show up with "this is the solution we demand".


Yes, that would be great. Unfortunately there is no incentive at all for product managers to have that sort of positive and forward thinking attitude or working relationship with engineering. Instead, 99.9% of product managers have every political incentive to take the approach of 'I have the word manager in my job title therefore I am everyone's boss and they must work to meet my demands' Inexperienced engineers won't challenge this and every other person on the team loves the idea that engineers are their underlings, so that becomes the culture and work environment.


So: I don't really know, but I have a theory.

Good product managers are really really hard to find. I've had the pleasure of working with a few, but I would say about 90% of them are worthless. The gems are definitely worth having around though.

The problem is, since finding good product managers seems so incredibly hard, I think instead of hiring for it and making it an official title, most organizations just evolve someone into the role. The problem is, being able to be a good manager requires a lot more domain knowledge than a lot of people realize, IMO, and so it ends up that often times the best product managers are people that either evolved into it from a design or development standpoint, or a person that had a lot of good domain knowledge in the subject matter that could step in. The commonality of all the product managers I've know that weren't good was that they really lacked domain knowledge, to the point where they were basically trying to tell people what to do even though they were clearly the least informed person in the room.


I agree. Essentially, good product managers should have all the skills necessary to be a designer or developer as well.


Think about the roles of a PMM --- customer discovery, pricing/segmentation, roadmap.

In a single-product startup, which is what most startups are, the whole company is doing these jobs. Product/market fit might not be established, or might be just months old, so the people doing sales are also doing customer discovery. The management team is agonizing over pricing and isn't ready to delegate it. The CEO might be reading every commit, and the roadmap is obvious.

I was a PMM for a couple years, and the role was described by a friend to me as "president of the product". In an organization with multiple products, you can need that role; one person keeping track of every business facet of every product doesn't scale. But you don't delegate roles until you need to. Like Jason Fried recommends (paraphrasing): hire when you've gotten so good at a role that you're tired and can't keep up with it anymore.


It seems some people are lumping Product Managers and Project Managers together.

They should be separate roles. And I believe, ideally, if you're in an organization with Product Managers, you shouldn't have Project Managers.

You can depending on the circumstance, but if you're a product manager you're more than likely in an agile environment.

Project Managers deal with projects, a temporary endeavor with a definite start and definite end to accomplish a goal. Products are ongoing things. Prod Managers should be looking for trends in the future of the market, and putting those features on the backlog of the team that's working on that product.

Are Prod and Proj managers going away? I think Proj Managers are. So many bad ones. Prod Managers? I haven't seen that happening actually. It seems more people are moving to Agile and hiring Prod Managers and Scrum Masters.

At least in my area.


Just because you don't have a formal role an unspoken org chart will arise and someone will be acting more as a PM than others.

when you aren't trying to build a lasting product, and are hoping to get acquired after a few rounds of funding its pretty easy to not have product managers.


Well, I for once am hoping they don't all come back to haunt me!

I've rarely met a good one. In most agency style environments PMs are responsible for the messes that will have to be picked up by the devs, having promised the world and are unable to backtrack on any of it "because the customer has already agreed to it". I'd rather talk to someone about what they want out of their product and then let them make an informed decision where they can weigh up cost and impact of a certain feature. After all it's their money.


I've met a good PM or two.

Know how you tell a good PM? You think, "Thank God someone is doing that job. I'd hate to be doing it." They are bringing teams together and smoothing out rancor and NIH, getting agreement on things that are hard to get agreement on, researching things that nobody else has time to do, ensuring that Joe and Susan and Amhed are talking to each other regularly, and they know everything about the project, at least at a high level. They are technical as hell and you wonder why they aren't slinging code. You read the specs they've written and are just awe-struck by their technical depth and completeness.

Know how to tell a bad PM? You avoid them because they depress you and make you wish they didn't exist, because they subtract value from what you are doing. You go to their daily status meetings with a heavy feeling in your heart. You explain time after time to them that no, you can't use XML for that, that adding 12 programmers to the project won't bring in the schedule by six months, and that the slide deck they're giving to management in an hour has so many mistakes and fantastic assumptions that it might as well be crayon drawings by a three year old. The specs they write, if they exist at all, are mostly schedules and technical buzzwords and are useless. Typically, they love SharePoint.

Good PMs are very, very hard to find.


> I'd rather talk to someone about what they want out of their product and then let them make an informed decision where they can weigh up cost and impact of a certain feature.

So, you'd like to be a PM then?


Not really. I'd rather work in an agile team with a proper product owner aka customer on board, where the whole team can discuss cost vs benefit of each individual feature and then act accordingly.


That setup rarely ever works. There needs to be a person to interact with the customer. Developers don't work well with customers.

A good PM will discuss options with the team, but they will serve as the interface through which the customer communicates with the team. The customer does not care how things get done, only that they get done on time.


"Developers don't work well with customers"

Why does it have to be like that? This sort of silo thinking is probably what created the disconnect in the first place.

The customer might care about how things get done, if it means the difference between getting 85% of their wish list done or 50%, all depending on one obscure feature.

Agile/SCRUM can make the potential complexity of a feature more visible because it's a team estimate. It also can make the decision process less laggy because the customer/product owner sits in on the team. Finally it can make the end goal more visible to the Devs, resulting in less of a disconnect.

My 2p


It's not so much that it "has to be like that", in that your merging two different roles, without finishing your thought. Your arguing for good project management, and practicing good project management, while telling yourself + others that it's "no project management."

There is no such thing as "no PM". Such a concept can't exist (for the same reason that "no developers" can't exist). There's actual work there, that someone has to do, or nothing gets built.

Now, it's totally fine if you say "I think it's best if all of our team members spend 75% of their time as developers, and 25% of their time as project managers". That's what you've just described above, and (in my opinion) there's nothing inherently wrong with that.

But your misleading yourself if you claim "PM's aren't needed because Agile", or "PM's aren't needed because the one's I've met 'silo' us off". All you've done is shift the PM burden from a specific person, to some/all of your developers. Your developers are now actually "part-time developers, part-time PM's"

There's also some weird assumptions that your making around PM's. PM's do not have to silo developers away from the client (and good ones don't). PM's do not have to estimate for devs (good ones always use team estimates).

I've seen developers write buggy code, or brittle tests. But I would never say "developers aren't needed". You've clearly encountered bad PM's, and that's very unfortunate. But that doesn't mean "PM isn't needed", and as you yourself just described, you already have to pick up that work on your own since you lack one on your team.


All good points, and I agree with you that project management as a task isn't going away. Of course my original comment was coined towards the agency style workplace (and meant to be a bit tongue-in-cheek), that's where I experienced the worst permutations of the role.

I'm not saying that there aren't any good ones somewhere else, but I just haven't really met any.


I agree with you. No need for these types of fake jobs.


Obviously you lack serious development experience. These "fake jobs" are the only reason we have serious apps like Salesforce, SAP and others. If you want to create a "hip" app just to get featured in TC and such with a 90% possibility you'll fail then, yeah, you don't need a good PM, because you're almost certain to fail anyway regardless.


I am not sure what SAP and Salesforce have to do with my example of a typical agency environment?


I think it depends a lot on (1) product complexity and (2) who the customers are.

Stripe has the luxury of a product with straightforward requirements (note this says nothing of the technical architecture/complexity of the product, just what it does -- "process credit cards") and they're building for other developers. In a company like this, it seems easier to prioritize based on developers' understanding of the problem.

Contrast that to a place like Zen Payroll (went to breakfast with a friend who works there today). ZP has to deal with complex tax issues, understand and prioritize feature requests from a huge array of non- to semi-technical customers, and deal with major PII/infosec compliance stuff. These kinds of problems really necessitate having someone on the team who will be the go-to expert for their domain, that can act as a "customer surrogate" in discussions of what's important, how something will be used, the relevant laws/regulations/etc.

So to summarize, I think it's less necessary to have a lot of product managers if you're building a simple product for engineers. The minute you get into complex access controls, security roles, legal/compliance issues, multiple classes of customers, or complex multi-tiered pricing setups, you need a PM to make it all hang together.


I'm sitting in Austria, twiddling my thumbs after years of Product Management circuses (eBay, BBC). Would much rather now be something, anything, other than a Product Manager.


"Would much rather now be something, anything, other than a Product Manager." Why?


I work as a product manager and hardware engineer. In my experience the fundamental role of a successful product manager is to understand the users of the product. And this isn't guess work, its based on hundreds of hours of interviews and interactions with users and potential users, its figuring out ways to prototype, test, and refine features before committing to build, its being able to articulate how the product meets and exceeds user needs. It means that when feature prioritization pops up during sprint planning, the product manager can talk authoritatively about what the user wants or needs. And a good product manager will have involved the dev team in some of these user interactions so the devs can empathize with the users as well.

This is not a role fulfilled by developers or scrum masters or project managers. If you want to repeatedly make great product, instead of just the lucky guess / shot in the dark that a lot of startups rely on, you need someone whose whole job is deeply understanding the user and making sure the product under development will meet and exceed the user's needs.


"A good product manager could be away for 6 months and no one would notice" (or something like that is often said).

PRODUCT Managers have one primary responsibility - figure out what to do next.

In order to accomplish that, they need to do research, gather feedback, involve stakeholders, identify risks, and understand from development what's actually possible (among other many other things).

I hypothesize that too often people think they "know what the users want" and don't need a PM. In reality, they have an opinion on what to do. Good Product folks know that their individual opinion is often wrong and that only through research, testing, and a little bit of luck can they establish what's next.

The more PMs can fine tune this expertise and emphasize this as their core value to an organization, the more companies of all sizes will begin to make sure their is a PRODUCT manager on their team.


Call it whatever job title you want, there inevitably needs to be someone steering the boat. You can get rid of 'PMs' but you can't get rid of the need to set strategy / vision, understand the customer problem, identify solutions, collaborate with design and corral the rest of the organization (marketing, sales, support, operations) to bring it all together. If you don't have a PM performing those functions, then a member of the engineering team needs to step up, or perhaps someone from the executive team. But then guess what... that person is doing the things that PMs do, so I guess you might start calling them a PM...? Or a 'Product Editor'... or 'Program Manager'. All just names for something pretty similar.

When organizations are small enough, the whole team performs those functions together. As you grow it makes sense to have someone double down and own those responsibilities. Though this doesn't absolve engineers of the need to understand customers and help paint the product vision.

Perhaps the better question is 'Where did all the non-technical-purely-business-MBA PMs go?'

The answer is that it is likely a disappearing breed. An MBA won't teach you how to build great software or lead technology teams, so it's foolish to believe that someone with such credentials would be a natural fit to come lead a software organization. Good PMs I've worked with can have a conversation about the technology stack as easily as they can debate a marketing strategy. Great PMs these days need to span the entire 'company stack' if that makes sense.

Lastly, if you don't know why a given role exists, then it's probably because you haven't worked with someone great in that role. There are a number of roles in tech companies I found less useful until I met someone who had mastered the craft - when I saw them in action, it became clear why the role existed and how they could perform a certain function infinitely better than I.

As a last thought, I worked at Intuit a while back and I'm not sure they are a 'shining star' of PM training. They have done a good job of 'marketing' themselves that way, and they are an example of a company that typically has 'less technical' PMs in their organization. This is because Intuit is more of a 'marketing / business' driven organization. This contrasts with Google who is known to favor promoting engineers into the PM role. Neither model is 100% - the ideal is probably somewhere in between.


So, within an SCRUM/agile process, where do you see the PM role? The scrum master? The product owner?


At the very least they are the product owner, and if needed can step into a scrum master role depending on resources / constraints.


I worked at a place where agile failed because (1) the "Product Manager" was AWOL (he punched a timecard but never seemed to put stories in) and (2) the lead developer refused to put in estimate for everything. (As the one developer who actually put in estimates, I just got abuse because my estimates were "too long")


Sounds like a nightmare! Nothing worse than an environment where you get blamed for estimating something.

I too have worked in places that called themselves Agile but where everything but.

On the other hand I also was part of a well adjusted SCRUM team where the roles were fulfilled properly and we rolled through the project like a steam train. The key was to have a really well filled backlog and then wear most of the pain during the sprint estimation meetings, and the whole team sat in on that. This made everybody understand all the features and their potential complexity before the sprint even started, and gave full visibility of the cost of each of these to the product owner, who could de-prioritise something or swap it out in that very session. The actual sprints then were really straight forward and I really enjoyed myself there.

Prior to that I had plenty of contracts where I get "specs" from PMs, but then have to question each aspect of those, often resulting in me having to ask the product owner myself to decipher what it meant. Inevitably, nobody ever had time and I spent 50% of my day waiting for people getting back to me or work on whatever I could come up with.


Personally I think having one person who's responsible for product is essential. Someone needs to find out what features really matter, how to prioritize them, and make important decisions like when to kill features.

I work for a very early stage startup. One of the reasons why we are having such a hard time finding product market fit is that there is no one person in charge of product. We all just do what we feel is important and 50% of the time it's useless, gets scrapped, or wasn't thought out well enough.

We need someone who eats and shits the product 24/7 and is responsible for making good or bad decisions.


They key missing ingredient here is "ownerhsip" you can debate all the pros/cons of Product Manager functions and even Project Management functions till the cows come home, but regardless of functional skills / job description, the only key for success in any of these roles in true Product Ownership.

and I'm not talking about hiring a PM off the street then bestowing him/her with the "ownership" of a product they've never seen before! True Ownership comes from a self generated interest in the well-being of the product, its customers, the technology empowering it and its sustainability.

This does not happen overnight, and is certainly not a skill that can be taught.

The most successful PM I've worked with over the years had one thing in common: they actually CARE about the product AND about the users (clients). this generates an internal drive for excellence like no other, in both satisfying business goals, client asks, and technology roadmap, even though those three are almost never on parallel lines.

As to the original question, where did they all go? I don't believe the role in it self went away, but rather smart companies nowadays recognize that a set of skills and an Agile/SCRUM/PMP/etc certificate will not make you a "drop in" successful PM, but rather they rely on the internal champions of the products to help shape the story.

This means more developers are stepping into the role, and through the right level of support they can/are picking up the business/accounting/client side of managing a technology product.

Also, an important part of a Product Manager (Owner) role is relationship management and communicating with people (clients, developers, business owners, sales, marketing, support, design, etc ...).

Human interaction is unfortunately another one of those things that cannot be taught! communicating with people is so different from sending status update emails, or adding them to auto notifications from tickets in a feature tracking system.

Sadly, most of the PM I've worked with and from what I've seen, the industry actually encourages the automation, over the human interaction. yet another reason why this role is changing and is being redefined.

just my 2 cents.


Facebook and Google both still have tons of PM's.


Square has Product Editors.


Ha. When I saw this on the RSS feed, I thought you meant "where did all the good product managers go?"


In big companies these people are often called Enterprise Architects or Solutions Architects nowadays.


I am glad they are going away. Don't need idea people.


Product managers aren't idea people. They're not supposed to be, anyway.

They interview, the gather data, they build consensus around requirements, then deliver those requirements to development. Development is where the ideas happen.

Unfortunately, though, I think I know why you say this. Product management should not be about coming up with (read: dictating) ideas & implementation to product. It happens though and it's annoying as hell.


I think this is the case in a FB, What's App, or Tinder startup. But if you are in an advanced field like Medical, Law, etc. Then you need Product people with specializations to discuss with development and refine requirements.


You completely misunderstand true product and project management, that much is apparent.




Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: