Product Management and Project Management are two different jobs that often get confused

Ok, so how many times has this occurred: someone asks you what you do for a living and you tell them that you are a Product Manager and they fire back at you “Oh, so you manage projects?”. Grrr, it’s really no fair – the two disciplines really have nothing in common. Well, wait a minute, maybe they do. No, no they really are different. Dang it. What’s the difference between the two?

A lot of the confusion comes from the simple fact that the two jobs do share a lot of things in common. However, never fear, they really are completely different no matter what your friends or your boss tell you. In a nutshell, the differences fall into three different categories: scope, execution, and results.

Scope: A project manager has the somewhat enviable benefit of having the hope of there existing clear cut boundaries that define what he/she is responsible for. They are responsible for a project that uses resources, has a schedule, and has a clear set of deliverables. A successful product manager on the other hand has a less defined job of creating a successful product. The product will be driven by not so much a set of requirements, but rather a customer need which may be fickle and change over time. A product manager has to be able to see through requirements and determine what the root cause of the customer’s issue is and create a product that solves that.

Execution: The project manager is responsible for basically reporting on the status of the project and he/she has a whole host of tools to do this with. However, the project manager is not responsible for designing the product. In fact the project manager does not have to be a subject matter expert – they can mange projects that they know nothing about the underlying technology. A Product Manager on the other hand desperately needs to know everything about how the product works. They need to know the motivation behind every design decision so that they can explain it in non-technical terms to a customer. A product manager is going to have to be able to sell (something a project manager never has to do) his/her product to others both internally and externally.

Results: How is a project manager judged? If a project follows a set schedule, delivers what was requested when it was promised and does not exceed its budget, then it is considered to have been a success. Basically, the less attention a project attracts, the more successful it is deemed to have been. The product manager on the other hand is expected to have created a product efficiently (similar to a project manager’s project), but has the additional burden of having to be successful no matter if it is delivered to an internal or external customer. If the product is a runaway success and gets lots of vocal praise from the customer than the product manager is deemed to have done a good job.

Yes, there are a lot of similarities between the jobs. However with due respect to both project managers and product managers, you can’t switch them around and expect success. Product Management really does require a special set of skills – it’s an art, not a science.

Have you ever been confused with a project manager? Does anyone in your family really understand what you do for a living? How do you get along with project managers – are you friendly or bitter enemies? Leave a comment and let me know what you think.

Tags: project, project management, product management, IT Product manager, product manager jobs

No related posts.

One of the key differences between a product manager and a project manager is that a product manager truly needs to motivate others to do work for him/her. A project manager can get away with just reporting on the current status of a project, a product manager needs to make that product successful. High-commitment, high-performance (HCHP) IT leaders realize this and have come to realize that they won’t be able to be successful unless they can find a way to create a purpose that can be shared across the entire product team.

As our product teams spread out farther and farther across the globe, our ability to create this sense of shared purpose become even more difficult. Product teams that are successful have to share more than just a common employer. Their IT leaders have to spend a lot of time, energy, and effort in creating a shared purpose that will have an emotional appeal to each member of the team. This can go a long way in developing an entrepreneurial spirit within the team. How’s that for a real soft skill? Every successful shared purpose has the same three components:

• it allows the employees to create a better world in which to live in,
• it allows them to deliver performance that they can all be proud of, and
• by subscribing to it they will be able to be in an environment in which they can personally grow.

Each component of this type of shared purpose both helps the firm as well as acts as a powerful motivation tool for the employees working on the product.

Creating a better world in which to live in. Although we may all be working together on a product, what are we doing to improve the world in which we live in? This can take several different forms. Doing work in the community as a team, collecting funds to help people in remote areas, etc. all allow the team to pull together on an issue that is outside of work. However, this bonding then spills over and ties the team together more closely.

Deliver performance that they can be proud of. If the product team is not being recognized as a high performance team, then the people working on that team won’t be getting fulfillment from participating. At the end of the day, the best workers really want to work with the other best workers. If it is at all possible for a product manager to choose who works on their product, then by all means select only the best workers. If not, then you need to find ways to get peak performance out of your team.

Be in an environment in which they can personally grow. Ultimately we all want to have an opportunity to reach our own personal peak potential. The only way to do this is to ensure that the job of every person who is working on the product is both personally fulfilling and one that they can get excited about. What this means for a product manager is that you need to be constantly be working to ensure that everyone on the product team is being challenged and has opportunities to grow.

Whew! Being one of these HCHP leaders sure seems like a lot of work. All this discussion about what they have to do and we’re not even done yet. Next time we’ll talk about how you can keep it all in perspective…

How do you build a sense of shared perspective for your product teams? Have you ever tried to get the team to work together on a task that was outside of work – how did that go? Do you feel that it is your job to make sure that everyone on your product team is being challenged or do you think that that is the job of other mangers and HR?

Tags: purpose, project management, product manager, performance, personal growth

