Product Management Tips by Gopal Shenoy

When I interview candidates, the first question I ask them is to give me their elevator pitch in one minute. Many candidates resemble a deer caught in the headlights and I am very surprised. If you cannot explain who you are, what you can do for the company, your strengths in one minute or less - are you a good candidate?

I give them one minute only because I have sat through 4-5 minutes of torture when I used to ask the question “Please tell me about yourself” - believe it or not, I have heard everything from how the CEO in one of their previous employers sucked to how the candidate filed a patent on some esoteric stuff that had nothing to do to what we do. If the open position is for a product manager, it is a good question to ask because product managers have to create positioning statements, give an elevator pitch about their products to prospects. This also displays the communication skills of the candidate.

Elevator pitches should highlight your strengths so that it piques the interviewer’s interest that he wants to know more about it - now the ball is in your court where you can further substantiate on your strengths and make the connection as to how those strengths can help the company.

So what is your elevator pitch?

I have been thinking lately of all the software tools and resources I use everyday to get my job done and to get better as a product manager - here is my list in no priority order.

1) MS Office
2) Outlook
3) Google
4) GotoMeeting, Webex - to have customers take a look at early mockups, do usability testing, review comments on specs from customers in real time, webinars etc. - GotoMeeting rocks, webex and live meeting suck.
5) Photoediting software - Photoshop Elements, Paintshop Pro etc. - to do very quick mockups of concepts
6) Snagit - I can’t tell you much I love this tool

7) Websites - LinkedIn, ZoomInfo - get information on who’s who at a prospect or a customer

8. Salesforce.com - to get customer contact info and understand what products has the customer bought etc.
9) Internal Bug database - report bugs, do bug mining before I land up at a customer site.

What I read regularly though not as much as I want:

1) Business Week
2) Fast Company
3) Enterpreneur
4) Aska Good Product Manager blog
5) How to be a Good Product Manager blog
6) Ecommerce times

I would love to hear other great tools or resources you have found very useful as a product manager.

Software vendors have been struggling to find a solution to thwart software piracy with very limited success. Anywhere from 70-90% of software used in Asian countries like India, China, Vietnam and in the former Soviet republics is estimated to be pirated. There was nothing you could do when pirates made copies of packaged software and easily cracked the reg codes and other security measures devised by the software industry.

Now that software as a service (Saas) is picking up steam, would’nt this help thwart piracy? You pay for such software based on a subscription model and the software is hosted with the software vendor. You don’t pay, you don’t get to use it and this can be done easily by flipping a switch. You buy licenses for 10 concurrent users, the vendor can allow just that - 10 concurrent users.

Is this the nirvana that the software industry has been long waiting for?

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.

Last weekend, I volunteered to spend an hour at our local grocery store handing out flyers to shoppers on an upcoming Town hall vote on Grafton school feasibility study. We had a simple decision to make - do we hand out the flyer when shoppers are coming into the store or when they are exiting the store after they are done shopping. We chose to do the latter - for a very simple reason.

When shoppers walk in, they are thinking about one thing and one thing only - SHOPPING - what do I need to buy? where do I need to start? I should not forget to pick up the gallon of milk etc. - anything that breaks their train of thought is an interruption and an unwanted intrusion. If you now give them the flyer, here is a very likely scenario:

1. They are unlikely to read it
2. They will put it in the empty cart and the groceries they buy, end up on top of the flyer
3. When they check out, they will leave the flyer in the cart
4. They will load the groceries into the car and the flyer ends up left behind the cart.

When shoppers are exiting their store - they are happy that they finished shopping and are headed out. They are more likely to be receptive to your pitch when you hand them the flyer. Here is a very likely scenario:

1. They are likely to put the flyer into one of their grocery bags or carry it with them in their hand.
2. The flyer makes it to their car and their home
3. It has more chances of being read

Now you can see why the simple decision to hand it out at exit works in our favor.

I can think of many such scenarios when I use different products:

1. When I visit a website that offers a free service, I get interrupted by ads that I have to get past before I am allowed to complete the task. Just because you offer something for free, it does not make it acceptable to force an ad on the user - allow them to have a positive experience and then once they are done, thank them and have the ad appear. They are more likely to look at the ad now that they have had a sense of accomplishment of having completed their task - they are more relaxed. You helped them and they are more likely to help you.
2. Asking users to register before they can read marketing white paper that brought them to your website. Let them read enough of an outline so that they know if it worth their time and then if they want to read more about it, ask them to either login or register - and tell them why your are asking for the information - so that you can improve their user experience, provide them more of such material etc. - whatever will benefit them. They are likely to give this information to you, now that you have helped them. Or give them the first one free without needing to register and ask them to register when they try to access the second white paper or on their repeat visit.

These may sound obvious when we are the consumers of products or services, but when on the other side designing these products or services, we may get too hung up on our business agenda as opposed to the needs of the users of your product. Try walking in their shoes and see if it makes a whole lot of sense. Go with your gut feel, you will usually be right and if not talk to some real people (people outside your company and get a second opinion.

Your perspectives and comments welcome !!

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.

Recent news article about the airlines report how they are looking at flying slower to save fuel costs.

Consider these numbers from the above article …..

$42 million - Southwest Airlines will save in fuel this year by extending each flight ONE to THREE minutes.

$13.6 million - Jet Blue saves by adding about TWO minutes to a flight

$600,000 - Northwest Airlines saves a year by adding FOUR minutes to flights to and from Hawaii

and so the list goes on …

ONE TO FOUR MINUTES and this much payback?

As a product manager, here is what I took away - small nuggets of change could result in big payback. It does not necessarily have to do with the product, it could be in operations as well - whether it is making tech support calls efficient, whether it is how you optimize your software packaging to save shipment costs etc.

Important thing is to think out of the box and leave no stone unturned - not just the big stones, but many small ones as well - you never know what small nuggets you will find.

The latest Business Week cover story reads Mac in the gray flannel suit and talks about how more and more corporations are now allowing their employees to use Macs in the office. Apple on the other hand has shown no interest in catering to this market.

The above article is definitely worth reading. Here are some of the key points that I thought were worth a highlight.

- While Apple is getting all this attention, Microsoft CEO agrees that Vista is still a work in progress - so what do they do - force it down the customer’s throat by saying you cannot get XP past June 30. Microsoft’s Windows marketing VP says “The thing that can best help perceptions is more and more people using Vista” - this is what I call arrogance - we know it sucks and we want to make sure that we inflict the pain on everyone we can - great - just the thing your customers need.

- Apple’s average selling price has gone up to $1526 while the cost of average PC’s has gone down from $1046 to $963 in the last three years

- Apple’s market share of the personal computer market is now on pace to hit 7%.

You can call it arrogance on Apple’s part not to cater to the corporate world, but I want to commend Jobs in understanding where he wants to take his company (consumer, consumer, consumer) and sticking to it.

This is something very hard to do for many companies. Smelling and chasing a new stream of revenue defocuses companies and finally leads to their failures or demise. Apple knows all about this - having made that mistake in the past.

But what a great situation Apple finds itself in - the student community - one of Apple’s strongest users of iPods and iPhones - now are their sales force when it comes to corporations. Would’nt you want the world to beat a path to your door?

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.