"IT Product Management" blog has moved!

You should be automatically redirected in 6 seconds. If not, visit
http://www.theaccidentalpm.com/
and update your bookmarks.
Thank you very much!
- Dr. Jim Anderson

Showing posts with label product management. Show all posts
Showing posts with label product management. Show all posts

Tuesday, September 2, 2008

Product vs. Project Management

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 are 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 no 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 product manager is not responsible for designing the product. In fact the product manger does not have to be a subject matter expert - they can mange projects that they know nothing about the underlying technology. A Product Manger 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 product 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 manger 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 mangers 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: , , , ,

Tuesday, August 26, 2008

Q: What Comes Before Requirements, A: ...

Before creating product requirements a Product Manger must first create a business analysis

A: Business Analysis

A good product manager needs to be able to wear many different hats and one of them is that of a Business Analyst. (Oh great I can hear you saying - yet another job for the overworked PM to take on). Before you throw your hands up in the air and run screaming from the room at being presented with even more work, it turns out that you are already doing this job and just may not know it. I guess we should start our discussion in the beginning - just what is a Business Analyst and why should I care?

We are all familiar with requirements and just how important they are to ensuring that the product that you are working so hard to create meets your customer's needs. What has been missing has been the realization that an analysis of the business needs to be done before any requirements start to be collected. If you don't understand WHAT the business does and, even more importantly, HOW it does it, then there is no way that you'll ever be able to create products that complement the business. All too often Product Managers try to combine the business analysis task with the requirements collection task and end up doing at best half of both jobs.

In some larger companies, there may be whole departments of business analysts, in small firms the full responsibility for this task may fall on the shoulders of the PM. If we can all agree that the business analyst's role of understanding how the business operates is important, then perhaps we should have a quick discussion to fully understand what a business analyst does?

At a high level, the business analyst is the role that the product manager plays in order to bridge the divide between IT departments and the rest of the business units that they support. No matter if the product being developed is for internal consumption or for external customers, the business analyst's role is to ensure that the most is made of the human contact between multiple internal departments.

The end result of a business analyst's efforts feed into the requirements collection process. However, in order to generate this output, a business analyst needs to start with a clear understanding of what those product requirements will eventually look like. This includes having a good understanding of the plan to eventually create the requirements, what types of requirements will be needed, the process that will be used to gather the requirements, and the planning and preparation that will go into creating the final set of requirements. Note that the business analyst does not need to actually create product requirements; however, they should have a good understanding of what they will look like.

In order to understand how a company does what it does, the business analyst is going to have to do a lot of talking. As the analyst moves from department to department, he/she is going to have to use many different techniques to elicit information from various employees. Some techniques that can be used include:
  • Brainstorming
  • Job shadowing / observation
  • Surveys / interviews / focus groups
  • Collaborative work sessions
  • Prototyping
  • Document / Interface analysis
After having collected all of the information needed to completely describe how the company operates, the next step is to find a way to document this information. As we all know, thick binders of dense text will be put on the shelf and never looked at again. A few issues that the business analyst needs to resolve as the information is processed are:
  • Developing Use Cases to show how information & parts move within the company
  • Categorizing and packaging the collected information
  • Documentation techniques that work best for this particular company / division.
  • Change control - critical because of the understanding that process information ages quickly.
In the end the Product Manager / Business Analyst needs to develop and document a detailed understanding of how the company/customer operates in order to prepare to develop requirements. The skills that a Product Manger needs to have in order to do this successfully are as follows:
  1. The ability to elicit and assess information from information holders.
  2. The ability to conduct interviews with users and business leaders.
  3. The ability to facilitate collaborative sessions.
  4. The ability to resolve conflicts and reach consensus.
  5. The ability to navigate internal politics.
  6. The ability to foster creative problem solving within the various departments.
  7. The ability to document the business information that has been gathered.
So do you play the role of business analyst in your firm today? Do you do a good job of documenting how the business works or are you too busy creating actual product requirements? What skills did I leave off of my list of what a business analyst needs to do? Leave a comment and let me know what you think.


Tags: , , , ,