What, exactly, is a Product Manager?
mindtheproduct.com
mindtheproduct.com
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.
It's hard, and "fluffy" at the same time :-)
I've been able to make it work over the years but it's not everyone's cup of tea, especially if you dislike politics.
(Oh, and in my view, none of the glory either - that's to be used to help achieve objectives, not self-promotion.)
It's a training document that Ben Horowitz wrote when he was at Netscape. More here: http://bhorowitz.com/2010/05/14/why-startups-should-train-th...
https://secure.wikimedia.org/wikipedia/en/wiki/Scrum_%28deve...
"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 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 can't believe it's been over a year since I submitted my article covering the same topic: http://news.ycombinator.com/item?id=1627668
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.
- 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.
What do I do to go from Software Engineer to Product Manager?
- 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.