I just happened to see this quote from Bill Cosby.

“I don’t know the key to success, but the key to failure is trying to please everybody”

How appropriate for product managers?

All product managers should have this quote stuck next to their desks so that it is in your face as a reminder. We cannot build a product that is good for everyone - pick the target buyer (who will buy) and then execute like hell. Use the target buyer to handle all the “what if we do this …” or “what if the user wants to do this …” ideas people throw at you.

Don’t know what I am talking about? Google “personas” and read all about it.

Everything that one tries to sell, in my opinion, starts or ends in one of three buckets.

1. A need sell
2. A category sell
3. A product sell

Let me explain in more detail on what I mean.

1) A need sell is the worst place for a product long term. If your product is here, you are essentially trying to convince the customer that he has a need and that he needs your product or service. You cannot sell to someone who won’t buy. Products that remain here either are:

• Products that are typically technology driven and hence looking for a problem to solve or just plain stupid products - someone told me that there was Sharper Image tire pressure gauge that had a clock built into it - yah, right I was missing that - guess where Sharper image ended up to be.
• Products that are way ahead of their time - the market is just not ready for it or the technology has not matured enough that the initial implementation is just not the right way to do it.

You may be able to sell a few of these products via lengthy sales cycle, but nothing to keep you going long term - the very existence of a product should be to solve an existing need and not to convince the customer that they have a need.

2) A category sell to me is where the prospect knows that he/she has a problem, but does not think it is possible to solve it and is skeptical whether the problem can be solved. New products that solve an existing problem in a very new way (pragmatic shift) could remain here for a little while. There are many examples that come to mind:

1. Salesforce.com comes to mind during its early days. The dotcom bubble had burst, people were just wary of anything related to the internet, internet connectivity was sketchy and here was a company that wanted to do salesforce automation on the web. I am sure it was a tough sell in the beginning.
2. “Data loss prevention” products - large corporations are always wary of insiders leaking confidential information to the outsiders accidentally or intentionally. Technology exists to solve this problem, but it is a little bit of a hard sell. This is not only because of the sophisticated technology, but also convincing someone that the technology actually works.

Many products/services could end up in a pilot and a longer sales cycle. You may not be able to convince everyone and hence you may sell less especially in the early days. Once enough people buy it and the product becomes mainstream, it will move into the “product sell” category. Such products/services follow the classic product adoption cycle made famous by Geoffrey Moore in “Crossing the Chasm” as long as the product can cross the chasm.

3) A product sell is basically where a prospect walks in and says “Give me this product” - the customer knows that the product solves a well known problem. You don’t have anything to sell, you just have to let the customer buy it from you. This is the sweetest spot you want to be in. You sell a ton (yes, there will be competition, but you still could do very well) at a very fast pace. This is where successful products eventually end up.

Salesforce.com is currently in this category. Microsoft Windows ended up here. Apple iPhone and iPod are here. Getting here should be every product manager’s dream. But products don’t end up here only by luck - they ended up here because they solved a real problem, solved it in the most innovative way and also enjoyed some luck by being at the right place at the right time. But products cannot be complacent once they get here, because there could very well be a competing product currently in the “category sell” that is solving the same problem in a whole different way, just waiting in the wings to take off.

As a product manager, it is extremely important that you know where your product/service lies and then try to see how you can move quickly to a “product sell” as soon as possible. If you are stuck in the “need sell” category, you may want to rethink your strategy, reinvent your product or call it day and cut your losses.

Liked this article? Leave me comments - I would love to hear your thoughts - or get an RSS Feed to this blog at http://productmanagementtips.com/feed

Product Managers pay (or should pay) a lot of attention to finding out more about why people are NOT buying their product more than why people are buying their product. This can be framed based on the current population of users.

But we are at a tipping point in history where a large number of baby boomers are approaching retirement and their places are being taken by a wave of new entrants. Many of these new entrants are currently in colleges. So if you are planning to develop a long term roadmap, make sure you are taking into account the behavioral aspects of the new generation.

I thought that the survery results shown below (Source: eMarketer.com) was very interesting in understanding the adoption of the latest technology by age (Low adoption of RSS feeds in the younger age group was a surprise to me). It is important that we pay attention to this because these represent the future users of our products.

