The Black Box of Product Management
medium.com
medium.com
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".
No battle plan survives first contact with Engineering, Marketing, Sales, Manufacturing, Finance, or Upper Management.
No battle plan survives second contact either.
A software product is defined by its set of features, therefore a product manager's job should be to manage the feature set.
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.
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.
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 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).
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.
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.
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 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.
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...
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...
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.
Do it. To stay just invites an ulcer.
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.
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.
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).
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.
Ah, well, that's a different problem: PM arrogance.
Confidence + Humility is not contradictory to Leadership, but unfortunately not everyone understands that.
'course, many also don't understand that Manager and Leader are two different things... and a Product Manager has to be both.
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?)
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.
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.
...No?
In a small company sans PM, this work is done by the CEO or CTO. Deferring that to even a VP-level PM... that's no easy transition!