No related posts.

Who would have ever guessed that a big chunk of the art of product management would revolve around your ability to make good guesses? We like to call it estimating; however, at the end of the day it’s really guessing. The cruel fact of life is that he/she who does the best (most accurate) job of guessing wins the raise, promotion, undying gratitude of the big boss, etc.

So just how does one go about learning this black art of estimating? Well back when I was first starting out as a Product Manger I was working with a coworker named Dave. I can clearly remember working until the wee hours of the night trying to pull together the product business plans for the next year. Dave was doing the same thing, but he seemed to be going home on time each evening. I on the other hand was staying and building elaborate Excel models in an attempt to estimate budget, staffing, and time required to complete these business plans.

Dave and I both reported to the same manager who had been around the block countless times. When we turned in our product plans my boss took a look through Dave’s, grunted, and put them down on his desk. Next he looked through mine, didn’t say anything for the longest time, and then finally looked at me and said: …your estimates are all way too low. Talk about being crushed! On our way back to our desks, I turned to Dave and asked him how he did it. I mean I had put in the time, built the Excel models, and done everything with engineering precision. Yet, somehow I had missed the mark. What was his secret?

Dave then told me something that I have used to this very day. He told me that he really wasn’t very good at estimating anything. However, he had taken the time to study WHY his estimates were wrong. It turns out that his estimates were consistently about 1/2 of what they should have been. How did he solve this problem? Simply by doubling every estimate that he created. Poof – that allowed him to be on the mark every time! I took Dave’s advice, doubled my estimates and took them back to my boss. This time around he grunted and accepted my business plans.

So what does this mean to you – should you just start doubling your estimate? NO! Instead, what you need to do is to pick one or more of your estimates and collect metrics on how that project actually ended up costing. What you’ll find is that you are probably off by the same amount each time (you will always be off!). This is the magic estimate number for you. Some of us estimate high, some low. but we all seem to do it constantly. My friend Dave has stayed with that firm and is now an Executive Director in the Marketing department. I’ve moved on; however, I still use his rule to create accurate estimates.

Does this approach cause chills to run up your spine? Would you be able to create an estimate without a complex Excel spreadsheet to back it up? Speak up and let me know what you think the best way for Product Managers to create estimates is.

Tags: estimates, project management, costs, pricing, staffing

No related posts.

The late George Carlin became famous thanks to a skit that he did titled “The 7 Words That You Can’t Say On Television”. I’m thinking that he missed a word — RISK. Why should this be added to the list you say? Simple — nobody dares to say it out loud!

A couple of university professors, Charalambos Iacovou and Robbie Nakatsu, recently decided to do the unthinkable: look into just how risky pushing IT development projects offshore really is. Although this type of discussion is normally what project managers stay up nights worrying about, at the end of the day if there are problems, then Product Mangers are going to be in trouble also. That means that offshore project risk is everyone’s problem.

I know that I’ve worked for several companies that viewed offshoring as a great new black box: drop a project in one side of the box and magically a completed IT product should pop out the other side. As anyone who has working on an offshore project knows, it never happens that way. The two professors reached out and talked with 15 project managers who had experience with offshore projects. They asked them a bunch of questions and got some interesting answers. The biggest revelation was:

There’s nothing earthshaking there (sorry to readers in southern California); however, the project managers that were surveyed provided some interesting reasons for why this is true. Here are the top 3 reasons that offshored projects run into problems:

• #1: Lack of Top Management Commitment
  I like to call this one “out of sight, out of mind”. The immense amount of effort that goes into setting up an offshoring contract often results in senior management viewing the development problem as being “solved” and they move on to other more pressing issues. Without their involvement, the offshore vendor can start to not do what you need done.

• #2: Original Set Of Requirements Is Miscommunicated
  One of the project managers said it perfectly: … you will get exactly what you asked for, so you better make sure you are asking for exactly the right thing. Every single product that I have managed has started with only partial requirements that pretty much all changed during the product development process. Even the thought of trying to deliver a complete set of requirements to an offshore team at the start of a project makes me laugh — it just can’t be done.
• #3: Language Barriers In Project Communications
  We’re not talking about whether the offshore team can speak English (or Spanish, or whatever). Rather we are talking about the bigger question of if the two teams can actually understand each other. The professors point out that much of our team communications is based on cultural assumptions. This means that when you think that the other side understands what you just said, they probably don’t.

The end result of all of this study is to tell us that offshoring development work will increase the risk in a project and thus make a product even more risky to bring to market. So should we stop offshoring? No way — the economic benefits are too great for that to happen.

Instead, firms need to realize that by using offshoring as a part of their development process, they are increasing the RISK of the project/product. This means that they need to spend more time training both their project and product managers about the unique risks that offshoring brings and how to deal with them.

Until this is done, I don’t think that you should use the word RISK on television…

Tags: risk reduction, offshoring, project management, new products

No related posts.