The full article is titled Baby Boomers and Social Networking and is worth a read. Pay equal attention to some of the similarities called out in the full article.

Liked this article? Leave me comments - I would love to hear your thoughts - or get an RSS Feed to this blog at http://productmanagementtips.com/feed

We as product manager are well tuned with doing a market read, determining the unmet needs of the market and then getting someone to build products that will satisfy the need.

But there is an important trap that product managers should avoid. History is full of examples of products that fell into this trap. You want to build products that customers will BUY and not JUST LIKE. You could build a product that satisfies the unmet need in the best possible manner, but if it is not something that the customer is willing to pay for, you are out of luck. Your product will languish on the shelf and it will join countless number of other products that have met a similar fate.

We have four different scenarios of Like vs. Buy as shown below.

Obviously, the two categories you want to avoid are the red ones and the places where you want to be are the green ones.

You may wonder how you could ever make a customer buy a product that he does not like - there are many classes of products that fit the bill here. For example, insurance products - not that I like them, but I have to buy them - isn’t this such a sweet category to be in? Other examples include anything related to taxes (Turbotax for example), funeral planning products (that one needs no explanation) etc.

The biggest trap among all this is the Like and Don’t Buy category. Lot of customers may tell you how much they love your new product idea, but you absolutely need to find out if they will put their money down to buy it - or in other words, is the painpoint you are attempting to solve painful enough that they will be willing to spend money on it? If not, it is not worth pursuing.

Beta programs kind of fall into this category - everyone is all excited to be part of your Beta, but not many give you feedback. It is OK to have this happen on your Beta, but you don’t want this to happen to your product.

One way to avoid this trap is to try to get customers to buy the early version of your product at a heavily discounted price - you would get them the Beta version, they will give you the feedback and then you would ship them the real product at the very low price that they paid you. If you run a subscription model, you could offer the customer a heavily discounted price upfront and the opportunity to lock down the price for say the first 2 years. If you cannot get enough customers to bite on this and sign on the dotted line, then the writing is on the wall - your product is in the trap category - how are you ever going to sell at the full prize?

Having said this, I would love to hear from my fellow product managers on other techniques that could be used to avoid falling into this trap.

Liked this article? Get an RSS Feed to my blog at http://productmanagementtips.com/feed

PS: I have to thank my mentor Jon Hirschtick, founder and ex CEO of SolidWorks for having drilled this into me whenever I have had different product discussions with him.

There is a great article on Business Week titled Johnson & Johnson’s Big Design Challenge which talks about how their design director Chris Hacker is promoting sustainable design.

I thought the key sentence was when he says “The key to growing sales is not to load up the packaging with “marketing bullets,” but to “think about what motivates the consumer to take the product home.“

So well said. Always challenge your team to answer the question “What is the Customer Value?”. Agreed that you also need to appeal to the emotional side of the customers and do need to have some sizzle features or demo candy that makes the customer buy your product - but if it is all sizzle and no steak, the product will not have sustainable sales.

Last week, I had to get a tree cut in the yard and then my garage door broke down with the door bent and the rollers popped out. Not knowing who to call, I checked out ServiceMagic. What an awesome experience that turned out to.

Within minutes, they send me names of three pros rated very high by their customers. I called the pro, got a quote, scheduled the job and got both of these issues taken care of in a hurry. Their customer service is outstanding - they called me to find out how the project was going, they send me thank you notes via email after I had rated the pros - they did not have to do any of this.

This is one of the rare occasions in the recent past where I could say that I have received just an excellent service. We hear all the time about service is being shortchanged by companies due to the current tough economic times, but here is a company that has figured out how to use technology to the hilt to provide such a great service - their website is awesome with easy navigation, customer ratings and reviews of their pros, the results of their 10 point screening etc. They use email communication very well and as a result take many of the pain points involved in finding/hiring a contractor off their customer’s chests. Think about the effort it takes to make sure that the contractors you want to hire have the necessary license, insurance etc. to do the work? All this is done by ServiceMagic for you. Dealing with contractors has never been easy and they seem to have made this easy.

ServiceMagic sets the benchmark against which other service companies should be considered. If you have not used them, I would strongly recommend that you give them a try.

Their success is because they have thought through the entire user experience from the usability of their website through every touch point with the customer either via email or phone. Plus, their service is absolutely free for consumers, they make their money from the pros who get referrals.

