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

People or Products - Which Do You Mange Better?

Nobody ever said that being a product manager was going to be easy, and I think that we can all agree that it's a tough job. There's been a lot of talk about finding a way to certify product managers by making them go back to school; however, I think that at the heart of the task is the need to achieve a balance between the product and the people working on it. No, we're not CEOs of a the company, however we are ultimately CEOs of our products and too many of us view our organizations as being either product or people focused.

Look, we are all under a great deal of pressure all of the time. Our budgets are too small to begin with and will get cut even further when the company runs into a tough quarter, people leave the project, other departments don't want to work with us, and don't even get me started on outside vendors and suppliers. Yet, still we are ultimately responsible for fixing problems and creating and delivering a successful product. I will confess that when I've been handed a new product to manage, I have the habit of quickly scoping my vision down to the product - what needs to be done to make it successful, people be damned.

Russell Eisenstat is a former Harvard Business School prof has been studying CEOs who do a good job of balancing the product / people scale correctly. There is a great deal that product managers can learn from Russell's work. What would any effort be worth if there wasn't a clever acronym and so Russell has come up with the term HCHP which refers to "High-Commitment and High-Performance" firms & leaders.

So here's the question that we product managers need to find an answer to: how are successful leaders able to resolve the necessary tensions that exist between their quest for creating profitable products and their desire to build a sustainable team that has a high-commitment level? As a product manager I personally feel that I'm motivated by something much deeper than short term profits. I feel a sense of responsibility to leave the company in a better position than I found it. This means creating a successful product AND creating a successful team.

Russell has some suggestions and I have a bunch of things that have worked/not worked for me. Before we jump into the details on how best to achieve this balance, which side of the fence do you fall on: are you a product person or a people person? How has this worked out for you - do your products succeed and do your teams stick around? Leave a comment and let me know.


Tags: people, new products, product manager, product managing, CEO

Good Guessing Gets Great Grades

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

Vendor Contracts: Let's Talk About Force Majeure One More Time

We had talked about force majeure awhile back, and apparently it was interesting enough to catch the attention of one of my colleagues. Phil is a hard-charging product manager who works in the telecommunications space and he just sent me an email that was talking about another story where a vendor had to declare force majeure:

Jim,
Shortly after I read your posting on force majeure I saw an article that said that Royal Dutch Shell has just announced that they won't be able to meet a big piece of their Nigerian oil-export obligations for their customer for the next two months because of militant attacks on their facilities. The force majeure legally protects Shell from not meeting contractual obligations because of factors outside of its control. So much for gas prices going down anytime soon!

Phil
Senior Product Manager

During our last discussion, we spent some time making sure everyone understood what force majeure was. This time around, we should probably discuss what you need to do as a product manager if one of your vendors declares a force majeure!

This is just the tip of the business continuity planning iceberg. As product managers we are responsible for the success of our products no matter if they are just being rolled out or if they are already currently available . The wrong time to worry about the loss of a critical vendor is after something has happened. The right time is when you are introducing your product. There are three questions that you need to both ask and answer:

1. What Are All Of The Things That Could Possibly Happen: This requires a big blank sheet of paper and some serious brainstorming. Generally things fall into categories such as natural disasters, political unrest, pandemics, etc.
   
   
2. What Are The Things That Probably Might Happen: You can't plan for every possibility (your budget is not that big!). So instead you need to identify the top possibilities on your list of all things. How long your probable lists is depends on your budget and your available time.
   
   
3. Plan, Plan, Plan: You don't need separate plans for earthquakes, floods, fires, etc. Instead, you need just one plan with a few special case steps. Putting this together BEFORE you need it is the key to being a product manager who is always on top of things.
   

Once you have a plan, you might think that you are all done. As my friend Phil says "... a plan is just the start of the real work..." He's correct: a plan starts to go out-of-date once it's been created. You need to revisit it at least twice a year and make sure that that names, contact info, and actions are still valid.

So are you ready for one of your vendors to declare a force majeure? Post a comment and let me know if your firm insists that you have a plan for how you will deal with these types of disasters or if you are flying without a plan...


Tags: Shell, Privacy, vendor, business plan

The 8th Word That You Can't Say On Television...

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:

Outsourcing magnifies existing risks and creates new threats.

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

The Secret To Successful IT Product Management Is ...

