Product manager responsibilities
leaninberlin.de
leaninberlin.de
While there are a hand full of exceptions. IMHO the dedicated role of a product manager is exceptionally counter productive.
Unless they are a founder they tend to lack technical expertise of capable enginners and enginnering managers as well as have a disconnect from the core drivers of what can make the buisness sucessful.
Maybe I have just had bad luck but in my 12 years of experiance with 6+ startups it's either the founders or buisness competent technical leaders who have driven a company and its products to suceed. "Formal" product managers I have come to associate with elements that kill startups... things like kingdom building, playing politics, information withholding, setting timelines and expectations without any real clue what it really takes.
We need buisness competent enginners, systems to feed feedback from sales and customer service to product enginner teams and engineering leaders who can communicate with other departments and understand buisness goals that they must build towards.
What is not needed a role who does not know sales, customer service, marketing ,or enginnering who puts systems in place to seperated thoes units for their own personal benafit.
* Design meticulous user studies, evaluate prototypes with customers, identify problems earlier.
* Research options for external interfaces for the company including supply chains, offshore options, vendors, partners.
* Do analysis of competition, their strengths and weaknesses. Estimate their future trajectory, influences, cost structure, customer opinions and actions.
* Perform retrospectives for successes and failures that happens within the company. Create systematic log of these analysis and ensure failures don't repeat but successes do.
* Make sure there exist systems for various data collections including human resources, engineering (bugs, backlog, hours spent, LOCs), customer support etc. Help turn these data in to dashboards. Lead analytics and insights in all aspects.
* Take a detailed look at the history of the field. Why past product failed? Why some won in competition and some lost? What customers rejected? How laws changed destiny of products? Lead the "lessons learned" storyteller role.
* Create systematic database of who's who in the field. Everyone from previous founders, star engineers, politicians, activists, biggest fans, partners etc.
* Ensure there exist efficient measurable pipeline for lead generation to customer acquisition to customer exit interviews. Influence strategies for sales, marketing, evangelization. Ensure company can preemptively avoid or at very least detect churn much earlier.
As you can see, founder alone may not be able to do all of these + product design + engineering efficiently and comprehensively. I would also say good product managers are never just product managers but also able to take over partly or completely sales and/or marketing. Also many good product managers are not generic MBA types but rather very specialized in specific field with solid design skills and experience in their field. The way I look at it is founders provides intuitions while product manager brings data and systematic analysis.
In other words, product management work needs to get done, one way or another.
Saying you don't need product people, you just need engineers who can do product work, is like saying you don't need engineers, you just need designers and salespeople who can code.
Sure, you could ask engineers to do all the product management. But then they'd just be PMs, except with engineering titles.
All that said, it sounds like you've worked with some pretty bad PMs in the past. And a bad PM can certainly be worse than no PM - kinda like how a bad engineer can make their entire team less productive.
It's also wrong.
The piece you're missing? The technical definition of the problem changes as we engage with solving it
So there's no "collected and distilled". This is not a grocery shopping trip. Instead there's heavy user interaction, playing, and coming to grips with both the tech and user and how they live and work together. You can't capture that in a stack of printouts or Word docs.
There are two problems with project/product management in tech. First, value discovery is a completely different activity than value delivery optimization, although they use mostly the same tools and skills. You can't tell from the outside which is which -- and we train most all of our management skills around optimization. Second, the intuitive way we humans have of solving problems, where we break them into pieces, "componentize", then optimize -- it's the wrong way of looking at it. Our natural intuitions lead us astray. (It's not a manager thing. Tons of great technical folks have taken a shot at managing and made these same mistakes)
Disclaimer: wrote a book on how this works at the team level. Currently working on one about the program and product management level. https://leanpub.com/info-ops
It took me many years of watching this fail over and over again before it finally clicked what was going on. The PM skills are desperately needed. It's the framing of the work that begins to take us down a dark path.
The comment above says, that to have a good product we need someone that understands the users. And if we want someone to be good at something he has to do that most of his time. So we need PM.
I don't think your answer is relevant, also because project management and product management are complete different disciplines
I'll try one more time. I guess if this were easy to explain it wouldn't be done so poorly everywhere.
By looking at the Product Manager's role in terms of componentizing responsibilities, duties, and skills -- which both the original author and the commenter did -- there is an underlying assumption that is false. That assumption is that these things you're supposed to understand and manage are discrete items. There's a factory metaphor, whether either author realizes that or not. Ideas come in from the users, bug system, and other places. The Product Manager assembles and works these ideas, identifying a MVP, breaking them down into smaller features, and so forth.
Perhaps this could be restated as such: There is a discrete set of information and processing that must be done to translate external stimulus into items ready for work (And yes, I think everybody agrees that this information changes over time, but the assumption is that you fix it in place at least long enough to go through a release cycle)
This assumption is not true. Yes, there is a discrete set of ideas that need processing, and the result looks the same -- but not only does the information change as time moves on, the developers concept of the world the user lives in changes the more they intimately interact. Now in a small team you join the team at the hip with some users and it works out. As you scale up, however, that's not an option, and it's much easier for a developer working as a Product Manager to spot where the world changed than a person trained only in management. (A developer who has no product experience in this particular startup would the same problem, by the way. You're looking to identify business model impedance mistmatches, places where we were coding for one universe we thought existed when in fact we were mistaken.)
That's not something you can somehow document or think your way out of, since so much of "the universe we thought existed" exists as invisible, implied assumptions. All you can do as an external manager is manage those things you can identify and record. When you're doing value discovery, the most important value ideas you'll find start subconsciously and then become visible.
We have this same problem in project management -- conflation of what I can see, record, and optimize with what the actual work is. In both cases, the underlying assumption of physicality and how we deal with physical problems comes into conflict with fluid, fluffy, and ephemeral way that humans actually think about and work through problems. This is not a problem in a ton of other areas where there actually is physicality, like hardware-only product development, where the cycle times are long. (Or at least not in the same way). But it is when you're doing traditional software-heavy product management.
Hope that helps. It was on-topic. It's just a difficult thing to write about in a simple way. Thanks for the feedback.
ADD: One of the things that makes this so difficult is the amount of invisible and many times unacknowledged work that happens. So you could ask a successful founder/Product Manager what their job and responsibilities were, and you'd get a list just like the one provided. Go out and try to execute on that list, though, and you'd screw it up.
How do I know? Because I went through them — started as a developer, turned to design, involved in business, started/exited few Startups, and continued to help Startups.
When I was in the engineering role, I thought everyone else was an idiot and “they don’t get it.” I thought that all the talks are useless when I can just go, write codes and get the “actual final thing done.” In my defense, I heard last time, some of my codes are still working on AT&T, Walt Disney to name a few.
When I realized that there are lots of engineers, who are much better than me, I jumped to designing and did a whole lot of designs too for many known brands, some unknown and many Startups during their early days, including few of our own. I sometimes see the logo of an established on billboards and I proudly claim, that was one of my early works and I designed that logo. I dabbled in designs before the development/engineering phase of my life. Because I can empathize with engineering, I became more lenient with my thought but I sometimes wondered, “let them program it but I’ll add the final beauty and that is what it sells.”
Then I got in love with business and once upon a time even closed deals worth multiple thousand dollars. By that time I began to realize the importance of every role
* the irritating salesperson is no longer irritating but began to fascinate me.
* loved working with a bunch of project manager that shield the team from the clients and cushion everything that came in hard.
* brilliant work by the business development team that makes life clearer for everyone to work on.
* and the product managers that lingers on to all the silly, nitty-gritty, boring work long after the engineers and the designers moved on “interesting challenges”.
Yes, everyone has a role and they play their part. If you play a role in the whole cycle, play your part and do it well. If you’re that good an engineer who can start from A and finish till the Z, then you’re already a good person and won’t say such thing as “xyz is useless because I’m abc.”
Any competent hire can be useful, but hiring good PMs is maybe even harder than good engineers. So people bitch.
Product manager is required job in any company that wants to grow and deliver best products. But these people are very hard to find and very expensive, so instead we hire PO and give them the title of PM and ask them to do what the CEO is asking
PM job can be thankless if you try to make everyone happy, and you've way more things to do with limited time.
As some have already mentioned, the PM is often the person who is kind of a "utility tool" within the departments. PMs have to be able to communicate effectively amongst each team, and translate each departments needs into positive action.
I have also noticed that a lot of answers here are saying that all you need is a competent engineering lead instead of a PM. I don't agree with this at all. Engineers are critical to the success of a product, there is no doubt about that. But they also are generally more of a hard-skills player in the development of the process. PMs often have to be able to translate the work of hard-skill colleagues into understandable insights for other stakeholders. Some may see this as frivolous, but you'd be surprised at how many times I've seen an engineer deliver a report in a way that was impossible to understand, and far from relatable.
While this post could literally be pages long, I am going sum up the final point here: PMs do the work that allows engineers and members of other departments to focus on their core responsibilities. Engineers don't always have the time to determine customer needs, assess market competition, develop sales strategy, move information through departments, or the many other tasks that are necessary to create a top-tier product. So before jumping to conclusions about Product Management responsibilities, be sure to do your homework and see what the best PMs have done to take their businesses into greener pastures.
In contrast, PM leadership role becomes crucial in an established product, or even a startup entering into the growth trajectory.
PM responsibilities vary wildly. Being able to sell, build relationship, be at the right place at the right time etc. decides your success more than your inbound skills like product requirements, planning etc.
There are a bunch of Product Managers, while a few good engineering leaders are leading the tech team.
My role is basically to groom the PMs to mostly talking to customers, say NO to the engineers' cool feature they want to build if they are not yet validated with customers, say NO to the C-Suite including the CEO of all their fancy cool business ideas they want to execute. Continue with mini-experiments, and build a process to do such repeatedly and rinse them well. Reduce the release cycle and hopefully automate pretty much everything.