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