Thank you ServiceMagic.

A while back, I had written why a functional spec is needed in addition to a PRD. So what does a good functional spec need to contain?

Here is what I consider elements of a good functional spec. I tend to use smaller paragraphs or bullets to make it readable. People tend not to read lengthy sentences or large paragraphs.

1. Problem statement: This section should clearly explain the problem you are trying to solve. This should not contain anything about the solution to the problem. You want readers to clearly understand the problem first.

2. Proposed solution: Now briefly explain the solution you are proposing to solve the problem.

3. Marketing Information/Justification: Things such as how big is the customer base that has this problem and why should we solve this problem (differentiation, tablestakes etc.)

4. Target Users: Who are the typical users who will use this? Internal to your company? External users? Experienced users? New users? All users?

5. Committed or Minimum Requirements: The requirements that have been reviewed and committed by Product Management and Engineering should be listed here. Unless all of these requirements have been implemented, the project will not solve the problem it is intended to solve to customer expectations. Or in other words, the new thing cannot be shipped in the product. Number the requirements instead of using bullets so that it is easier to refer to them during reviews, in emails, during discussions etc.

6. Requirements under Consideration: The requirements that needs to be considered by Engineering for implementation should be listed here. These are not committed to make this release. If time permits, Engineering will try to implement these in the current release (this never happens by the way). However, more importantly, Engineering has agreed to take them into account such that the current implementation will be able to support these requirements in the future. Again, number the requirements instead of using bullets so that it is easier to refer to them during reviews, in emails, during discussions etc.

7. Out of Scope Requirements: These would be requirements that have been agreed upon by Product Management and Engineering as out of scope for the current implementation. However, Engineering has agreed to take them into account such that the current implementation will be able to support these requirements in the future.

8. Proposed User Interface: This is where you would propose as to what the user interface needs to look like, what the interaction needs to be. This section will be written by an interaction designer or a graphics artist and if you don’t have such people, you should write them. I would not leave it to engineering to design the UI, you very well know what that will end up to be.

9. Typical Use Cases: Here you should list the most common use cases that should be supported by the current implementation. QA should be able to generate test plans based on these use cases. Flow charts are a very nice way to document use cases because it would mimic the workflow you expect the user to experience and are also very easy to understand. Doing flow charts also makes you realize the requirements you may not have accounted for.

I have used such a format for about 14 years now and engineering have always liked them because it tells them why to do something, how it needs to work etc.

As a product manager, you are very likely to have more feature requests than what you can put out in a given release. In my case, a good product manager’s job at release planning is figuring out what to eliminate from consideration - you have to make hard decisions - that is what you are paid to do.

Please note that my background is working on products that have mass market appeal and did not have to deal with things like customer funded development - where a customer throws money at you to get a feature that only they will use.

Here are the five guidelines I have used effectively ….

1) How MANY customers will ever USE it?

We held a strong line on this - if the feature was meant just for the selected few (no matter how much money these customers had), we said No to the customer. You may say - no way, it will not work in my case. My reply - have you tried - Have you told your customer No and told him why? - if not try it.

I will give you an example - we had a very well known consumer company in Japan as a customer - they had bought a few licenses but had the promise of buying a whole lot more licenses - they had a lot of money. We visited them in Japan, they visited us here, met with our executives etc. - they tried to push their agenda hard on us and they had all sort of ideas as to how the software needs to work. We questioned them hard to get to the bottom of their underlying problems - why, why, why do you need to do something. They had some great ideas and some that applied only to them - we readily agreed to do the former and rejected the latter with solid business reasons why we won’t do it - not enough customers have the need.

They respected us at the end - their feedback was that we were the first vendor to have grilled them on their requests and were bold enough to turn them down, as opposed to other vendors who were ready to do whatever they wanted. They realized that we were a company that knew what we were doing and our willingness to grill them, told them that we wanted to make sure we were solving their problems the right way.

2) How OFTEN will customers USE it?

Is this something a customer will use once a year, once a month or something they would use everyday. Why does this matter? Remember the phrase “death by thousand cuts” - if something that needs to be used everyday is not supported or is very inefficient to do, it kills user productivity. This may not be something that will make a press release when you launch a new release or in your product demo, but this is something that will get you a standing ovation from your existing customers. Believe me, I have experienced this multiple times where the smallest change scored the highest in customer satisfaction. Stuff such as choosing the right default values, remembering the last used options fall into this category.

