Demo candy may not be sweet after all

Hey, it is Halloween time, so let us talk about some candies. Heard the term “demo candy”? – almost all of you probably have. Features that are thrown into a product because it appeals to the emotions of the buyer but basically a feature of less practical value.

But there are some demo candies that are going to be hard to defend. Everyone these days is talking about the iPhone. iPhone has such sex appeal – so should vendors need to jump on this bandwagon and build demo candies? Probably not, unless both of the following are true:

  1. Vast number of your customers (at least 30%) are heavy users of iPhone.
  2. Users have the need to interact with your application so often that they are very likely to use the iPhone to use your application.

If either of the above is not true, then it is not worth developing support for iPhone. For example, vendors in the HR space have started developing mobile support for career management and performance reviews. Now think about this for a second, can there be a convincing argument that you need access to these apps so often that you need to get to them via a mobile phone? And even if they did, can you imagine filling out a performance review form using the tiny mobile phone screen? Does it improve usability – No? So what does this actually solve. In my mind, nothing and I am not sure this demo candy is going to be sweet after all?

One can argue that more customers will own iPhones in the near future but what about point 2. Even if 100% of your customers have iPhones, will they need (and even want) to interact with your product via the iPhone? That is the most important question you need to answer.

Or am I completely missing something? Your thoughts?

Photo source: vendingdistribution.com

WBUR/NPR is not “On point”

I listen to WBUR/NPR every day on my 50 min drive to/from work. I listen to the BBC World news (and it really is world news) at 9am and to OnPoint with Ashbrook at 7pm. At last, I had found one radio station that I looked forward to listening to and getting quality news in the current day and age where you get everything else from the Internet.

Everything was going so well until WBUR started its fall fund raiser. I am a big fundraising proponent for worthy causes and I consider WBUR to fall very much into such a category. The first time I heard about it, I immediately called them up and donated money. But I started finding out that as days went by, this fund raiser announcements were becoming a nuisance. They have been so frequent that I get to listen to these fund raising pitches more than I get to listen to what I tuned in for. For example, BBC world news used to start at 9am sharp. These days, at 9am, I get to hear the fund raising pitch that the BBC news is now getting delayed.

It has become so annoying that I now think twice before switching to WBUR and even when I do, I immediately switch to another station at the very sound of the fund raising pitch. So has WBUR/NPR overdone it – absolutely yes, if you ask me.  With such frequent fund raising requests interrupting the programs their audience want to listen to, WBUR/NPR has forgotten the needs of their audience and instead has become more tuned into their needs. Don’t get me wrong – they need the funds, but so do other radio stations.

What would I recommend WBUR do? – have a smaller pitch – a 20 sec slot every 30 min that points people to a website where they can donate. People like me who really like their service will take the time to contribute. Screaming loudly at your listeners and even to those who have already donated is not going to help. In fact, it may do just the opposite. You are likely to turn them away.

My impressions of wbur has soured a little because of this campaign and I strongly believe they could have executed this a whole lot better with a little more thought.

Customer’s Wants vs. Needs

A customer’s wants vs. needs – This subject has been part of numerous conversations I have had in my working life. Every time I go to India on vacation to visit my family, I always think about this topic. I come back from these trips thankful of what I have and telling myself to appreciate what I have. Whenever I discuss this with friends or whenever anyone asks me what it is to live in India, I draw the following spectrum.

I explain that the vast majority of the US population falls in the WANTS spectrum. We have everything we need, we own/rent a house, we have food to eat, we drive cars or ride a bus, we have TV’s, we have electricity and running water. But we are constantly focusing on satisfying our WANTS with the next better/faster/safer gadget.

India however has a vast majority of its population still living in the NEEDS spectrum. All the IT improvements and the other technology advances that the country has made is still a drop (though a good size one) in the bucket that has made a small chunk of the population to move into the WANTS spectrum. Do not forget that India is a country of over 1 billion people.

So, why does all of this matter to you as a product manager. I liked what Seth Godin said at the Inbound Marketing Summit “We are living in a society where we have everything we need and hence we are left selling what customers want”. It is extremely important for us as product managers to clearly understand what our customers are asking for – is it a real need or is it a want?

Some customers may pay money if you satisfy their WANTS, but more customers will pay a whole lot more money if you satisfy a NEED that is unmet by you or by anyone else in the market place. So whenever you are talking to customers and they propose needed improvements, do the following

  1. First understand the underlying problem
  2. Second find out if it is something they NEED or WANT
  3. Third, is it a large enough NEED/WANT that they will pay you money if you solve them and
  4. Fourth, build solutions for ONLY those problems which a LARGE number of customers are willing to pay you money for.

Liked this article? Leave me comments – I would love to hear your thoughts – or get an RSS Feed to this blog
Bookmark and Share

Need a head and a date

As product managers, we have to work with a lot of departments – engineering, qa, order admin, finance, shipping etc as part of creating the product and then putting that product into the market.

Doing all of this, involves choreographing and managing a lot of activities, so that the final dance that results meets the customer expectations.

Here is a common answer I get when I ask people to commit to a date when a task assigned to them will be completed by them – “I am not sure, I have a lot on my plate”. Great, you think I don’t have anything else to do?

Don’t accept this answer but counter it with the following – “OK, I understand you are very busy and you may need to get more information before you can commit to a completion date. But can you give me  a date when you will get back to me with a firm completion date?” This way, you are asking them to commit to a date to a date. To this, people will usually give you an answer.

Then when you end the meeting minutes, assign the action item to the person to get back to you with a completion date. Hold them accountable to the entire team and not just to you. Yes, unexpected things will come up, they always do, but you cannot run a business without a head and a date for each task.

Benefits of early usability testing