... leadership. Sorry in advance for this rant, but I've just about had it with product managers who spent their time whining and complaining that nobody listens to them. Pretty much across the board I've seem organizations where IT Product Managers get less respect than Rodney Dangerfield (on a good day!). In talking with these Product Managers, I think that I've heard just about every excuse that you could imagine: "it's really an engineering company and I'm not an engineer", "they don't work well with women", "most of the team is in India and they think differently", "this is a low priority project", etc. To which I say, just shut up already. The time for Product Mangers to feeling sorry for themselves is over - nobody has time to listen to them anymore.

What's wrong with all of these complaints? The accusing finger of blame is pointing in the wrong direction: it's not everyone else's fault, it's the Product Manager's fault. Yes -- I'm blaming the Product Manager, get over it. We really have done a lousy job of clearly defining who we are, what the qualifications to be Product Manager are, and just exactly what value we bring to the company. Who can blame everyone else for not respecting us?

What's Wrong With Product Managers?
Most (98%) of Product Managers don't understand the #1 rule of being a Product Manager: you are the CEO of your product. I really don't care if anyone told you that you were (normally they don't); however, they sure are going to hold you responsible if it fails so you may as well grab the reigns and start to drive that product wagon because if you don't, then nobody will.

A good 75% of Product Managers then go on to mess up Rule #2 of being a Product Manager: it's all about the people. Do you know what the difference between a project manager and a Product Manager is? Scope. A project manager has a clear start and finish to a project and gets to lose him/herself in tracking the progress of that project. A Product Manager operates on a higher plane and needs to ensure that the world is ready for the product once the project manager is done. Oh, and that the product that was created was the right product with the right features.

What To Do?
So what is a Product Manger to do? Let's keep this nice and simple -- show some leadership. A Product Manger can't "manage" because nobody works for them. Instead, a Product Manger needs to inspire those that he/she works with in order to have them work on those items that the Product Manager needs to have done. IT staff, finance staff, marketing folks, etc. all need to come together and do work at the request of a Product Manager for whom they do not actually work. The only way that this can be done successfully is for the Product Manager to set an example of leadership by showing the team the correct way forward. This means that the Product Manager needs to have great interpersonal skills, lots of time and patience, and the ability to simplify complex product status in order to communicate it to many different parties.

How hard can this be? It turns out that it is very hard. There are lots of different Product Management courses out there; however, there is precious few courses on Product Management leadership. Maybe it's time that Leadership becomes the new focus for all Product Mangers...


Tags: IT Product manager, leadership, project, CEO

Brainstorming: How To Do Them The Right Way!

If you've even come close to a business book in the last 5 years or so, you have probably discovered that "innovation" is what every IT organization is desperately trying to capture, grow, encourage, enhance, etc. Although this sounds like a great idea, and IT product management is one area that would directly benefit from this, it turns out that it's actually quite hard to do consistently over time. What gives?

One of the key skills that an IT organization needs in order to be innovative and to develop better IT products, is the ability to brainstorm as a team well. We all THINK that we know what it means to brainstorm; however, it turns out that more often than not we are wrong. Too often we think of brainstorming as being a solitary task where we go off an think about a problem until an apple drops on our head and the answer emerges. Matt Bowen who is the CEO of Aloft Group spends a lot of time teaching his marketing firm's employees how to brainstorm as a group -- a much more powerful form of brainstorming. Here are his suggestions for how you can learn to use this powerful tool:

• Creativity Starts With The Hiring Process: When you are inviting people to join your team, you need to make sure that they will be able to contribute to the group's ability to innovate. This means that you need to understand how they think. A great way to do this is to ask them to tell you stories about jobs that they've had. If their storys revolve around creating new solutions than you know that you have a creative type. If instead, they focus on incremental improvements in the way that things are done, then you're probably talking with an operations person.
  
  
• How To Prepare To Brainstorm In A Group: The best way to learn to do this is to jump in and just do it. You will need to have a designated facilitator to lead the process. The first thing that the facilitator needs to help the group do is to very clearly lay out a single sentence that clearly describes what the goal of the brainstorming session is. Distribute this sentence a day or two before the meeting to everyone who will be attending so that they can start to think about it. Also, the facilitator needs to spend some time establishing criteria for how he/she thinks the resulting ideas need to be rated. What's are the most important characteristics of a solution and how should you rank them?
  
  
• Group Brainstorming Rules: Never have the meeting last more than an hour. Limit the size of the meeting to no more than 5-7 people (less if the facilitator is new to this). Try to make sure that the participants come from different departments because this will help to ensure that you get multiple perspectives. Normal brainstorming rules apply: no critiquing, no editing, no such thing as a bad idea, and always try to build on other people's ideas.

The real key to successful brainstorming lies in what you do AFTER the meeting. The facilitator needs to assemble a group of people to rate the ideas generated by the brainstorming based on the criteria that was established before the meeting. This group can be different from the group that created the ideas.

Finally, don't you let the resulting ideas die! In order for brainstorming to catch on in any IT department the staff need to see changes occurring that they can clearly relate back to brainstorming sessions. Do this and you'll have an innovative IT department that will be the envy of the rest of the firm.

Tags: innovation, innovation, program managers, IT products

Stop The Madness! A Rational Approach To IT New Product Development

The IT field can learn a great deal about new product development from other industries. This time we're going to learn from the big drug firms - they make excellent teachers. If you think about it, we've got a lot in common: both industries have to make big bets on unproven projects with the hopes that they will help make the company lots of money. Sometimes it works, more often than not it doesn't.

The pharmaceutical business views all projects as belonging to one of two different groups: a truth-seeking group and a success-seeking group. The truth-seeking group of projects is focused on evaluating novel new product possibilities and weeding out the bad bets. The success-seeking group of projects is focused on making those products that have been cleared for development as profitable as possible. Hmm, can anyone think of an IT project that wasn't automatically thrown into the success-seeking group without first spending some time in the truth-seeking group?

Eli Lilly has used this two-step approach to manage their new product development since 2001. What they've discovered is that it has been able to deliver products at 2x the speed and for about 1/3 of the cost. However, you never get anything for free. There are some side effects to using this two-step strategy:

• It will postpone the start up of successful projects.
  
  
• However, at the same time it will reduce the risk of failure in an IT environment in which the cost of development is high and the impact of a failure would also be high. If you work in an IT department that has had a lot of project failures, then this is an approach that can help you to absorb a great deal of risk early on in the project.

The sole purpose of an IT project in the truth-seeking group is to reduce the uncertainty about an IT project's ability to deliver what the company is looking for as quickly and effectively as possible. Two types of IT errors can happen to a project that is in this group:

• Managers can ignore evidence that is telling them that the IT project won't be able to deliver what it was designed to.

• The project is killed early before it has a chance to prove that it can deliver what the customer is looking for.

What this means is that for a product management team that is supposed to successfully launch new profitable products, they must avoid making both of these errors. Good luck killing bad products early while not killing good products too early! Using the two-group method allows a new way of thinking to be used to evaluate IT products. The teams can perform experiments on the products in the truth-seeking group in order to determine if they will be able to solve the end user's problems. The teams need to be rewarded when an IT project in this group fails -- they've just saved the company a great deal of money and frustration .

The problem with putting all IT projects automatically into the success-seeking group lies with us product mangers. Once we are assigned a product, we will use every trick in our book to gather whatever materials, facts, or figures are needed to show that we are still on track at each and every status review. Until it's too late, nobody will ever know that our product is doomed for failure.

Using a two group approach to IT products will allow an IT department to implement a new metric: "speed to failure". If a product is going to fail, then you'd like it to do so a quickly as possible. This type of approach to IT product development is not just another type of process reengineering. Rather it's a whole new way of thinking that can reduce the risk associated with IT products while at the same time improving an entire IT department's productivity.


Tags: IT product development, IT products, risk reduction, product failure

Product Manager Alert: Dealing With Hard Core Opposition Within Your Company

We've talked about why IT Product Mangers find it hard to get any respect. Now it's time to talk about the why's and how's of what to do when you run into another department (or person) who acts like a brick wall. Thanks to millions of years of evolution, we are all pretty good at recognizing situations in which we are called on to compete with other departments who are willing to do business with us. We are tuned to allow us to make ourselves heard in these situations and to get our point across. Which is why we all seem to do such a poor job when we are faced with not competition, but rather opposition. Oh, oh. What to do now?

So what is opposition? Opposition is what happens when the group of people that you are trying to communicate with are just dead set against what you have to say. This is not unique to Product Management -- a Project Manager has exactly the same problem. If you show up in a situation where you are going to be telling your team about a great new product that the company has decided to start development on , you will encounter opposition if nobody that you are talking to wants to work on that product in the first place -- it's not that the new product is a bad idea (although it might be), it's just that everyone rejects the idea of working on that product.

What's funny is that although in technical fields we struggle with how to deal with opposition, the folks who work in politics deal with it on a daily basis. Our elected officials are forced to deal with opposition everyday and so they have developed effective ways of dealing with it. We could learn a thing or two from them:

• Co-opt The Other Side's Issue: this is one of my favorite approaches. Don't go head-to-head with the opposition. Instead take a careful look at what's motivating their position: why doesn't the other department want to work on your product? If you show respect for their underlying issue and then go ahead and propose a different way of solving it, you'll basically cut off the opposition at the knees. In our product case, if you show the team that offshore developers do a poor job of creating products when there is minimal documentation and by doing a good job of development their work they will be able to keep more jobs onshore, then you've accomplished your co-opting.
  
  
• Redefine The Issue: Initially an issue may start out as a tug-of-war. In order to solve this problem, if you redefine it in such a way that it is no longer a tug-of-war, then you can win the other side over. In our product example, the issue could start out as a "the company is telling us to do more work". This could be redefined as "Other companies have created products that interface with our product. In order for them (and us) to be successful, we have to extend the interfaces that they are using to connect to our product." All of a sudden, what was something that was being created for the faceless company becomes a tool for specific small business owners.
  
  

If you can become skilled at learning to distinguish opposition from competition, then you will have a hard-to-find skill that you can start to use proactively. Do a little bit of research on the department that you will be communicating with. If there is strong opposition to what you will be discussing with them, it will probably come out quickly. Look for ways to co-opt or redefine the issue and you'll have accomplished half of your job before you even open your mouth.


Tags: passive aggressive, opposition, issues, redefine, co-opt

How To Make The Best IT Product Management Decisions

Warren Bennis is a smart guy (professor of business administration and chairman of the leadership Institute at the University of Southern California). He's cranked out a book called Judgment: How Winning Leaders Make Great Calls and it has a few ideas that really relate to how IT Product Managers can make better decisions.

It turns out that the ability to make good judgment calls when you are a Product Manager is very important (surprise!) because of the impact on others that all of your decisions make. When do these Product Managers get called on to make judgment calls? Warrne identified of the most common three areas: people, strategy, and what to do in a crises. We see the impacts of people judgments around us at work every day. Technically gifted folks who get put into a product team management role for which they are poorly suited, great team leaders who get bumped up and become paper-pushers, etc. The successes in choosing the right people for the right job gets reflected in how successful the product will be. The mistakes can cause lots of damage and are expensive to replace and to repair.

Strategy judgments are the big ones that can make or break a career. In today's hyperactive IT product development environment speed is often prized over accuracy. Warren brings up a great IT product example in his book: Intel. Many folks don't realize this, but Intel got its start in manufacturing and selling memory chips. When the prices in this market started eroding and the Japanese manufacturers started coming on strong, Intel had to make a product judgment call: stay in the memory chip business or move on to something else? Gordon Moore and Andy Grove made the decision to move on (to CPUs) and the rest, as they say, is history. Good judgment call.

Finally, the ability to make good judgment calls in in middle of a crisis. Once again Intel serves as a good IT product example. Back in 1994, as Intel was releasing the latest version of their x86 chip line it was discovered that under certain circumstances it would return the incorrect answer from a math operation. Initially Intel took the IT road in its response: it did some math and stated that the average user would only see an error once every 27,000 years. However, that didn't sit well with most of their customers and eventually Intel had to offer to refund/replace the defective chips. This initial response was a very, very poor judgment call on Intel's part.

So what can product managers do to make better judgment calls? Warren suggests that we work on improving four areas of our knowledge that are critical to making good judgment calls: self-knowledge, social-network knowledge, organizational knowledge, and stakeholder knowledge. Hmm, sure sounds like aligning the product management organization with the rest of the business would go a long way to making this a reality!


Tags: crises, Intel, IT Product Manager, judgment, people, strategy

How Do You Know If Your Product Is On Track Or In The Weeds?

As an IT product is being developed, one of the big questions that a product manager has to continually answer is if the product is on track or if somehow things have gotten mixed up and it's heading off into the weeds, so to speak. Although this sounds like a simple question to answer, in truth it's quite tricky. The challenge comes from the simple fact that it is never possible to see the entire product creation process at one time. The best that you can do is to get snapshots of part of it. From these you have to determine if all is good or if it's time to throw up a red flag.

We've already talked about the tools that you can use to track your product's development, now it's time to talk about exactly what you should be tracking. In tracking my products in the past, I have tried out countless metrics. Some were on the money and some were way off base. However, over time I believe that I've hit upon the six main metrics of an IT program that need to be continuously tracked by a product manager. Take a look and see if you agree with me:

1. Hardware: any IT product development process requires hardware to develop, test, integrate, etc. on. Initially obtaining and then making sure that everything is working correctly could be a full time job. I'm used to four different sets of hardware: development boxes, unit testing boxes, systems testing boxes, and production boxes. Each is owned and managed by a different team and you truly do need to constantly check with them to get status updates.
   
   
2. Staffing: In today's modern IT environments, staff can be added and removed as needed by a project. As books have taught us, a product development process that falls behind cannot be magically saved by just throwing more people at it. Tracking who is currently working on your product and who isn't is key to understanding if your are going to be able to meet your delivery dates.
   
   
3. Security: We all know that it's a very bad idea to leave security features and tests until the end of an IT product development process. That's why checking on the status of both product security features as well as the status of external security checks of the product and the boxes that it's being developed on are critical.
   
   
4. Support: How an IT product is going to be supported is a critical question that can't be left until the product is ready to launch. A so-so product that has great support can go on to be a winner (and likewise a great product can go down in flames with poor support). Involving the support teams in the product development and allowing them to make suggestions is the key to good long term support.
   
   
5. Testing: The testing team often inhabits the lonely no-man's land between the developers and the software quality folks. Showing them respect and allowing them to understand what the product is really supposed to do is the key to ensuring that they do a complete job of testing.
   
   
6. Requirements: Last, but by no means least comes the product requirements team. I've seen all too many IT products start off with a great set of requirements only to have them fall down later on when features got slipped in by the developers and in the end nobody could say for sure what the final product actually did. Constant care and feeding of the requirements team will result in an excellent set of product documents showing up at the same time that the final product hits the street.
   
   

Sounds like a challenge doesn't it? Take heart, if you can set up monitoring processes that keep track of these six metrics, you can rest assured that you'll always know what's going on in the development of your IT product.


Tags: hardware, IT product development, metrics, requirements, schedules, security, staffing

Tracking Your Product Development: What Works, What Doesn't

The job of product management often takes on a program management flavor when it comes to keeping track of how the development of a new product is coming along. It's probably important that I come right out and say that product management is a completely different job than program management; however, the two worlds do intersect when it comes to tracking product development. How an IT product development project is tracked is one of the ways that you can distinguish between a good product manager and a bad one.

So what's a product manager to do? More often than not, I've found myself having to create a means to track the status of a project that is creating my product. Often this project will include external firms, internal development, marketing, sales training, etc. As anyone with an IT background can tell you, there are countless ways to track a project like this; however, too many of them are cumbersome, awkward to use for IT products, and don't really do a good job of answering the questions that you (and your management) will be asking.

Physical File Folder w/ Sticky Notes: In all honesty, I have several IT product management friends who successfully use this system. They are all females and I'm not sure if this has something to do with why it seems to work for them. What I do know is that when I've tried to use it, it's been a complete disaster. This systems only requires you to put all pertinent information into a single file folder and then carry it around with you at all times. Critical information such as dates and contact info can be written on Post-IT notes and stuck on the inside of the file folder. Forget PDAs and laptops, if you know where your info is, you can answer just about any question quicker than your competition. The downside of this system (for me) is that it's not visual -- you can't tell where things are by looking at a summary of the information. Additionally, you need to occasionally spend time and resort/organize your folder in order to make sure that you have up-to-date copies of everything. I always run out of time to do this and then the whole thing just falls down.

Microsoft Project: everyone in IT likes this tool (at least deep down). We like it because it's complicated enough that we feel like if we feed it enough information it will tell us what to do. I have seen some very detailed Project plans; however, I've never really seen an IT project successfully use this tool. Much of the tool's functionality does not pertain to an IT project. One of the big problems is that very few people seem to have copies of Project and so you end up sending out PDF versions of the plan. Then you get busy, the plan doesn't get updated, and things fall apart.

Microsoft Excel: This is my weapon of choice. Everyone seems to have a copy of this application so you can share files and folks can make changes to it if needed. There really is no learning required in order to be able to use it. As a committed visual learner, I use Excel to make lots of colored progress charts. More often than not, I color in cell by cell to show the status of a given set of tasks. When the colored rows are stacked on top of each other, then you can quickly see the overall project status. Oh, and this can easily be copied into PowerPoint presentations to be used at the next mandatory product status meeting.

So there you have it, three different ways to track the status of an IT development project. There is no one perfect answer and what works for one may be different from what works for others. In the end, it's just important that you have a system that allows you to quickly answer the questions that you know are going to be coming your way.


Tags: Excel, Microsoft Project, project, status chart, tracking

What Medical Doctors Can Teach IT Product Managers

Once an IT product has been funded and staffed, there is very little that will cause it to be halted or the original decisions that caused the product to be funded to be revisited. This is probably a good explanation as to why so many IT products are so poorly received by their intended audience when they finally make it to market. It also explains why IT product managers have such a hard time getting respect from within their own companies. Maybe it's time to look outside of IT for a better way to do this.

It might seem like a bit of a stretch at first, but the medical profession has been dealing with "bad product development" issues for years. In the world of medicine, the consequences of errors, bad judgments, and flat out mistakes can be very severe - death. One of the leading causes for these medical mistakes are caused by doctor misdiagnosis. In these cases, a doctor relies on his set of experiences and his limited knowledge to make patient decisions. The fancy name for this type of flawed decision making is Comparative Ignorance. What's really interesting here is that we in IT do exactly the same thing - we decide what products to move forward with based more often that not on what we've seen work in the past. In a field like IT where everything changes so rapidly, it's decisions like this that have a tenancy to result in poor product feature selection or just flat out bad products.

So how have doctors gone about solving this problem? Hospitals convene regular review meetings which are attended by everyone: faculty, nurses, medical students, etc. At these meetings they revisit patient cases that had poor outcomes and they discuss what happened, why it happened, and what can have been done to ensure that it does not happen again. The result of these meetings is that everyone comes to understand that nobody is perfect - we all make mistakes and can learn from others' errors. In IT, reviews of the formal decision making process are rare. Even our brothers and sisters in Sales have what they call After Action Reviews (AARs) in which they review lost sales opportunities in the hopes of identifying what changes need to be made in order to avoid another sales loss.

Often times a product manager will have a "wrap-up meeting" as a part of the formal product development process. However, since IT products rarely ever reach an "end", these meetings never happen. Perhaps if we put our foot down more firmly and held detailed product review meetings at fixed milestones in the launch process, then we'd be able to learn from ourselves and things would be easier the next time around!


Tags: Comparative Ignorance, poor decision making, product review

Face-To-Face Meetings: Online vs. Offline?

How many of you have seen this: you've called a technical face to face meeting to resolve some key product issues. You've carefully coordinated the meeting time with everyone's schedules and you've been sure to make sure that you've included folks from all impacted departments. Imagine your joy when you see that just about everyone has actually shown up for your meeting. Imagine your disappointment when everyone whips out their laptops, powers up. gets a wired/wireless connection, and *poof* they mentally vanish.

So why are we having this meeting? I can't tell you how many times I've been in one of these meetings when someone gets asked a question, looks up from their laptop and says "I'm sorry, I was working on my email. Can you repeat the question?" I generally don't really like meetings all that much and it's events like this that cause them to take way too long. If you introduce IM into the equation, then you have folks in your meeting merrily typing away in one or more active conversations even while your meeting is going on. Arrgh! Why did they even bother to come?

So what's a product manger to do? Stomping your feet, rolling around on the floor, and shaking your finger at offenders are all possibilities; however, I'm not thinking that they will really accomplish the goal. What is the goal? To have a face-to-face meeting with all parties attending participating and engaged in the conversation and problem solving. This is a huge problem and we have yet to really work out the social issues that it brings up. For example, if your boss attends and opens his/her laptop, then what are you going to say to him/her?

I don't have any magic solutions, but one powerful force that you can bring to bear is peer pressure. If before the meeting occurs you loudly and clearly tell everyone that the use of laptops and Blackberrys will be banned during the meeting, then nobody can really object. If you hold the line and actually kick out active Blackberry users that will also send a clear message. Careful though -- if they don't leave, then you will have lost face with the rest of the attendees. Finally, make you meetings exciting and engaging. People do other tasks because they are bored. If you remove the boredom, they may even forget about their laptops/Blackberrys/iPhones for at least awhile.