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