Taking how MANY customers would use it and multiplying it by how OFTEN they will use it, you get what I define as Velocity of a new feature.

VELOCITY = How MANY customers will use X How OFTEN they will use

Features with highest velocity should be serious contenders to make into your new release.

3) Will this open up new markets?

It could be something that could be asked by your smallest customer - but it could be this brilliant idea that could change the rules of the game and open up a completely new market for you. You as a product manager need to make this call.

I have been asked in the past if we implemented feature requests only from large customers with lots of licenses - my response always has been - size does not matter, quality of the idea does. This is what product managers get paid to do - take such ideas and make a business out of it.

4) Is this considered table stakes by the market?

There could be features you would need to compete in the market - if you don’t have these basic things, you are not even considered a player. These ones should be obvious if you know your market. For example, pivot tables or charting are considered table stakes for a serious spreadsheet application.

But tread this one with caution - this is where sales can take you for a ride. They will say “we cannot compete because we don’t have this X, Y and Z” and the list could be endless. For those being raised by sales, ask them to put you in touch with customers who would not buy without this feature - then from the customers get to the real problem that is solved by the feature - for all you know, you may have an innovative way to do it, or can come up with one that might change the rules of the game.

5) Is the feature a building block to the real thing?

This could be something determined by R&D (architectural changes) or some other user facing feature that is needed to support the final feature.

If you consistently use these guidelines, you end up making a business case why you want to turn down a feature request - this even works with executives because it is now based on facts and not opinions. After all this, if some higher up overrides your decision, it is not in your hands, but you know you did your analysis.

Have you heard this one before - I have - internal pundits claiming they know what the market wants because at one point in time (read “eons” ago, before your market segment even existed), they used to be in the customer’s shoes.

“Hey, I used to do product design”

or

“I used to be a salesman”

or

“When I used to run YYYY department”

they say ….

I have found a quick counterattack for this -

“Great, when did you do that?”

“In 1997, I used to work at XYZ Co.”

“Hummm, 11 years ago - so you mean to tell me that the world has remained stagnant and nothing has changed in those 11 years - did I hear that right? (OK, not exactly in the words above, but you get the point).

That usually stops this “we have answers here in the building” or “the way I did is how the world works”.

Yes, there are certain product decisions that you have to make drawing on your past experience, but saying that we know what to build because I was a customer once, is nothing but a recipe for failure - especially in the high tech arena, where the way you did it last month is probably not valid anymore.

It amazes me how many companies claim to be customer driven, but then they limit their product managers from traveling because the travel budget is tight, but on the other side the product development budget is a big leaky bucket funding products no one will ever want to buy.

When interviewing customers to determine their needs, take the time to also ask them where they get information that keep them up-to-date in their profession.

1) Are there organizations that they regard in high regard that a recommendation from such organizations is considered valued?
2) What magazines do they read frequently?
3) Do they have a blog?
4) Do they read blogs? Which ones?
5) Do they read or contribute online discussion forums?
6) Are there places which your customer absolutely disrespects or would not want to have any association with?
7) Do they read analyst reports - like Gartner, Yankee Group, IDC etc.

You want to find out where they hang out professionally online and offline. This is because if and when you build a product/service that solves their needs, you want to make sure that the new product/service is promoted well where your potential customers hang out. So, there is more to learn in customer interviews than just the unmet needs - take it as an opportunity to profile your customer very well.

I have been a big proponent of online communities and social media - I have written at least two blog posts on this. So when the latest Business Week arrived with the main section titled “Consumer vigilantes” I could not put it down. The most interesting article among many dealing with social media was titled Love the customers who hate you. This is a must read. The net net of the article is captured in “…… Now don’t get mad at these people. Instead, help them get even with you. These angry customers are doing you a great favor. They care enough about your product or service to tell you exactly what went wrong. Other customers may just desert you and head to the competition. But these are telling you what to fix. Listen to them. Help them. Respond to them. Ask their advice—and they’ll give it to you.” - Enjoy reading.

