Product vs. Project Management

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: project, project management, product management, IT Product manager, product manager jobs

Should You Get An MBA?

I had a chance to talk with one of my friends the other day who is a product manager working in the telcom space. Carol is basically happy with her job, but she's tired of always gathering requirements and she is already starting to think about the next step in her career - becoming a Director. She told me that she was thinking about getting an MBA; however, she had not made up her mind yet as to if it would be worth the time, energy, and expense required to get one. She wanted to know what I thought?

Just a little background info for you here: I've collected four university degrees. I've got a BS, MS, and PhD in Computer Science and then I went on and just for good measure I picked up an MBA with a focus on Marketing. All in all this took me about 15 years to do. Because of the time, energy, and expense that I've gone through I felt that Carol was talking to the right person!

The first thing that I asked Carol was where she wanted to take her career and what she thought that she needed to do to get there (besides getting an MBA). She said that she had been doing some studying of the last four or five IT people who had been promoted to a Director position. What she had found that they had all been at the company for at least 5 years, they had been associated with a successful project, they were well known to the Executive Director that they would be reporting to. She then said that only two of the five new Directors had an MBA - the other three had at least a Masters technical degree.

Carol had done her homework! We then spent some time talking about what you can expect to get if you get an MBA. Assuming that you can't take time off from your job to go to school for two years, then you are probably looking at going to night school for 4-5 years. I realize that there are other options such as the University of Phoenix and Executive MBA programs; however, my experience has been with the traditional butt-in-a-classroom-at-night approach. One of the first questions that I asked Carol was if she expected to be living where she was right now for the next 5 years - nothing could be sadder than moving half-way through a program! Carol said that yes, she expected to be in town for the next 5 years.

I got my MBA for two reasons: I wanted to have the vocabulary that was needed to work with the people who are running the business and I wanted to network with other people who were at the same stage of their career as I was. In the end, I feel that I got the vocabulary that I wanted. A lot of that vocabulary has to do with finance, organizational behavior, and marketing and these had been things that I didn't know much about before starting my MBA.

The networking with other folks who were working on their MBA didn't work out as well. When one attends the big Ivy League schools to get an MBA, you have the advantage of moving though your courses with your peers in lock step. The MBA program that I was in had more people in it and so we were spread out both over time (some people completed in 3 years, some took as long as 7 years) and in courses - there were a lot of courses offered each semester. This meant that few close relationships were formed that lasted more than a semester or two. In my case I moved out of town after completing the degree and so the value of the networking was even more minimized. All that being said, I believe that if you went into the program with networking as a key goal, you could build up a healthy LinkedIn network by the time you were though.

The final benefit of getting an MBA is that you get a chance to be exposed to a great deal of business information that you may have heard of, but never had a chance to study before. Depending on what your background is, this material may be very straightforward. Unlike technical degrees, an MBA requires you to work in teams, give in-class presentations and really doesn't have that many problem sets to turn in. Rather, questions require wordy answers - you have to memorize a great deal of information that does not have a formula or numbers associated with it. I found the studying to be easy because it was all new. It kept my interest and was easy to memorize.

After I had shared all of this with Carol, she decided to go ahead and take the GMAT in order to apply to enter an MBA program. What helped her to finally make her mind up is that she took a look at the people who would be her competition for the next Director position and decided that an MBA would set her apart from them.

What do you think about Product Managers getting an MBA? Do you think that it helps make them better Product Managers or is it just so much window dressing? At your firm, do people with MBAs seem to go higher, faster in their careers? Leave a comment and let me know what you think.


Tags: MBA, GMAT, product manager, product manager jobs, software product manager

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

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: business, business analyst, new products, requirements, product management

The 3 Secrets To Creating Good Product Requirements

Requirements - don't we all have a love 'em / hate 'em relationship with them? You can have the best product team in the world, an amazing entrepreneurial spirit, and yet if you screw up the first step in a product launch, the requirements, then you're basically dead in the water. I'll probably take some hits for this next statement: you can also screw up by spending too much time trying to build the perfect requirements for your product. Great - damned if you do, and damned if you don't. What's a hard working product manager to do?

Researchers at the University of Florida have discovered that as much as 80% of the rework that has to be done on a development product has its roots in defects in the product's requirements. What this means is that no matter what development methodology your team is planning on using, one of the largest opportunities for an IT organization to improve the quality of the products that it creates is to find a way to capture requirements correctly.

About 10 years ago I had the opportunity to work with a colleague whom I'll call Neil. Neil was an excellent product manager and his heart was in the right place - he really wanted to do a good job. On the last product that he had worked on the requirements were all screwed up. This time around he swore that things would be better. He not only interviewed his customers as to what they were looking for, it would be more accurate to say that he grilled them. He wrote, rewrote, and rewrote again the product requirements. He also held big meetings where everyone came together and nodded that the requirements were exactly what they were looking for. (You know how this story turns out!) Neil's product was a complete flop. The customer took one look at it and said that they weren't going to use it because it didn't fit with how they did their work. Argh! Neil had done everything classically correctly - what went wrong?

Actually, Neil had screwed up in three major ways that we'll now talk about so that the same fate doesn't befall you. Here are the three secrets that every Product Manager needs to know when it's time to collect product requirements:

