Image Credit

It May Seem Strange, But Listening To Your Customer Really Works

Why Bother Listening To Your Customers?

One of the best interviews that I’ve ever read was with Steve Jobs (of Apple fame) in which he scoffed at doing things like focus groups and such in order to get input for the fantastic products that Apple makes. He said that since what Apple is doing is so revolutionary, getting input from potential customers wouldn’t help much because they couldn’t even imagine what a product could do. I do respect Steve, but could he be wrong?

For those of us product managers whose products are NOT the next best thing to sliced bread, just maybe taking some time to talk with our customers might help our products be more successful. I mean think about all of the decisions that we have to make that getting a customer’s input would help with: what we should be selling, what our products should look like (will anyone buy the gold colored model?), what to price our products at, and just exactly where and how we should go about selling them.

In tough times there is another powerful motivation for tapping your customers to act as your product advisors: they sure are a lot cheaper than those fancy high priced, suit wearing, professional consultants that a lot of us normally use. Customers can also deliver something that no professional consultant can: they may actually buy your product simply because they were involved in creating it.

How To Listen To Your Customers

Deciding to listen to your customers is a great idea. Where things start to get just a bit sticky is when you sit down and try to figure out just exactly HOW to go about doing this. The simplest way to start things off is to use everyone’s new best friend: Twitter. Why not set up a Twitter account for your product, advertise its existence to your existing customers and interested parties, and then start throwing product related questions out there. It’s cheap, it’s easy, and it sure can’t do any harm.

Your next step could be to set up a blog to talk about your product. This is a great way to get your customer base to drop by in order to find out what you have planned for the product. A great example of this are the blogs that the Google team have set up for their products.

You can take this one step further and setup online communities. This starts to allow your customers to not only talk with you, but to also talk amongst themselves. Yeah, this can be a little dangerous but the benefits probably outweigh the risks.

If you want to get all formal about it, then you can set up product related forums on your company’s web site where you can allow your customers to contribute and vote on ideas. No matter how you do it, it’s pretty easy to get in touch with your customers.

The Downside To Listening To Your Customers

Before you go running off and start to design your next product solely based on guidance provided by online potential customers, you might want to hold on for a minute and give it some further thought. As powerful a force as this may be, there are some drawbacks to listening too closely to what your customers have to say.

The first big issue is that simple fact that the folks who are willing to talk to you online may not be a good representation of the people who will eventually buy your product. I’m sure that the product managers at Coke got lots of feedback from people who liked the taste of New Coke, but that turned out to be the wrong group of people to be asking.

A much more subtle drawback to allowing your customers to have a big voice in the creation and marketing of your product is the fact that by doing so you may be stifling internal creativity. It turns out that the more democratic you make the product design (or marketing) process, the less people are going to be motivated to contribute their ground-breaking ideas and will instead op to go along with what the crowd is saying.

What All Of This Means For You

In the end, the voice of your customer is a powerful tool that can help you to design and market your product better. However, you need to have a firm grasp on when you need to listen to your customers and when you need to follow your own ideas.

No matter how you choose to proceed, it’s important to realize that you’re making a commitment if you ask for input from your customers. Once you’ve done this, you need to find ways to show that you respect it and make it clear to the people who provided input how that input is being used so that everyone feels appreciated.

Do you think that your customers have anything to say that would make your product better?

Click here to get automatic updates when The Accidental Successful CIO Blog is updated.

What We’ll Be Talking About Next Time

There’s not a product manager out there who doesn’t dream of the day in which their product is the only show in town. Man – wouldn’t that be great? You wouldn’t have to worry about any real competition, you’d just be spending your time working to grow the market. And then you wake up.

No related posts.

Before creating product requirements a Product Manger must first create 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

No related posts.

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

No related posts.

By Dr. Jim Anderson

Here in the comfortable 21st Century, IT product managers have many different ways to communicate with their boss/team/etc. However, just because you have a lot of ways to say something, does not mean that you are using the correct way to say it.

Email is all of our favorite (ok, how about most used?) communication tool. We get emails, we read emails, we send emails. The problem is that it is all to easy to view email as our only communication channel. We’ve got others:

1. Email
2. Instant Messaging
3. Phone
4. Written Note
5. Physical Visit

Both emails and IM messages suffer from a key failure: they lack any way to communicate emotion. “Come to my office” is a message that, depending on the emotion with which it is delivered, can have many different meetings.

Let me wrap this discussion up with a true story that will help me make my point. One Friday afternoon (these things always happen on Fridays) I got a call from my product’s development team leader. He told me that the feature that a VP had requested be added to the next release of the product would not be making it into the product because his team did not have any requirements. I thanked him for the head’s up. Hung up the phone and briefly considered how short my career was going to be once the VP discovered that we had apparently ignored his request. I then called the requirements team and asked if they had requirements for this feature. Their team lead told me that they couldn’t start working on those requirements until they got funding to do so. I then called the folks in finance and asked if funding was available. They said “sure, just tell us where it needs to go.” A quick call back to requirements confirmed that they could have the requirements done by the end of the day once funding was confirmed. A final call to development secured me an assurance that the coding would be done by the end of the weekend if the requirements were available by the end of the day. Whew — problem solved.

The take-away here is that the phone calls were the key. Everyone had already been sending emails about this issue, but that had not solved the problem. It’s the small things that make an effective IT product manager.

No related posts.