In my product management career, I have always had some users who were more vociferous than most of the others. Their decibel level when they asked for new enhancements or yelled at you for the bugs in the software was orders of magnitude higher than majority of the users. The vast majority of these users were loud because they cared, they were passionate about your product. Hence, don’t discount these users - listen to them, allow them to vent and take action to fix their problems if appropriate.

However, you as a product manager need to do a fine balancing act you - some of the feature requests from these vociferous users could be for functionality that applies just to them, because of what they use your product for or the unique way in which they do a common task. You have to listen to them, but also be willing to say No with a justifiable reason. All of us ask for more, but not everyone expects to get everything they ask for (if you don’t ask, you don’t get - so there is not much downside to asking). As long as you tell them why you would not do something, they will understand - getting back to them tells them you care.

I remember an instance where I was reading through the enhancement requests we had received when I came across a tirade from a user. It was an email bomb filled with expletives how our product sucked and how he thought we were all a bunch of idiots. I picked up the phone and called the user. I introduced myself and told him that I was calling him about the enhancement request he had send in. First thing he said was a sincere apology for having writing such a tirade (I don’t know if he thought I was going to sue him) and said he was having a bad day and the software was not working the way he wanted to get his job done. I asked him not to be apologetic and asked him to help me understand the deficiency in the software. We spend a good 20 minutes on the phone understanding the issue.

Guess what likely happened after the call - I created a passionate user for our product because I took time to read what he had written (however unpleasant),  call him and discuss the issue to see how we could improve our product so that he can be successful with what he does. Do you think he would have shared this experience with his colleagues or other users in his community? I absolutely think he would have. What happens if he encounters someone else who has a similar gripe - he is going to tell them we care and to talk to us. I created another big proponent who is going to spread the word about our product and about us as a company.

Creating passionate users and listening to them is one of the most important parts of your job as a product manager. After all, the answer is not in the building - it is very important for all of us to get out of our busy schedule of internal meetings and take the time to talk to real users.  After all, they are the ones who buy our product.

I bought a new car last week. I was very clear what I needed - a Toyota Camry Hybrid and knew the exact options I needed. I did all my research on the web in reading user generated reviews, dealer invoice prices and so on. After spending about 3 hours doing all this, I was ready to buy. I wanted the car in a day because my previous car was giving me trouble.

I started making phone calls to Toyota dealers. I told them right upfront:

1) Here is the exact car I need - color, options etc.

2) I don’t have time to haggle

3) I am shopping around calling dealers

4) I am looking to buy tomorrow.

The sales person at the three dealers I called listened and they told me their best price and they had the car - they asked me if I would like to come in to test drive the car - no pressure, here is what you need, here is what we want - none of the traditional pressure tactics that auto dealers are well known for.

I ended up buying the car from Bernardi Toyota because they not only had the lowest  price but they also worked with me respecting my intelligence to come up with a win-win situation regarding my trade in. So what two lessons did I learn as a product manager from this personal experience?

1) Get real users to write reviews about your product. This is much more reliable than what you as a vendor can put out there. I went to the Toyota website only to look at the specs, colors, options etc. I did all my research on sites such as edmunds.com. Organizations always worry about user reviews because they fear bad things will be said about their products and that the competition will get hold off these reviews. Think about it, by promoting candid feedback from your user base, you are actually raising the bar for your competition. Everyone has skeletons in their closets – you are forcing the competition’s hand to do the same. My advice – forget about the competition – be more concerned about what your customers have to say – if they have bad things to say, you should be the first one to know because you are in a position to fix the problem. No matter what you put out, you cannot satisfy everyone – there will be someone who will say something bad about your product. If all you get are bad reviews about your product and you choose to ignore it, you are only buying time before the inevitable happens.

2) Teach your sales people to listen to the customer’s needs and to respect the customer as an intelligent human being. Help the customers buy what they want rather than trying to sell to them. We all love to buy and don’t want to be sold to.

Based on this very positive experience, I recommended Bernardi Toyota to my friend who was also looking to buy a new car and he is buying from them today. “Word of mouth” pays.

Customer visits have always been one of my pet subjects because the only way I have learned to deliver good products is by getting out of the building and talking to real people who buy or will buy my products. At SolidWorks, customer visits was ingrained into our working culture and all of us had an MBO of conducting six customer visits every quarter.