1. The Customer Is Never Right: One of Neil's biggest errors was listening to his customer. What he should have done was to listen to their business processes. Ultimately the role of every product is to solve a problem. If you just listen to the customer's description of the problem, then you may end up creating a solution that doesn't fit in with how they do their work. Instead, take a long, hard look at where the problem fits into their business processes and you just might discover that the correct solution looks nothing like what they described to you.
   
   
2. Good Enough Is Good Enough: You have to draw the line somewhere and stop the requirements gathering process. Neil couldn't do this - he was on a Don Quixote quest to create the perfect all encompassing product requirements. Instead of thinking of requirements as being written on stone, try thinking about them as having as many layers as an onion. In order to get thing started, you need to have the first complete layer of requirements. You can then refine, refine, and refine some more while the project has already started. Perfection is never attainable and you'll waste a lot of time trying to get there.
   
   
3. Dedication Is Required: All too often product requirements are not "owned" by anyone after they have been created. What this means is that the orphan requirements quickly become almost useless because of product development decisions that get made on an almost daily basis. However, if someone on the product team is given the responsibility of keeping the requirements up-to-date and ensuring that they are a living, breathing document, then they will have value both at the start and the finish of the project.
   

There you go, 3 simple secrets that can transform how a product manager collects, uses, and manages product requirements. Now if only keeping the product team aligned was so easy...!

So tell me - how have you gone about collecting product requirements? Are your product's requirements living requirements or should they have been buried a long time ago? When do you draw the line and stop collecting requirements and start developing the product? Leave a comment and let me know what you think.


Tags: new products,product manager,requirements management, product lifecycle

How Great Product Managers Keep Their Perspective

There are a lot of Product Managers in the world, the question is what makes some of them great product managers? We've been talking about high-commitment, high-performance product (HCHP) product managers and they are truly the great ones. What makes these product mangers better than all of the rest is that they have found a way to keep their work in perspective and this is what makes all the difference. So what's their secret?

The first secret to keeping perspective is that great product managers find a way to stay close with their teams while at the same time maintaining a distance. What this means is that everyone on the team feels as though they know the product manager and he/she knows them. At the same time, we all know that sometimes difficult staffing decisions need to be made and keeping a distance allows the great product managers to not be accused of playing favorites.

Secondly, great product managers actually have a life outside of work. No matter if it is just spending time with their families or throwing themselves into a hobby that they truly enjoy, they find a way to make sure that their job is not all that there is to life. This helps them to maintain a perspective about the job.

Finally, humor always helps. The great product managers are able to laugh at themselves and their situation. This ability can relieve tension that would otherwise spill over and poison workplace relationships. Additionally, when a product manager shows that he/she can laugh at themselves, then the entire team feels more relaxed around them and the team will function more smoothly.

Ultimately, a great product manager achieves that status not by WHAT they do, we all know what we are supposed to be doing, but rather HOW they do things. Great product mangers realize that the profession of product management is really a calling, not a science and it can only be done well by someone using their artistic talent, not their engineering skills.

What do you think? Are you able to keep perspective on your job or does it overwhelm you on occasion? Are you close enough with your product team or are you too close? Can you laugh at yourself and the things that you do or is this a skill that you are still working on? Leave a comment and let me know what you think.


Tags: perspective, product manager, humor, product management

Would You Like To Share My Purpose?

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

People Product Mangers Under Pressure

Last time we spent some time talking about high-commitment, high-performance (HCHP) companies and alluded to the fact that their IT leaders had found a way to balance between managing products and managing people. I want to be able to do that! Perhaps they can teach us Product Managers something...

As a product manager, we are really under incredible daily pressure to meet the performance demands of our investors. All too often we don't view our upper managers as investors; however, at the end of the day that is really what they are: they have decided to spend money on our product and not something else so clearly they expect a return on that investment that is larger than the other options could have provided. If you don't meet this need, then give it up - nothing else really matters.

How can you push for the superior performance that will be required in order to meet your management's expectations? In many cases you'll be called on to make extraordinary decisions and even implement unconventional ideas. One example of this would be recommending that your product be killed if you came to realize that it had no hope of being successful. How many product mangers that you know would have the guts to do that?

Having the courage to make big decisions is great; however, it means nothing if you take the commitment of your team for granted and end up having your decisions destroy the delicate social fabric that holds your organization together. Really good Product Mangers find a way to personally create a link between the people who are doing the work and the results that they must deliver.

I can hear you now saying "great words, but how do I do that...?" You do it by simultaneously combining four different strategies that will allow you to hold the center and not stray off course:

1. Earn Trust: Product Managers need to earn the trust of everyone who is working on their product. The ONLY way to do this is to be open with your team and to always share the truth with them - get caught in one lie or half-truth and the game is over.
   
   
2. Engage Deeply: Build a close connection with everyone on your team so that when you interact with them it can be direct and personal.
   
   
3. Create a Focused Agenda: In order to mobilize a group of people, a Product Manger needs to have a very clearly defined and focused agenda that can be communicated and bought into by the entire team.
   
   
4. Build Leadership: a Product Manager can not be everywhere at all times nor can he/she do everything. This means that the Product Manager needs to be building a leadership team within the product team so that progress can continue even when the Product Manger is not available.

Assuming that you can pull this off, you still have not achieved everything that HCHP IT leaders can do. Next comes the challenge of creating a sense of shared purpose for your team...

So do you have what it takes to be a HCHP Product Manager? If you were in charge of a product that had no hope of success, would you have the courage to kill it? Have you ever managed a product that should have been killed early on? Leave a comment and let me know what you think.


Tags: trust, engagement, agenda, focus, leadership, product manager