You do not need an Alpha/Beta software product to do usability testing. In fact, if you wait until then to do usability testing, you have waited too long. This late, making changes based on usability feedback will be costly and time consuming and apt to break something else.

The resistance offered by a software developer to change is directly proportional to the number of lines of code he has written. So the best time to do usability testing is before anyone starts coding anything. Make a bunch of images that show the proposed UI and create a click thru either using html pages (drop me a comment if you want to know how) or using powerpoint.

Then test with a bunch of your prospects/customers. Your customers/prospects should jump at a chance to see a preview of what you may be coming out with. Two things will come out of this testing:

1) You have nailed the usability (great position to be in, but very rare)

2) You will uncover some small or large usability issues.

Great! to make these changes is inexpensive, it will involve only your time, not that of your team. I don’t mean you are cheap, but in relative terms it is just your time.

Here are some guidelines to do usability testing with early mockups

1) Think about the main personas and their main use cases

2) Create mockups for these use cases

3) Never lead your audience – ask your testers to tell you how they would do the task given the mockup – if there is a large deviation between how they think they will do the task and how you will let them do the task – you have a serious usability issue.

4) If they tell you that they like something or don’t like something, ask them why – in either case, you need to know why – this is a wealth of information that will help you later when the product is built. You may even uncover some unique use cases by probing your testers here. You may hear things like – “Interesting, wonder if we could use this product to do X, Y and Z” or ” Hmmm, not sure if we would want to do this because later on we may run into problems A, B and C”. – again, great insights to get early on.

As you are doing this, ask them for their value proposition for what they are testing. Do they see value in it, if yes, what and why? If not, why not?

It usually takes only about 5-8 testers for you to see usage patterns and convergence of issues. If you see issues very early, quickly fix them before you continue to test with the remaining testers.

This is something I have successfully done for a long time with great success. Not doing usability testing very early on, is leaving things for chance. All you really need is some jpegs, a web conference tool like webex and 5-10 testers for you to work a lot of kinks out of your product early on.

BTW, invite your developers and QA testers also to these usability tests so that they are participants. This way you will get less resistance later because they will better understand the insights behind the UI that you will be asking them to code/test soon.

Google Chrome vs. Cuil – Product Management Case Studies?

By now, many of you are well aware of two new products that came out this summer (and if you have not, you were probably enjoying the summer a lot more than I was) – a new browser from Google called Google Chrome and a new search engine from a startup called Cuil

I was excited by both of these products and decided to try both of them. I had trouble getting to the Chrome download server but I waited patiently to get to it the next day. I found both the products to be buggy and gave up on Cuil and have never been back to it even once. I found Google Chrome to be buggy as well and uninstalled it because it did not work with my anti-virus software. So the initial product usage experience was the same, but there is one big difference.

I have talked positively about Google Chrome to a lot of people and given it glowing reviews – I have told them it was buggy, how I had to uninstall it and how I expect that these issues will be fixed. I have not talked to as many people about Cuil and to those who I have talked to, I have ridiculed it. I talked about what a joke it was and why I even needed another search engine when Google works so well.

So why am I spreading the positive word about Google Chrome though my first taste of it left lot to be desired? Interesting, isn’t it. Here is my analysis.

What is wrong with Cuil?

Very simple. It does not solve a problem I have. OK, you could say that you index more pages than Google but to me as a user, anything past 20-30 search results is Siberia. So the only yardstick is “Are the first 20-30 results better than what I get on Google” – No. So why do I care. So where is the product differentiation? No reason to switch from the incumbent vendor I use.

What is right with Google Chrome?

  1. Yes, the product is buggy (and aptly called Beta), but I buy into their vision. They have designed the web browser from the groundup to support web apps – at least that is what they claim. I buy into this vision. It does not solve my browsing problems today, but I know web apps are the future. So they are ahead of the game – they are looking out into the future for me.
  2. They released it in a very novel way – using the comic book concept. Very novel, again out of the box thinking.
  3. A company I respect tremendously for past innovations and I use their innovative tools everyday. If they have not got it right yet, I have the confidence that they will. Read “incumbent/entrenched vendors are always at an advantage”.
  4. When I had the issue with anti-virus software, they already knew about it and said on the forums that they were working on a solution – they were listening – they are on top of their game.
  5. They made it open source – they contributed their code base to the software community – I already know about the success of Firefox – they did not beat their chests creating another proprietary product, they are letting everyone use their innovations.

Product Management Lessons:

  1. Solve a real problem customers have (or will have soon)
  2. Incumbent vendors have a big advantage – to make users switch to your product, it needs to absolutely rock. If you are just a “wannabe” or if your differentiation is some metric which no one cares about, users will not switch.
  3. Past vendor success generates respect. Once you gain that respect, you will get a longer leash from your users (same applies to product managers too).

Saas model will collapse in two years – What?

In a mind numbing interview with ZDnet, Lawson Software CEO Harry Debes made the prediction that Saas software model is bound to collapse in two years. Even if I try to put aside his opinion (however dumbfounded it is), what I cannot comprehend is how a CEO of a public company can call his customers stupid and that they are addicted to software like they would to cocaine. Read that again – stupid? cocaine?

In his interview, does he say anything about benefits to his customers that Saas brings to the table? It all seems to be a pitch on how beneficial on-premise software model is to the vendor – profitability, captive customers, switching costs etc. I wonder if Harry has a clue as to the pain points involved in installing and upgrading on-premise software? Maybe he should so that he can feel the pain of his stupid, cocaine addicted customers. Maybe companies like Google, Microsoft are all stupid too for having Saas models for delivering software.

While I totally agree that Saas is not the panacea to solve everything that is wrong with software, that many of the Saas vendors are not yet profitable, I cannot come to terms with him calling his prospective buyers stupid.

What is next to collapse Harry – social media?