Jeff Lash has written a very good article on his blog titled Avoid excuses for not conducting customer visits. It is definitely worth reading.

I have heard this question being asked a lot of times - do you use agile development methodology? How about scrum, how about spikes? I heard this asked yesterday. To tell you the truth, I have some idea what agile is but to me it sounds very much like the latest buzzword to me. In my product management career spanning 11+ years, I have really not paid too much attention to what software development process my team uses. Instead what I have focused on are things like -

1) Is my development team delivering functionality that solves customer problems that customers care about?

2) Are they delivering it on time so that it satisfies my existing customers and can help the business meet the revenue projections for this year?

3) Is the team receptive to iterative input or to customer’s new requirements during the development cycle to change the functionality based on customer feedback during alpha and beta testing - without telling me that “hey it was not in the spec and it is too late to make changes” (I fully realize to meet schedules and quality, there is indeed a point where it is too late to make changes)

4) Does my development team create very frequent and usable builds (not fully tested and hence buggy in some respect) so that QA and product management get to play with it early to ensure that what is being built is what customers want and to provide iterative feedback (Believe me, I do not think there is anything called a complete spec because have written so many functional specs over the years, I consider it difficult to foresee all the different permutations and combinations when writing the initial spec)?

5)  Are they delivering functionality of good quality that customers can use?

To me, delivering usable products to customers  that help the customer be successful and helps my business to make more money, is all that matters. What you call the process, agile, scrum, spike, non-agile does not matter.

Like anything else, if your development team does not have the right skill set, no development methodology stands a chance to do what is needed to sustain and grow your business. So before one starts using the latest fad in development methodology or starts saying things like - if you are not using agile, you are doing something wrong - it would be better to ask the question - why do I need this new methodology? what current development problems will it solve? What benefits would it bring to my customers or to the business.? Such an assessment would be well grounded in objectivity and reality rather than getting carried away by this hype.

I am not saying “agile” is bad or wrong (I don’t know enough about it) but no process can fix a problem if you don’t know the root cause to the problem.

How often have you called customer service at credit card companies, airlines, medical benefits and you have been asked to enter information such as your credit card number, your zip code, your social security number, your frequent flyer number etc. and then finally when you get to a live person, the first question is what is your XXXX - the same information that you had entered using the keypad …. Huh!!

Do these folks ever try out their own systems to check out the customer experience? Or is just a tactic to balance the call volume - benefit for them and none for the customer.

BTW, if you want to spare yourselves of this torture, check out gethuman.com

I was involved in a conversation last week where we were trying to unearth customer pain points. One of the product managers explained that main pain points were integration and scalability. This is what set me thinking about the difference between pain points and requirements. The  two are not interchangeable - in fact there is a parent child relationship here which if you ignore, you could end up building the wrong or a less preferred product.

Pain points are what customers are going through because they do not have a product that solves their problem. For example, before the advent of wireless devices, a customer pain point could have been that he cannot make a phone call while he was in the car - notice that nowhere in this pain point is wireless mentioned. Putting wireless into this sentence would be jumping to a solution as to how to solve the pain point. It is extremely important that product managers understand the real pain points. Here are some other examples - all cooked up for illustration.

1) I am in sales and I get a lot of customer queries via email. I need to respond to these quickly to close the deals. This is especially true towards the end of the quarter. But given that I am travelling and in meetings at customer sites, I am unable to do this because I cannot get to my email unless I am in the office and this costs me time and money. For example, in one instance last quarter I missed closing a deal worth $1M by one day. (I guess RIM probably heard this a whole lot and came up with the Blackberry - but do you see anything about a Blackberry or a mobile device in the customer’s description of his/her pain point? - does it say anything related to integration or scalability or ease of deployment in the description?)

2) I usually get out of the office after the banks have closed. Hence I am unable to get to the bank before they close to withdraw money from my account. Hence I have to remember to withdraw money on Saturday mornings, enough to last me one week. I feel uncomfortable carrying all that money around where ever I go.  BTW, this is still true in a lots of places in India (what do you think could solve this? I can think of two - ATMs, credit cards)

3) I end up paying a lot of late fees because I forget to mail my payments on time or because the postal service takes more time to delivery my check to the credit card company. For example, last month I ended up paying $58 in late fees. It is hard to predict when exactly to mail the payment. I cannot afford to send the money way ahead of time because I have to wait for paychecks to get deposited (Could very well have been one of the pain points that created online banking)

