How to be a good PM.
January 16, 2008 8:41 AM Subscribe
Help me be a good product manager.
Rather to my surprise, I have ended up in a product management role at a very large tech company. I'm not going to be managing major release and products, but for about 50% of my time I'll be looking after smaller projects, mostly internal-facing.
I'll be working with hard-core engineers who are experts in their field. I am deeply interested in technology, but I'm not a programmer by any stretch. I can easily grasp technical concepts when someone explains them to me, or understand why a potential technical solution is not possible, for example. But I would have no idea at all of the relative merits of Java vs Perl and so on.
What I bring to the table is a deep understanding of our internal and external customers' needs, and lots of ideas for how we can do things better.
I see my role as either defining or helping define the vision of the product we ultimately want, working with the engineering teams to define what is actually possible, working with the business teams to make sure what we can deliver will meet their needs, and then creating an environment where the engineers can deliver the product as quickly as possible (protecting them from sales management intrusion, endless additional feature requests etc).
What I don't want to do is become a Pointy-Haired Boss and alienate or antagonise the eng teams. If it's relevant, my own background is an undergrad in mechanical engineering, a few years in journalism, and three years in this company.
So for any engineers or PMs or similar out there - do you have any thoughts, experiences, anecdotes, book recommendations or anything else that might help me be a good PM?
Thanks MeFites.
Rather to my surprise, I have ended up in a product management role at a very large tech company. I'm not going to be managing major release and products, but for about 50% of my time I'll be looking after smaller projects, mostly internal-facing.
I'll be working with hard-core engineers who are experts in their field. I am deeply interested in technology, but I'm not a programmer by any stretch. I can easily grasp technical concepts when someone explains them to me, or understand why a potential technical solution is not possible, for example. But I would have no idea at all of the relative merits of Java vs Perl and so on.
What I bring to the table is a deep understanding of our internal and external customers' needs, and lots of ideas for how we can do things better.
I see my role as either defining or helping define the vision of the product we ultimately want, working with the engineering teams to define what is actually possible, working with the business teams to make sure what we can deliver will meet their needs, and then creating an environment where the engineers can deliver the product as quickly as possible (protecting them from sales management intrusion, endless additional feature requests etc).
What I don't want to do is become a Pointy-Haired Boss and alienate or antagonise the eng teams. If it's relevant, my own background is an undergrad in mechanical engineering, a few years in journalism, and three years in this company.
So for any engineers or PMs or similar out there - do you have any thoughts, experiences, anecdotes, book recommendations or anything else that might help me be a good PM?
Thanks MeFites.
Also, the cardinal rule: "If it isn't written down, it doesn't exist."
posted by Caviar at 9:18 AM on January 16, 2008
posted by Caviar at 9:18 AM on January 16, 2008
Best answer: I'm an software engineer, not a PM, but I have some suggestions based on my experience.
Find some good books on how software development works. The Mythical Man Month is a great example. You also might want to read a book about a specific aspect of software engineering that your team may or may not use, such as Object Oriented Design or Extreme Programming. Any information you get will be helpful, so I would say just pick up any book related to what your teams will be doing. Also, ask some of your team members if they have any recommendations.
I see my role as either defining or helping define the vision of the product we ultimately want,
Make sure that you involve the actual end-users in the process as much as possible. One of the most common ways projects end up failing is that the solution is built properly but the customer ends up finding out that it does not actually meet their needs. Many times the best way to get the best solution is to do interviews and observation of the future users before the solution is designed, and have one or more prototype solutions that the users can test at some point during development.
working with the engineering teams to define what is actually possible,
You should probably take a backseat in this part of the process more than anything else. The engineers will need to be able to define this without much help from you. You should mostly just collect their findings in an organized way. Also, make sure you get time and cost estimates for all of the possibilities being considered.
working with the business teams to make sure what we can deliver will meet their needs,
Again, make sure that the end-user's needs are considered at this point.
and then creating an environment where the engineers can deliver the product as quickly as possible (protecting them from sales management intrusion, endless additional feature requests etc).
This is probably your most important role. You need to handle all of the political stuff and set priorities for your team. You'll also need keep track of all of the deliverables and send out status reports periodically to make sure any external customers are aware of any changes in the schedule.
In general, you need to balance representing your team and their concerns with representing the business and the business needs. Make sure that your team trusts you and knows you are representing them well, but at the same time make sure that any of the business customers know that you are trying to get the product out on-time and under budget.
posted by burnmp3s at 9:20 AM on January 16, 2008
Find some good books on how software development works. The Mythical Man Month is a great example. You also might want to read a book about a specific aspect of software engineering that your team may or may not use, such as Object Oriented Design or Extreme Programming. Any information you get will be helpful, so I would say just pick up any book related to what your teams will be doing. Also, ask some of your team members if they have any recommendations.
I see my role as either defining or helping define the vision of the product we ultimately want,
Make sure that you involve the actual end-users in the process as much as possible. One of the most common ways projects end up failing is that the solution is built properly but the customer ends up finding out that it does not actually meet their needs. Many times the best way to get the best solution is to do interviews and observation of the future users before the solution is designed, and have one or more prototype solutions that the users can test at some point during development.
working with the engineering teams to define what is actually possible,
You should probably take a backseat in this part of the process more than anything else. The engineers will need to be able to define this without much help from you. You should mostly just collect their findings in an organized way. Also, make sure you get time and cost estimates for all of the possibilities being considered.
working with the business teams to make sure what we can deliver will meet their needs,
Again, make sure that the end-user's needs are considered at this point.
and then creating an environment where the engineers can deliver the product as quickly as possible (protecting them from sales management intrusion, endless additional feature requests etc).
This is probably your most important role. You need to handle all of the political stuff and set priorities for your team. You'll also need keep track of all of the deliverables and send out status reports periodically to make sure any external customers are aware of any changes in the schedule.
In general, you need to balance representing your team and their concerns with representing the business and the business needs. Make sure that your team trusts you and knows you are representing them well, but at the same time make sure that any of the business customers know that you are trying to get the product out on-time and under budget.
posted by burnmp3s at 9:20 AM on January 16, 2008
IMO, PM's at tech companies almost always work out better when they come from technology rather than marketing, so it seems like you're already off to a good start.
Also, the sales and marketing side of a company will always expect political shenanigans to go on, but developers are (often rightly) a paranoid lot with elephantine memories. Get an early win with them, however small- push back a date, axe a feature they're whining about. This will be remembered long-past the grumbling of your sales guys.
posted by mkultra at 9:26 AM on January 16, 2008 [1 favorite]
Also, the sales and marketing side of a company will always expect political shenanigans to go on, but developers are (often rightly) a paranoid lot with elephantine memories. Get an early win with them, however small- push back a date, axe a feature they're whining about. This will be remembered long-past the grumbling of your sales guys.
posted by mkultra at 9:26 AM on January 16, 2008 [1 favorite]
As I always say, the most important sentence for project/account managers is "I’ll get back to you with an answer when I’ve spoken to the developers."
You should find yourself using it a lot.
posted by malevolent at 9:27 AM on January 16, 2008
You should find yourself using it a lot.
posted by malevolent at 9:27 AM on January 16, 2008
Include your developers in your time estimation process.
I can't second this highly enough. It sounds like a total duh, but one of my leads tends to pop in and say, "I know you say you needed N weeks to do this, but can you do this in N-4 weeks?", not leave your cube until you say okay, and calls himself a fair boss. [He means well. I think.] Result: every single one of our current projects is at least 2 weeks past deadline.
I guess what I'm saying is don't just pay lip service to the engineers when you include them in the loop. If they say it's going to take N weeks, it's going to take N weeks, possibly 1.3N weeks.
posted by universal_qlc at 9:37 AM on January 16, 2008
I can't second this highly enough. It sounds like a total duh, but one of my leads tends to pop in and say, "I know you say you needed N weeks to do this, but can you do this in N-4 weeks?", not leave your cube until you say okay, and calls himself a fair boss. [He means well. I think.] Result: every single one of our current projects is at least 2 weeks past deadline.
I guess what I'm saying is don't just pay lip service to the engineers when you include them in the loop. If they say it's going to take N weeks, it's going to take N weeks, possibly 1.3N weeks.
posted by universal_qlc at 9:37 AM on January 16, 2008
Always add at least an extra 20% to your projected schedule for mistaken assumptions and unidentified snafus.
Please, please don't disregard this particular bit of advice. In fact, when I was going through internal PM training they told us the magic number for overbudget in-house projects was 18%.
posted by fusinski at 10:01 AM on January 16, 2008
Please, please don't disregard this particular bit of advice. In fact, when I was going through internal PM training they told us the magic number for overbudget in-house projects was 18%.
posted by fusinski at 10:01 AM on January 16, 2008
I moved into a product management role a year ago after 18 years working in various I.T. operations roles. I could type for about a week on this subject about my experiences over the past year, but there was one thing that jumped out at me in your post:
What I bring to the table is a deep understanding of our internal and external customers' needs, and lots of ideas for how we can do things better.
This is a very positive attitude to have about your new job. However, I can tell you from recent personal experience that you have NO IDEA YET what your internal and external customers' needs are. You may think you know, but take it from me, you don't. You're going to go onsite with a customer and they're going to challenge every single idea you had about what your customers' needs are. You may think you know what people need (I sure did), but trust me, you're not even close. I've heard the same thing from every product manager in my division, as well.
My advice to you is: keep an open mind, and be willing to have your ideas challenged. I've found that my customers have some incredibly smart people on their staffs, and their opinions and advice has been positively invaluable to me.
Oh, and your best feedback is going to come from the customers that are REALLY pissed off at you. Negative feedback is your best friend in this job. As a product manager, I LIKE getting yelled at - it's the only way I learn anything.
posted by deadmessenger at 10:52 AM on January 16, 2008
What I bring to the table is a deep understanding of our internal and external customers' needs, and lots of ideas for how we can do things better.
This is a very positive attitude to have about your new job. However, I can tell you from recent personal experience that you have NO IDEA YET what your internal and external customers' needs are. You may think you know, but take it from me, you don't. You're going to go onsite with a customer and they're going to challenge every single idea you had about what your customers' needs are. You may think you know what people need (I sure did), but trust me, you're not even close. I've heard the same thing from every product manager in my division, as well.
My advice to you is: keep an open mind, and be willing to have your ideas challenged. I've found that my customers have some incredibly smart people on their staffs, and their opinions and advice has been positively invaluable to me.
Oh, and your best feedback is going to come from the customers that are REALLY pissed off at you. Negative feedback is your best friend in this job. As a product manager, I LIKE getting yelled at - it's the only way I learn anything.
posted by deadmessenger at 10:52 AM on January 16, 2008
The best bit of software created or modified in-house at a company I've worked with is the *one* piece of software that the users were truly proactive about. Granted, in this case the users were pretty technical, but this is what they did:
Well, the chances are good that your users have been on the receiving end of project before. They have dealt with everything from awful stuff to good stuff - and they probably don't ever want to deal with awful stuff again.
Just get the users to work with you to define use cases, workflows and a few gui mockups (if there's a gui). The users will end up feeling pleased that they're being paid attention, and your developers/engineers can move forward knowing what actually needs to be delivered. When everyone is on the same page, lots of problems disappear.
posted by terpia at 12:06 PM on January 16, 2008
- put together screen by screen walk-through of the current program and workflow.
- put together screen by screen photshop/visio/ms access* mock-ups of every gui screen
- decided on all reasonable use-cases, and then wrote a summary and a workflow for each
- defined a last-day-of-project "go or no go" list. (the project wouldn't be pushed live without these items)
- Created 300 mock records, using actual (but anonymized) data from the current system for the developers to work with
- delivered soft copies of all data one day before meeting with developers
- delivered hard copies and case of beer to the developers in the initial meeting
- made sure that the initial meeting was well before the project had approval, allowing the developers to provide honest feedback on the feasibility.
- Graciously and voraciously accepted feedback on the plan, and made modifications.
- sought and won approval for project from the mangers & PMs
- jumped on something immediately, whenever a developer asked, throughout the duration of the project.
Well, the chances are good that your users have been on the receiving end of project before. They have dealt with everything from awful stuff to good stuff - and they probably don't ever want to deal with awful stuff again.
Just get the users to work with you to define use cases, workflows and a few gui mockups (if there's a gui). The users will end up feeling pleased that they're being paid attention, and your developers/engineers can move forward knowing what actually needs to be delivered. When everyone is on the same page, lots of problems disappear.
posted by terpia at 12:06 PM on January 16, 2008
13 years in product management here. Big companies and small companies.
From your post, it looks like you'll do grand as a product manager. As far as it describes, you've got what it takes.
I recognize a developer's viewpoint of what a product manager should be in a lot of the previously posted material. This is very important. I have heard similar comments from development leads I have worked with.
Some of the best product managers I know strike the right balance between the customer's requests and the abilities of the team. Each is very important. You need to recognize right away if you are talking to a customer or a team member and tune yourself accordingly. You need to make commitments to customers that you know the team will follow through with. Likewise, you need to make commitments to the team that you know the customers will follow through with (along the lines of, "if we build widgets as this document I wrote describes, the customer will buy the number of widgets the document says they will."). This leads to a successful team, promotions all around and huge salaries. Or not.
I've never met a good book about product management.
And as far as time estimation, I have had the most success with the following: understand as much as possible what is to be delivered, take your initial goal (such as 2 weeks to complete a task), double it, then double it again. Try it for yourself and see how well it works.
posted by tdogboy at 12:06 PM on January 16, 2008
From your post, it looks like you'll do grand as a product manager. As far as it describes, you've got what it takes.
I recognize a developer's viewpoint of what a product manager should be in a lot of the previously posted material. This is very important. I have heard similar comments from development leads I have worked with.
Some of the best product managers I know strike the right balance between the customer's requests and the abilities of the team. Each is very important. You need to recognize right away if you are talking to a customer or a team member and tune yourself accordingly. You need to make commitments to customers that you know the team will follow through with. Likewise, you need to make commitments to the team that you know the customers will follow through with (along the lines of, "if we build widgets as this document I wrote describes, the customer will buy the number of widgets the document says they will."). This leads to a successful team, promotions all around and huge salaries. Or not.
I've never met a good book about product management.
And as far as time estimation, I have had the most success with the following: understand as much as possible what is to be delivered, take your initial goal (such as 2 weeks to complete a task), double it, then double it again. Try it for yourself and see how well it works.
posted by tdogboy at 12:06 PM on January 16, 2008
Doh! I left out the explanation for the * next to MS Access.
Despite the application not having anything to do with MS Access, it proved to be a surprisingly good tool for basic gui mockups when using design view. Nothing needs to be behind the buttons and fields one adds in design view and it's relatively easy for most tech-competent users to poke around with.
posted by terpia at 12:10 PM on January 16, 2008
Despite the application not having anything to do with MS Access, it proved to be a surprisingly good tool for basic gui mockups when using design view. Nothing needs to be behind the buttons and fields one adds in design view and it's relatively easy for most tech-competent users to poke around with.
posted by terpia at 12:10 PM on January 16, 2008
In terms of scheduling projects - I found this article from Joel on Software, outlining Evidence Based Scheduling, to be great. I am in the same situation in trying to plan for and create schedules for internal software that has never been created before.
Oh and the other advice as a PM - let people know about upcoming work as soon and as often as you can.
posted by clarkie666 at 12:40 PM on January 16, 2008
Oh and the other advice as a PM - let people know about upcoming work as soon and as often as you can.
posted by clarkie666 at 12:40 PM on January 16, 2008
You might try checking out some of the training available leading to certification as a Project Management Professional (PMP) through the Project Management Institute
posted by Pressed Rat at 2:09 PM on January 16, 2008
posted by Pressed Rat at 2:09 PM on January 16, 2008
Another good practical PM book:
The Art of Project Management, by Scott Berkun.
posted by bumpybear at 7:40 PM on January 16, 2008 [1 favorite]
The Art of Project Management, by Scott Berkun.
posted by bumpybear at 7:40 PM on January 16, 2008 [1 favorite]
Reading some of the comments here is triggering one of my pet peeves. StephenF was asking for advice on how to be a good product manager, not a good project manager, and they're NOT the same thing.
Although product managers occasionally have *some* project-management responsibilities, product management and project management are completely different disciplines, with very different responsibilities and requisite skillsets.
posted by deadmessenger at 8:54 AM on January 17, 2008
Although product managers occasionally have *some* project-management responsibilities, product management and project management are completely different disciplines, with very different responsibilities and requisite skillsets.
posted by deadmessenger at 8:54 AM on January 17, 2008
How can they be completely different if there's some overlap?
posted by Caviar at 9:22 AM on January 17, 2008
posted by Caviar at 9:22 AM on January 17, 2008
Best answer: IAAPM. Ok, let's see what we can do here. This is going to be a 5-minute brain-dump, as I have a meeting, but I'll see what I can do.
Training
If you can get training, do it. I highly recommend the seminars put on by the Pragmatic Marketing folks. Their system has its flaws, but for getting into the swing, they can't be beat.
Also, you really need a good mentor. They can't be beat.
Books
This is what I read, and enjoyed, in my first year as a PM. Some of these are still references.
The Effective Executive
Drucker is the king of management gurus. If it's management, it's influenced by him.
The Art of Profitability
Set aside some time for this one. It takes the form of a series of weekly lessons with a mentor. I recommend you follow the format yourself, and do the assignments. I got a lot of value out of this approach.
Differentiate or Die
What is differentiation? You may be surprised... Trout is mouthy and opinionated, but his perspective is extremely valuable.
The Market Research Toolbox
You'll want to research. You won't have money. You'll have to know what's effective, when.
Voices into Choices
Talk to customers. It's your job, in a nutshell. But don't just chat, have a plan. I disagree with 70% of this book, but it encourages a mindset that is necessary.
How to Drive Your Competition Crazy
They'll do it to you. Guy is a bit cheesy for my taste, at times, but he's full of ideas.
Competitors
Understand the tactics.
Marketing Warfare
Ditto.
The Strategy and Tactics of Pricing
Pricing is the single most important thing you will be asked to do for your business.
The Price Advantage
This one's not for the feint of heart, but it can't be beat. I referenced it today.
Positioning
All of the Trout books sort of bleed together, but there are a few nuggets in this worth finding.
The Channel Advantage
Channels. If you have them, you need to understand them. If you don't have them, you need to understand why.
Blue Ocean Strategy
One solid market innovation is worth ten killer also-rans. I particularly liked the anecdote about the Cirque du Soleil.
The Inmates Are Running the Asylum
Personas [sic] are one of the most powerful design tools you can master. However, you really need to master them, and that takes time and painful experience. Cooper doesn't recommend basing your personas on real customer data, but you should. Keep it in mind.
The Deadline
This one's a fun read. It's written like a fictional account, and there are some good lessons here. I particularly liked the bit about the confessional. I don't do that, but I have created a similar effect.
Blogs
Seth Godin
Seth is full of crap. That having been said, his mind is going non-stop, and if even 10% can ignite a spark in your brain, he's done his job.
Product Marketing Blog
From the folks at Pragmatic Marketing
Guy Kawasaki
He's widely revered for being a start-up badass, but I like him for his presentations. Also, be forewarned that he uses his blog to promote his investments. Shady, but whatever.
Product Personas [sic]
This is the companion blog to the Inmates book referenced above. Not by the same author, but it's all about the same topic - personas.
On Product Management
Pretty self-explanatory.
Joel on Software
Joel is generally regarded as having one of the most consistently interesting opinions in the world of software development. I don't always agree, but I do generally have to think about it.
How to be a Good Product Manager
This is written as a contrast - good Prod Mgrs do this, bad ones do that. Not too earth-shattering, but I use it as a weekly reminder about good habits that I may have let fall by the way-side.
The Cranky Product Manager
Oh, she's cranky. And fun.
Presentation Zen
Become good at presenting. If you work in a corporation, most of these ideas are not directly applicable. But you can try, and you should.
Podcasts
Manager Tools
A great podcast for the basics of everyday management. It doesn't look like you have directs yet, so pick and choose the podcasts that look interesting to you. You will be leading cross-functional (matrix) teams, so you need to be able to deal with people and conflicts.
Project Management Podcast
I'm not crazy about this one, but some people really dig it. YMMV.
The Welch Way
Jack. He's a legend, and he will tell you so. Still, this is a great bit of mental hygiene, to help you focus on the big picture, and what's going on in the real world. Plus, it's fun to do impressions of him with your friends and coworkers.
Killer Innovations
This guy has set out a rigorous system for innovating. Start at the beginning, and learn from someone who has taken the time to convert and art into a science.
I'm leaving out a ton of stuff. You can send me a message, and I will send you my email.
posted by rush at 1:31 PM on January 17, 2008 [8 favorites]
Training
If you can get training, do it. I highly recommend the seminars put on by the Pragmatic Marketing folks. Their system has its flaws, but for getting into the swing, they can't be beat.
Also, you really need a good mentor. They can't be beat.
Books
This is what I read, and enjoyed, in my first year as a PM. Some of these are still references.
The Effective Executive
Drucker is the king of management gurus. If it's management, it's influenced by him.
The Art of Profitability
Set aside some time for this one. It takes the form of a series of weekly lessons with a mentor. I recommend you follow the format yourself, and do the assignments. I got a lot of value out of this approach.
Differentiate or Die
What is differentiation? You may be surprised... Trout is mouthy and opinionated, but his perspective is extremely valuable.
The Market Research Toolbox
You'll want to research. You won't have money. You'll have to know what's effective, when.
Voices into Choices
Talk to customers. It's your job, in a nutshell. But don't just chat, have a plan. I disagree with 70% of this book, but it encourages a mindset that is necessary.
How to Drive Your Competition Crazy
They'll do it to you. Guy is a bit cheesy for my taste, at times, but he's full of ideas.
Competitors
Understand the tactics.
Marketing Warfare
Ditto.
The Strategy and Tactics of Pricing
Pricing is the single most important thing you will be asked to do for your business.
The Price Advantage
This one's not for the feint of heart, but it can't be beat. I referenced it today.
Positioning
All of the Trout books sort of bleed together, but there are a few nuggets in this worth finding.
The Channel Advantage
Channels. If you have them, you need to understand them. If you don't have them, you need to understand why.
Blue Ocean Strategy
One solid market innovation is worth ten killer also-rans. I particularly liked the anecdote about the Cirque du Soleil.
The Inmates Are Running the Asylum
Personas [sic] are one of the most powerful design tools you can master. However, you really need to master them, and that takes time and painful experience. Cooper doesn't recommend basing your personas on real customer data, but you should. Keep it in mind.
The Deadline
This one's a fun read. It's written like a fictional account, and there are some good lessons here. I particularly liked the bit about the confessional. I don't do that, but I have created a similar effect.
Blogs
Seth Godin
Seth is full of crap. That having been said, his mind is going non-stop, and if even 10% can ignite a spark in your brain, he's done his job.
Product Marketing Blog
From the folks at Pragmatic Marketing
Guy Kawasaki
He's widely revered for being a start-up badass, but I like him for his presentations. Also, be forewarned that he uses his blog to promote his investments. Shady, but whatever.
Product Personas [sic]
This is the companion blog to the Inmates book referenced above. Not by the same author, but it's all about the same topic - personas.
On Product Management
Pretty self-explanatory.
Joel on Software
Joel is generally regarded as having one of the most consistently interesting opinions in the world of software development. I don't always agree, but I do generally have to think about it.
How to be a Good Product Manager
This is written as a contrast - good Prod Mgrs do this, bad ones do that. Not too earth-shattering, but I use it as a weekly reminder about good habits that I may have let fall by the way-side.
The Cranky Product Manager
Oh, she's cranky. And fun.
Presentation Zen
Become good at presenting. If you work in a corporation, most of these ideas are not directly applicable. But you can try, and you should.
Podcasts
Manager Tools
A great podcast for the basics of everyday management. It doesn't look like you have directs yet, so pick and choose the podcasts that look interesting to you. You will be leading cross-functional (matrix) teams, so you need to be able to deal with people and conflicts.
Project Management Podcast
I'm not crazy about this one, but some people really dig it. YMMV.
The Welch Way
Jack. He's a legend, and he will tell you so. Still, this is a great bit of mental hygiene, to help you focus on the big picture, and what's going on in the real world. Plus, it's fun to do impressions of him with your friends and coworkers.
Killer Innovations
This guy has set out a rigorous system for innovating. Start at the beginning, and learn from someone who has taken the time to convert and art into a science.
I'm leaving out a ton of stuff. You can send me a message, and I will send you my email.
posted by rush at 1:31 PM on January 17, 2008 [8 favorites]
« Older Creating an easy-to-import photo archive for... | How do I create a TV schedule based on a topic? Newer »
This thread is closed to new comments.
posted by Caviar at 9:17 AM on January 16, 2008 [2 favorites]