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

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

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