You get the idea. It is very easy to fall into the trap of starting to describe product requirements and not pain points. It is not easy to do tjos because the creative part of our brains loves to start thinking about how to solve the problem. But take control - make sure that you understand the pain points very clearly before you start listing requirements or evaluating product ideas.

My previous post was about how product managers should think more about customer experiences. I had mentioned about how I have had the most memorable product experiences when I bought my iPod and my iMac. Here is another one that is service related that has truly been enjoyable. For the last one year, we have been seeing doctors who are associated with Fallon Clinic. I am truly impressed by their service because of the attention they have paid to details. Everytime, I show up for my appointment, they print a page of labels with all the pertinent information - my name, my phone number, my address etc. on these labels. The doctor then uses the labels on all the forms, prescriptions that he writes. Not a big deal you think until you show up at the pharmacy or at the labs. I no longer have to repeat all this information over and over. I use the pharmacy drive thru, hand off the prescription and off I go - nothing else said - the label has all the information the pharmacy needs.

This is a classic example of walking thru the entire customer experience and then designing a solution. Fallon Clinic did not have to do this, they could have easily dropped this feature and put the onus on me - after all by showing up for the appointment, the clinic get its money. Instead, they chose to make my life easier - net result they have won a long term customer who is now spreading the word.

Not often !! Think back to all the products that you have bought in your life - for how many of them has the buying/first usage experience been so good that you have remembered it. In my case - exactly two - iPod and iMac. In fact, I was so impressed with my iMac packaging, I took pictures while I was opening the package (see below). Setting up the machine was so much fun that I did not want it to end.

Horrible first use experience permeates both hardware products and also computer software. I think before any new products are released to the market, the executive management and product managers should watch some real people (not designers, not developers) try to use their product the first time. That should stop claims every marketing department loves to make - easy to use, easy to deploy (my foot !!).

Steve Johnson of Pragmatic Marketing in his blog post On buying and using describes his horrendous first user experience with a JBL portable player for his iPod. Such examples are everywhere - so why do great companies like Apple get it right - they take the time and give it the right amount of priority during design. They are not necessarily smarter than the rest of us, they just know that their products are going to be used by people who are very different from them and hence take the time to think how best to design the product to make it easy.

Steve points out how product packaging gets shoe horned into a one size fits all approach for all sales channels because one of the channels exhibits high incidence of product theft. Companies should start paying more attention to how customers buy if they want to make differentiation especially in product areas where all products are starting to look like. After all, good looks sell. Otherwise, you will have people like Steve and me openly writing about our horrendous experiences with products on our blogs for the rest of the world to read. Welcome to the new world of bad PR !!

This morning, while walking through Terminal 3 of the San Francisco airport to get to my gate, I happened to notice the design museum display near the moving walkways. The museum is titled “From Prototype to Product: Thirty-three Projects from the Bay Area Design Community“.Behind each display, were quotes of some famous people.

One of them caught my eye - it said ““The ability to simplify means to eliminate the unnecessary so that the necessary may speak”. After getting home, I googled it to find that it is a quote by Hans Hofmann. The reason I find this quote very interesting is because it captures what good product design is all about. Designing a good product involves spending more time deciding what features NOT to include than deciding what features to include. I would bet that designers of iPod had all the pressures to add a zillion features to it - an AM/FM radio station, ability to add/edit/delete songs etc. But they did not - because adding all of these features would have destroyed the elegant design. The end product does not do everything, but what it does it does very elegantly. To this day, I would be willing to pay more for a remote control that would do the five things I want to do - play, stop, forward, rewind, power on/off, instead of the other 500 features it has making it impossible to find these features. The office phone is another example. Try doing a conference call.

To do this right, you need to understand who your target user is and then saying no to features that are not needed by target users. You cannot listen to sales, they will tell you that you need everything under the sun. You cannot listen to just your existing customers, they will ask you for more and more features. What you need to do is get out and talk to real people who want to use your product - especially people who have not yet bought your product. Observe them struggle using the current products (your products or competitors) and then figure out what you can do to simplify their lives. It is not easy, but good things never come easy.