Kind of fluffy. I always worry about descriptions of roles that seem more about selling the role than about the stuff the role owns; you worry about aspirants getting the words "product manager" on their b-card and then not doing anything, like what happened with "architects".
Product managers own most, often all, of:
* Customer outreach: The PM is ostensibly the one with routine scheduled calls to all the clients to collect feedback.
* Feature/function/benefit: the PM usually co-owns the roadmap with engineering, and the split is usually that the PM mostly owns the ordering of things on the roadmap, engineering owns the time estimates, PM describes the feature and the business benefits it solves --- both to customers and, when the job is done right, to engineering.
* Pricing and packaging (in a startup, the PM is probably going to own pricing; in a mature company, nobody is going to trust the PM to own the most important business decision about the product).
* Competitive analysis: the PM is who you blame if you get blindsided by a customer dropping your product for a competing offering.
In mature companies the PM role often ends here and is picked up on the other side by Marcom, who is in turn going to outsource the copywriting and design of white papers and sales material and websites. In a startup, you'd expect the PM is going to own the marcom stuff too.
For a startup, most of what Joel writes on Joel on Software, especially the earlier posts, is a record of the job of a small company product manager.
Yes, but in startups, being a PM is often very hard, because no one has to listen to you. So you need to bring your own credibility and influence so the product gets done properly.
Oh, definitely. Sorry, I sounded like I was criticizing the post. I really just want to make the case that PM is not a fluffy role. "Architect", "CTO", "advocate", "community manager", "evangelist", "information design" --- all carry fluffy connotations. PM owns nuts-and-bolts stuff that companies need to be doing, no matter who's doing them.
"The Product Owner represents the voice of the customer and is accountable for ensuring that the Team delivers value to the business. The Product Owner writes customer-centric items (typically user stories), prioritizes them, and adds them to the product backlog."
Rather than evangelizing the product in the community to gain funding with investors, it's about acquiring the resources and good will within the company. You still need all the skills to not necessarily create the product but rather know what it takes.
That being said, it's very safe. It's entrepreneurial just short of being an entrepreneur. I'd like to think it's the best position to gain experience for starting your own venture without actually developing/designing the product.
I've been working as a PM for the last 4 months and taken Pragmatic Marketing training as well.
I think the 'mini-CEO' analogy is an extremely flawed one that discounts a large portion of a CEO's job and marginalizes the real and very significant differences between even those parts that are similar. This is particularly the case CEO's of medium to large companies.
This isn't as true for CEO's of start-ups, but that is because the CEO will possibly be fulfilling the PM role as well, not so much that the PM role is like the CEO role.
However, I do agree with looking at it as an entrepreneurial role.
I've been at single-digit startups and *500 companies and entrepreneurial role fits the bill. I'd say in some cases they are the CEO of their own business unit with capacity for setting the product direction, selecting the team and establishing/punishing timetables. Usually in that case, they'll have X project managers under them carrying out instructions, but in the case of a small company they do usually sit somewhere between ops/tech/mktg and somehow guide with diplomacy.
I focused a little more on early stage startups, but a lot of the same rings through.
A lot of people have had experiences with bad product managers. From the feedback from my team, I don't think I fall into that camp. Here's why:
* I learn as much as I can about our technology stack. I try to understand what's hard and what's easy to build. I even write code for our app when I have a chance.
* I try to remove blockers so everyone else can do their job better.
* I give anyone on the team the opportunity to comment on the work that I'm doing. Nothing we're building is ever a surprise.
* I make our longer term goals clear and try to show how what we're building this week gets us closer.
I've never worked with bad product managers. I've always been the lone product manager on a team and have taught myself how to do the job well. It's something I enjoy doing, but can be pretty stressful. Ultimately, the buck stops with me and the success or failure of the execution of the product is on my shoulders.
Product manager, IMHO, is an owner of a product and therefore responsible for the success of the product. That means the role and responsibility of a product manager touch on many aspects of product development and delivery. I have been a product manager at a social gaming and a web company, so my answers have to do more with such space.
- Own analytics. Don't trust qualitative stuff, but trust quantitative stuff. Track important metrics and monitor performance. One of the metrics should be revenue generation.
- Do many experiments on subset or all users. This is our way of finding out what customers want. First is intuition, but verify it with experiments.
- Own and prioritize specs and stories (in agile dev sense). This is where the cross with business part comes in and kinda obvious. Spec/story priorities should align with business objectives.
- User acquisition and retention. This part touches on marketing part. How to get new users? How to retain users? Social media? Email campaigns? Contests? Sweepstakes? Partnership?
- Etc., etc., etc.
But, ultimately, PM is responsible for success of product(s) s/he manages, and thus do whatever is necessary to make it happen.
Nope, that's not true at every company. In some companies PMs are part of the business unit, at others they're part of the engineering organization, and sometimes they form their own organization that sits in between engineering and business. There's no one right way to do it.
I'd argue that the first PM hire at a startup should report directly to the CEO since it's likely that the PM will act as the proxy for the business (and by extension the customer). At the same time, I'm seeing an increasing trend toward PMs with technical skills -- my guess is that within a few years it will not be possible to succeed in a PM role without at least some hands-on technical experience.
I made this transition a few months ago. To be honest, I was called up by a recruiter, but I think the following led up to that call:
- Be open to non-engineering roles, possibly to the point of actively seeking them out.
- Having and showing an interest in the industry I work in. Product managers are focused on solving customer and business problems in ways that create value and solve pain points for the customer and make money for the business.
- Developing a sense not only of the best technical solution to a problem, but also what business opportunities that solution opens up. Even when answering technical interview positions for my new job I would always back up a level and explore some other possibilities or motivations.
- Learn to communicate potentially technical information to non-technical people. By this I mean concisely expressing problems, hiding details that aren't immediately important, translating "side effects" into consequences.
- Demonstrate an ability to dig deeper into customer motivations and needs. They will often express what they want in terms of what is immediately visible. Sometimes you have to dig deeper so that you can come up with a design that solves their real underlying problem.
Not necessarily. This depends on the companies one is leaving and going to. Sure, if you are leaving an engineering position at Facebook or Google, this is probably true. Amongst young but not newborn startups, it could very well be a bump in pay depending on background and experience.
Well-well look. I already told you: I deal with the god damn customers so the engineers don't have to. I have people skills; I am good at dealing with people. Can't you understand that? What the hell is wrong with you people?
Product manager: coordinating officer, delegating company divisional chores / From manufacturing to vacuum-wrapping packaging, a model of corporate exacti-ture / He's pre-eminent -- isn't it evident? -- as his title infers / His word is law, yes it's an advantage / if he's managing the product that is yours
I'd love to see a post from someone(s) about "What, exactly, is a great Product Manager?". I've worked with good, bad and ugly but never a great one. Either that or I wouldn't recognize a great one out of my own ignorance.
Product managers own most, often all, of:
* Customer outreach: The PM is ostensibly the one with routine scheduled calls to all the clients to collect feedback.
* Feature/function/benefit: the PM usually co-owns the roadmap with engineering, and the split is usually that the PM mostly owns the ordering of things on the roadmap, engineering owns the time estimates, PM describes the feature and the business benefits it solves --- both to customers and, when the job is done right, to engineering.
* Pricing and packaging (in a startup, the PM is probably going to own pricing; in a mature company, nobody is going to trust the PM to own the most important business decision about the product).
* Competitive analysis: the PM is who you blame if you get blindsided by a customer dropping your product for a competing offering.
In mature companies the PM role often ends here and is picked up on the other side by Marcom, who is in turn going to outsource the copywriting and design of white papers and sales material and websites. In a startup, you'd expect the PM is going to own the marcom stuff too.
For a startup, most of what Joel writes on Joel on Software, especially the earlier posts, is a record of the job of a small company product manager.