I don't see why people think of a Software Product Manager's job as amorphous or poorly defined. The job description is straightforward: you manage features. You gather information from users/customers and/or sales & marketing about what new features and feature enhancements are wanted, define what criteria satisfy the features, get estimates on what the features will cost to build, and you make decisions about how to prioritize and schedule the development of features, to make the product as successful as possible.
Marketing of any kind. PMs often are either directly involved with marketing or work with a PMM.
Market and competitor analysis.
Tracking and being held accountable for KPIs, particularly P&L.
Strategic partnership development and management.
Corporate strategic planning.
Facilitating communication between sales and marketing, engineering, technical communications, and senior management.
I'm sure the list goes on.
And BTW, how it's defined varies from company to company. Some folks might place some or all of those responsibilities under the auspices of a CTO or COO.
So I disagree. I actually think the role is incredibly ill-defined... everyone has a different idea of what it means. Some people think it's basically an Agile Product Owner, polling customers, writing user stories, managing backlogs and working with engineers. Others describe it as "CEO of the Product", which implies a VP-level leadership-style position. Yet others probably see some weird amalgam.
And that's just what the role is supposedly defined as. I'll bet there's a wide gap between what a PM job description says someone should do, and what they actually do in practice when you have to marry the theory with organizational reality. After all, aside from various KPIs, I'm not aware of any obvious way to actually evaluate the performance of a PM...
And we haven't even delved into the ambiguity of moving from "what" a PM does to "how".
A lot of it is managing conflicts. Those decisions that you make will change over time, often outside of your control. The changes can come from above, below, inside, outside, or from within.
No battle plan survives first contact with Engineering, Marketing, Sales, Manufacturing, Finance, or Upper Management.
Fair point, I should have left out the second part. My point is that creating value shouldn't be associated at all with features. Creating value might be 1) striking a deal with a partner, 2) tweaking an operational process, 3) improving a customer support script, etc etc etc.
1) striking a deal with a partner, 2) tweaking an operational process, 3) improving a customer support script, etc etc etc.
Yes these tasks add value, but that doesn't necessarily mean they are, or should be, part of the Product Manager's job description. They may get done by Product Managers in some cases, but they could also be done by people in various other roles.
> One day, there may be graduate degrees and definite career paths to product management, but not today.
What he has described is a multi disciplinary generalist with knowledge of each business sector and training in how to manage organizational goals and people. There is actually a current post graduate degree for that exact task - the MBA.
Unfortunately, many MBAs are still looking at the world through a manufacturing lens. Software sector is fairly different in that you don't have a conveyor belt and "plant size" is only marginally useful in that you cannot replicate productiveness exactly.
For product marketing aspects of that job, an MBA is useful, but again, one needs very solid grounding in the subject matter itself. MBA is more of a way of thinking, as opposed to a blueprint in how to do X.
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.
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).
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.
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.
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.
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.
I like this. I'm a software developer but I often find myself on the "pro" side of debates about the value of an MBA (often with MBA-holders), and I have long thought product management is the most important role in a software company, but I didn't realize until I read your comment that those two opinions are probably one and the same.
It's a really long article explaining and justifying what "Product" is.
I think a much simpler explanation is that product management is the hub that connects all of the other groups together in a unified and consistent fashion.
Is marketing up to speed on exactly what is launching a month before it launches, so they can prep content and PR people? Do sales people understand exactly how we should or should not be selling a new feature? Do finance and legal know how we're going to sunset that old piece of functionality without violating contractual agreeements with customers?
Thats' all product management. And then you get into the roadmap side of things, but even that is largely in service of the above goal.
I'm not one of those product people who thinks that all companies need product managers. But I think in the end, someone ends up filling that need, whether they have a formal title or not. It could be a sales exec, or a presales engineer, or a head of engineering with good business sense, but that's the job function they're stepping in to fulfill.
It's a really long article explaining and justifying what "Product" is.
TBH, I didn't think the article was justifying the role so much as justifying the ambiguity that surrounds it.
The fact that PM touches so many areas without specializing in any one, and ultimately involves mostly leadership and coordination, means it can be really tough to put a finger on what, exactly, someone with that title is doing.
* But I think in the end, someone ends up filling that need, whether they have a formal title or not.*
And that really is the key.
In small organizations, it's not unusual for the lead of the technical group to own these functions. That can be good, or it can be very very bad, depending on the person and the market the company is operating in.
But as the organization scales, the complexity of the work grows substantially. Often that means a few folks help pick up the ball in an ad hoc fashion until someone realizes that maybe one person should own the responsibility, and voila, a product manager is born.
As a relatively newly minted Product Manager, I struggle, every day, to figure out what, exactly, my job is, other than to abuse commas (I'm in a rather odd spot in that I have no mentor and weak senior leadership, so I'm largely responsible for defining my own role in an organization that doesn't really grok what product management involves).
One thing I've found is that I can't easily put my finger on what exactly I do... "leadership + coordinator/facilitator" is the best I can come up with. It's something that's troubled me for a while now, but this post makes me realize that maybe that's just normal, which is rather nice to see.
Still doesn't mean I know what the hell I'm doing, but that's a different problem...
Honestly, your job is to get yourself into a product management role where you'll be properly mentored by someone more experienced. I'd persuade your company that they need to hire someone senior for you to learn from or move to another company where there's already a bigger PM organization.
Unfortunately, you're 100% right about all of that...
This is getting afield, but I'm in a rather tough spot: late stage startup that continues to grow, and one I've been involved with for a very long time, so I've invested a lot of my career here. I want to see it succeed (not the least because I have a not insubstantial option pool), and it seems we probably will, though perhaps in spite of ourselves. :) Customer engagement is high, we're seeing steadily growing revenues, and we've largely pushed aside any competition in our space.
But, senior management is only borderline functional and business focus is primarily customer acquisition rather than strategic product initiatives. Some recent changes in that area have been positive, but not transformative, and we continue to build a business on an original concept invented over a decade ago, while failing to keep up with changes in the industry.
Meanwhile, my direct report is essentially absent (which means product has no representation at the VP level), and the only other VP-level individual (who, notably, is not my direct report) with a strong product background is likely on their way out for various political reasons.
Tricky.
Anyway, barring a career change, at minimum, I really need to reach out to my network to find other folks in the role with whom I can share war stories and coaching/advice...
IMO: once you grok how PM is viewed by a management team, you need to make a stay-or-bail decision. Don't waffle. It sounds like you've already made the evaluation.
My 30 yrs of experience says that an idiotic mgmt team is going to stay that way until they fail and/or are replaced. PM's squishy nature just makes it a easy target for "oh, they're just marketing." And your particular direct report circumstances just make the decision that much easier.
I wouldn't necessarily agree with the part about "why product management exists".
Product management exists because customers need a clearly and concisely communicated path to their benefits today and in the future. Product developers need a clearly and concisely communicated path on what to build to create value for customers.
Successfully marrying those two is not an easy endeavor, and the way at which you do it isn't a one size fits all orchestration. Hence, why product management is seen as something of a dark art.
Here's what I do know. Companies without strong product management risks themselves to higher customer churn and longer development-to-value timelines.
One exception that i'll say is that a lot of platform-y products where the developers are relatively closer to the target audience tend to do better without product management.
Not that it gets you out from some of the challenges I list elsewhere, but at least from a persona/use case perspective it's comparatively easy to grok why and how someone wants to use the tool if that "someone" is close to the person who is writing the code.
On the flip side, anything with sophisticated non-technical business users or niche industries absolutely depends on having product management to rep the voice of the customer to R&D.
From an engineer's perspective, the problem with product management is often lack of a definable process. How do the PM's priorities correlate to actual user priorities? I've never had a PM who showed actual names and numbers or anything quantitative to show this relationship. If I could see that, it might be easier to understand why they're willing to tie up half of engineering for a year to implement a feature that not one of those engineers believes will actually matter, while other apparently low-hanging fruit have to go unpicked. It's OK if they're wrong, so long as there seems to be a rational process involved. I've worked with some pretty good PMs, but even they seemed to be good primarily because they had good gut instincts and not because they applied a rigorous process. In other cases, PM decisions seemed to be based on pure personal bias unchangeable by facts. Anyone who has lost a year of their life because of a PM's ten-second decision is going to be less keen on PMs as a species for a long time.
I've worked with some pretty good PMs, but even they seemed to be good primarily because they had good gut instincts and not because they applied a rigorous process.
So have you provided a rigorous, data-driven defense of every decision you've made as an engineer?
'cuz I've met a lot of great engineers whio made great decisions primarily because they had good gut instincts and not because they applied a rigorous process.
I've also seen engineering teams suffer because of a ten-second decision made by someone a year previously.
We're more similar than you think. :)
The sad reality is PM is fundamentally a dark art, even more so than engineering, which is, let's face it, driven as much by instinct as true engineering principles.
Now, that doesn't excuse a PM from not doing market research, not doing cost/benefit analysis, not tracking KPIs, etc, etc. PMs should view themselves like an entrepreneur, and should always be looking to back their decisions with data like any other business owner.
But ultimately, good instincts have to be part of the skillset. And just like an engineer, sometimes decisions are made based on a gut reaction, particularly when decisions have to be made very quickly (which happens more often than we'd all like).
> So have you provided a rigorous, data-driven defense of every decision you've made as an engineer?
Not every one, no, but most of the time. What you're engaging in here is tu quoque, as if an occasional behavior in one group justifies a continual behavior in another. Ain't so.
> I've met a lot of great engineers whio made great decisions primarily because they had good gut instinct
As have I. I've also met some PMs who were likewise, and said as much. All I'm saying is that relying on that all the time can cause resentment.
> The sad reality is PM is fundamentally a dark art
That's OK, though I believe it's probably less true than you or the OP seem to believe. What's most injurious to the PM/engineering relationship is not the lack of rigor but the lack of transparency that goes with it. Often PMs don't even try to explain where their priorities came from, and don't admit when they're just guessing. We engineers can deal with guesses. As you point out, we make them ourselves all the time, but we acknowledge that they're guesses and therefore inferior to any data that might come along. "Because I'm the PM" is too often the only reason given, and of course that leads to animosity.
As a PM at a large, engineering-driven company, I would say that convincing engineers like you that my process was rigorous is about half the job. It's annoying but enforces discipline. The engineers don't agree to build features otherwise.
That's funny, we say the same thing about anything to do with schedules. ;) I guess we all have our crosses to bear. That's why communication and transparency - on both sides - are so important. They can maintain trust, even when things don't go as planned. (And when do they?)
I find here in the valley companies value engineers who want a say in product direction. So we have companies filled with engineers who don't want to just be shoved a task and relegated to coding monkey status. I think that's where most of the ambiguity exists.
As I see it, a PM should be your team's CEO and the lead engineer should be the CTO. Together the pair of you are delivering on a single vision, one person outwardly and the other inwardly. Yet for the magic to work, the entire team needs to be on the same page. No one person should be setting the goals for everyone else. Simple put, the PM isn't the engineers bitch and engineering is the PM's bitch.
The problem is with closed-minded PMs who refuse to accept reasonable input from external stakeholders & experts. Not saying this is the rule, but it is common.
Well, to be blunt: a closed-minded PM is, by definition, a crappy PM. Listening to experts and external stakeholders is literally one of the core parts of the job.
That's not to say a PM has to take their advice. But if they choose not to, it should be for clearly defined reasons based on strong reasoning backed by data.
I think the author missed a biggie: In many companies, the Product Management team owns P&L's and makes sure products are profitable. They have direct delegation from the CEO for the "business side" of the product. If you're charging for your product, that's super important!
I work for a company with many product. This post explains why it is so hard for the company to move forward in our fast moving tech world. It also explains why so many startups today are "single trick ponies" that learn to expand their from only one product.
