It is all about the “right” metric

September 27, 2008 3 Comments

Remember the old adage – You cannot manage what you cannot measure. As product managers, we have to measure revenues, number of licenses, performance of our products and a slew of other things.

It is not that we don’t measure, but unfortunately, we measure using the wrong metric. Let us specifically look at two examples of how using percentages can be wrongly used.

1) Product performance: When new product releases come out, many companies tout improved performance and say “this new release improved performance by 50%”. This does not mean anything to the customer. Does a particular task now take 5 sec as opposed to 10 sec or is it now 50 sec instead of taking 100 sec? None of this matters if the customer expectation is to do the task in 3 sec or less. From the customer’s perspective, your product’s performance still stinks.

Instead measure your product performance against customer expectations and then find out how far you are from the expectations. If the customer expectation is measured in an absolute number – finish this task in “X” units of time then the performance has to measured in the same units. Only if the customer expectation is to reduce scrap or product deficiencies by 50%, then does % matter.

2) Resumes: I come across so many resumes where candidates claim their achievements using percentages – increased revenues by 100% or increased number of customers by 50%. Again, it does not convey much. Did the revenues go from $1 to $2 or did it go from $20 to $40M or from $200M to $400M? What is the hiring manager’s point of reference – he/she is likely looking at an absolute scale and not a relative scale. And if you are going to make a claim of 100% and the absolute increase is from 1 to 2, then you may want to leave it out unless say it was a multi-million dollar deal. Otherwise you will make a claim of 100% increase only to be exposed during the interview.

Sounds very simple right, but then you probably have seen as many instances of the above as I have.

Image: Courtesy of dvice.com

Filed under product management

Customer’s Wants vs. Needs

September 21, 2008 1 Comment

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

Filed under business, customer needs, marketing, product management

Need a head and a date

September 17, 2008 1 Comment

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.

Filed under business, leadership, marketing, product management

Benefits of early usability testing

September 15, 2008 1 Comment

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.

Filed under business, customer needs, marketing, product management

Google Chrome vs. Cuil – Product Management Case Studies?

September 12, 2008 1 Comment

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).

Filed under business, customer needs, leadership, marketing, product management

Saas model will collapse in two years – What?

September 2, 2008 3 Comments

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?

Filed under business, marketing, product management, saas

Follow

Get every new post delivered to your Inbox.

Join 176 other followers