Software Product Manager by Gopal Shenoy

January 21, 2010

4 lessons from Massachusetts Senatorial election

Filed under: product management — gopalshenoy @ 8:13 pm

The results of the Massachusetts senatorial election this week to elect the replacement for the senate seat held by Ted Kennedy shocked the entire nation. A Republican named Scott Brown who not many people had heard about about as recently as a month back won the seat convincingly in a largely Democratic state. Ted Kennedy had held this seat for the last 46 years. As recently as Jan 1st, the Democratic candidate Martha Coakley was considered a shoo-in for winning the seat. But then she lost. The repercussions are large with Democrats losing the filibuster majority in the Senate and President Obama’s health reform in its current form nothing but dead. What an irony. Ted Kennedy had spend his whole life championing health care reform.

As a software product manager, I took away the following 4 lessons from this election:

  1. It ain’t over ’til the fat lady sings – I am sure all the pollsters who advised Martha Coakley told her that she was a definite win. She did not run a hard campaign. In the corporate world, often times sales thinks that a deal is in the bag long before the deal has been signed. No, it is never done until the signature is on the contract.
  2. There is no entitlement - Yes, the seat was held for 46 years by one of the legends in the senate. It is a largely democratic state. But none of this gives anyone an entitlement to a senate seat. You could be the incumbent, a highly entrenched software vendor in an enterprise, but this does not give you the entitlement that you will always win all the future deals. Companies switch vendors all the time. So in every deal, give your best fight as if your whole business depends on it. This is the only way you can guarantee a win. For the election, people send a clear message as to who are the decision makers. In your sales situations, don’t forget that the customer has the last word.
  3. Keep the message simple - I don’t remember one thing that Martha Coakley said. But for Scott Brown, I know about him riding around 200,000 miles in his truck campaigning, his message that he is the 41st vote. I did not vote for him, but he kept the message simple and it resonated with the electorate. That is all that matters. Your customers do not know as much about your products/technology/company as much as you do nor do they care. But they know about their problems, their products, their business, their company much more than you ever will. So make it relevant to them and keep it simple, if you want to win.
  4. Don’t forget the network effect – The election was for one senate seat, but it drew world’s attention. The impact has been earth shattering. In your sales situations, losing a customer may appear like losing just that – one customer. But in the social media age we live in, how many are going to find out and how many are you going to lose based on this one customer’s influence? On the flip side, it may sound like one new customer, but how many new customers will this help you win? I remember from my SolidWorks days that winning Halliburton was a huge deal for us. Because it helped us establish a beach head in the oil and gas vertical and since then, it helped us win so many large customers in that vertical. So be aware that every action you take may have a network effect – consider this before you act.

Thoughts?

Image: Courtesy of aphr.wordpress.com

If you enjoyed this post, please consider leaving a comment or subscribing to the feed to receive future articles delivered to your feed reader or by subscribing by email via the text box in the right column.

January 18, 2010

Communications – RASCI approach

Filed under: team communication — gopalshenoy @ 12:55 pm

I am currently reading the book Art of Scalability by Marty Abbott and Michael Fisher, both of them ex-eBay executives. An approach they have described to make sure the entire product development team stays on top of things caught my attention. The model they recommend to use is called the RASCI model. It stands for:

R – Responsible – Individual(s) responsible for a task, project or initiative.

A – Accountable – Individual(s) to whom R is accountable to for the completion of the task, project or initiative. This individual(s) will need to approve the task, project or initiative before it gets underway.

S – Supportive -  Individual(s) that will need to support the task by providing resources towards completion of the task, project or initiative.

C – Consulted – Individual(s) that may need to be consulted because they may have data or information that will be useful to complete the task, project or initiative.

I – Informed – Individual(s) that need to be notified or kept informed of the progress of the task. They do not need to be consulted or asked to provide input to the task, project or initiative.

I believe that communications is a root cause for many of the organizational problems. For whatever reason, there is a tipping point in an organization’s growth where communications is ignored because it is taken for granted – “of course everyone knows” is a bad assumption that often gets made – and the net result ends up to be big surprises, annoyances, discontent and frustration.

Given that we as software product managers have to communicate with most of the other departments in the company, I thought the RASCI approach would come in very handy. I have previously written a post where I believe that if there is no head or a date associated with any task, it is not getting done.

About the book

Full disclosure – I was send a free copy by Michael Fisher so that I can read it and write a review here. While I am still reading it, I like the novel approach they are recommending for creating a scalable company. Given that both of the authors are highly technical, I expected the book to be about how to architect your software such that it can scale and not have any performance degradation as the number of users grow. Instead, the book is more about how to create an organization that will scale when business grows. Based on what I have read so far, I do recommend that you check this book out.

Have any of you read the book? If yes, what are your thoughts and comments?

If you enjoyed this post, please consider leaving a comment or subscribing to the feed to receive future articles delivered to your feed reader or by subscribing by email via the text box in the right column.

January 14, 2010

Donations for Haiti earthquake victims

Filed under: business — gopalshenoy @ 1:54 pm

Sincere request to all readers of this blog :

Unconfirmed reports in the aftermath of the Haiti earthquake put the death toll at 50,000 and the suspicion is that 100,000 may have perished. The earthquake has affected more than 1 million people. This makes this earthquake a disaster of epic proportions.

I am making a request to all of you to make a donation towards rescue and relief efforts in the aftermath of the earthquake in Haiti. The two organizations that are well known for their disaster response and also for administration of their donations are the American Red Cross and Oxfam America.

If you already have made a donation, Thank You  and if you have not, can I count on you to make any donation that you can?

If you could let me know the donation amount you have pledged by leaving a comment to this post, I would sincerely appreciate it. My sincere thanks to all of you in advance and God Bless.

January 13, 2010

Software product manager’s first 45-90 days at a new job ….

Filed under: business — gopalshenoy @ 11:24 pm

This is a continuation of my previous blog post of Software product manager’s first 30 days at a new job …..

Now that you are already settled into your new job and the first 45 days have gone by. You have done everything that was listed on the 30 day checklist. You have met with the stakeholders, they know who you are, you know the product, you are gaining momentum. Now what next? (BTW, in case you are wondering why I skipped the time period from 30-45 days, read on.)

It is hard to describe what the next steps need to be because it will depend on many factors such as organization structure, where the product is in its life cycle, your vertical etc. But here are 4 things I recommend you do during these 45-90 days to keep up the momentum. I think these 4 things apply no matter what product you are managing.

  1. 90 day plan – If your boss and you have not already put a next 90 day plan, you put one together. Create a proposal on what you think you need to accomplish, where you need help from your boss etc. Then sit down with your boss, refine it and finalize it. This will speak volumes to your boss of your organizational skills, your ability to set goals etc. But then, make sure you follow them and get it done. Achievements and not goals are the only things that matter after everything is said and done.
  2. Customer visits: Try to visit at least 5 current customers. If customer visits are not possible, try to make phone calls at the very least. If I am still not completely comfortable with the product/service by now and are nervous to engage with a customer, I try to go with someone else who may be visiting the customer. This could be a sales person, another product manager, customer support person etc. Here is what I typically tell these customers during these calls:
    1. I am new to the company (sets expectations that you are not an expert on your product yet)
    2. I introduce myself to them including explaining what my role is (believe it or not, many customers don’t understand what a product manager does, I also tell them that my call is not to sell them anything)
    3. I want to understand their business processes and where my product fits into their business process
    4. Understand why they chose to use my product or service?
    5. What do they like about us?
    6. Where do you think we fall short? Make sure that you set expectations that you cannot commit that these will be fixed. Remind them that you will get the information to the right people and that you are still a newbie.
    7. I want to build an ongoing relationship with them to make sure I continue to listen to their needs and painpoints, run future ideas by them to get their early feedback etc.
    8. I leave my direct phone number and email with them

    Write a report on what you heard from customers (good and bad) and send it to your product team and other stakeholders. This will help you build credibility within the organization that you are quickly getting up to speed and that you have started gathering real market data. In the future this credibility will help, because others won’t mistake your recommendations to be just your opinions but instead ones grounded in market facts.

  3. Secure early wins in areas that are important to your boss and where you build credibility within your organization. But before you commit to do anything, get permission from your boss. While the idea is to start getting yourselves en-grained into the process, you also don’t want be the newbie to be assigned a task by someone because it is an unpopular task and a setup for failure. What you should be looking for are tasks where you can start making contributions that your boss and others in the company start recognizing you and getting to know you. Try to find tasks that others may not want to do – that is OK. The idea is to help the team win. This may be anything such as:
    1. helping putting together a customer presentation
    2. updating the product roadmap by incorporating the latest changes
    3. testing a new piece of functionality that has been implemented
    4. helping with usability testing on a new feature (helps you get in front of a customer, observe and listen to how they react to your product)
    5. providing your input on a small feature that is going to be implemented. Research how the feature needs to be implemented, write requirements document. Believe it or not, this will help you understand all the inner workings of your product – what it takes to make even simple changes.
    6. writing release notes for an upcoming new release
    7. helping fill out an RFP from a prospect etc.
  4. Product demo – Call a meeting with your product team and anyone else who think can help you. Tell them that you would like to do a product demo to them to simulate a customer situation. Let them know that the whole point of the exercise is to gauge where you stand in terms of knowing your product in and out and also figure out gaps which you need to fill. This event is not because product managers will be demo jockies, but because you as a product manager must be able to demo your product in the event of a crunch.

Now why did I leave out the 30-45 day period. Only because I think to complete everything that was listed in the previous post will likely take you 45 days. Stakeholders will ask you to reschedule your 1 on 1 with them, you will run into hurdles such as getting accounts setup for all the tools you need to use etc. And if you don’t and you are rocking, I am sure your boss will give you new tasks to do that you had not planned for.

Thoughts?

If you enjoyed this post, please consider leaving a comment or subscribing to the feed to receive future articles delivered to your feed reader or by subscribing by email via the text box in the right column.

Image: Courtesy of hamiltonbeach.com

January 6, 2010

Software product manager’s first 30 days at a new job ….

Filed under: product management — gopalshenoy @ 6:45 am

Happy New Year! I wish you all a prosperous 2010.

So you found a new software product management job or you are moving into a software product manager’s role in your current company. Congratulations! Now what do you do in the first 30 days to make sure you start off on the right foot? Here is a list I have successfully used in the past when I have switched jobs. I hope you find it useful.

Company’s vision and Business Strategy: Your focus should be to first gain a solid understanding of the company’s vision and business strategy and take stock of what exists within the company. Specifically, find answers to the following questions by interviewing internal resources:

  1. Company’s vision and business strategy
  2. What are the current hypotheses?
  3. What are the data points (customers, research sources, analysts, partners etc.) that have been used to arrive at the vision and business strategy?

Target market: Who are we selling to?

  1. What segmentation and sizing has been done?
  2. Which segments are we targeting?
  3. What do we know about the target market?
  4. What do we not know about the target market?
  5. Who are our top customers today?
  6. Who are the customers with the largest potential?
  7. How is market research done? Customer visits? Surveys? Focus groups? Advisory boards? User conferences?
  8. Which customers have we talked to? Key learnings?
  9. Which customers should we talk to next?
  10. What are the pain points that exist in this market that customers are willing to pay for?
  11. What is a typical sales process and how long does it take?
  12. Is there a win-loss document that will give you an idea on why you win and why you lose?
  13. Common objections that are raised in a sales situation
  14. Why do customers buy from us?
  15. What is our unique value proposition?
  16. What solutions are prospects using today? Or in other words, how are they solving the problem today?
  17. What are the pain points of their current solution?
  18. What is the business impact ($, outdated information, process inefficiencies etc.) caused by these pain points?
  19. Have they tried to solve these pain points? And?
  20. What are they planning to do to solve these pain points and what is the urgency?

Your company may not have the answers to all of the above questions, but asking all of the above will help you identify the gaps that you should look to fill.

Competitive Analysis: Who are our competitors?

  1. Who are the main competitors? If you are breaking new ground, is anybody else trying to do anything similar? If yes, what are they trying to do? Traction?
  2. Has anyone talked to competitor’s customers to understand how their solution is working for these customers? Why did they buy?

Get to know your product

Simulate the experience of a new customer. Install your software (if on-premise) or create a new account (if a SaaS product) and learn everything about your product that you can. Understand the development process from identifying needs to writing requirements documents to getting it build, tested and shipped. Attend every meeting you are invited to.

The four ways I have done this are:

  1. Take all the product training that exists
  2. Read through the documentation (Yes, do the RTFM – this may be the only time you would do this)
  3. API documentation (if API exists) – this will allow you to quickly understand different aspects of the system
  4. Specs – read through as many functional specs as you can. It will give you a history of the product and also quickly understand what exists, why it exists and what it is supposed to do.

Your goal should be to be able to demo your product to your peers after the first 45 days. I would recommend that you do not use any demo material that exists today such as product presentation slides etc. Make your own. Can you explain in very simple terms of how your product will help your customers? By making your own slides, you will be forced to think and learn stuff as you are putting your slides together. Just using the current demo material is not going to help as much.

Tools used

Learn every tool that is being used in the company. Ask your manager to get you a personal account in these systems if this has not been done already. This would include

  1. CRM system such as salesforce
  2. Enhancement request database (if one exists) where customers submit requests
  3. Bug database
  4. File servers where important information is stored or can be stored for backup purposes
  5. Specs database
  6. Reports server – where are product usage reports stored? Where are key financials regarding your product stored?

Who do you need to talk to internally?

Given that software product manager’s job is the most cross-functional job you will ever find in a company, you need to plan on sitting down with key stakeholders in every department that touches your product from start to finish. Ask your manager to help you create a list of these key stakeholders.

This includes the obvious ones such as engineering, sales, marketing and also departments such as QA (how do they test your product), order admin (if appropriate – how does a new customer’s order get fulfilled?), shipping (if appropriate – how does your product get to the customer?) etc. Again, you have to understand the entire process from start to finish and get perspectives from everyone involved in the process. Believe me, you will learn something new from every one you see.

Understand people dynamics

This is the most important part, more important than even your product in the first 30 days. You have to start building relationships from day one. Every company has some form of internal people dynamics that you need to observe and learn as you get used to your new position especially in a new company.  People may approach you and tell you stuff (good and bad), but never get involved in any gossip (not that this is just when you are new in your job, gossip is never a good thing) and never take any sides no matter who says what to you. Stay neutral, keep your thoughts to yourselves, just observe and make mental notes.

The last thing you want to do in a new job is to step on the wrong shoes accidentally. Be the most professional as you can be, never let your guard down. But don’t be wooden, start building relationships.

I strongly recommend the book The First 90 Days: Critical Success Strategies for New Leaders at All Levels by Michael Watkins. Great book with great strategies that will help you ease into your new job.

Thoughts? What have your experiences been? What has worked for you and what has not? What are the pitfalls you would advise other software product managers to avoid?

If you enjoyed this post, please consider leaving a comment or subscribing to the feed to receive future articles delivered to your feed reader or by subscribing by email via the text box in the right column.

Image: Courtesy of wondercliparts.com

December 13, 2009

SEO Basics for Software Product Managers

Filed under: SEO, product management — gopalshenoy @ 1:09 pm

I am sure you have heard about Search Engine Optimization, commonly referred to by its abbreviation of SEO. If not, which planet have you been living on? Welcome back to Earth! SEO efforts in companies are often handled by someone who knows more or is very interested in SEO (smaller companies) or an in-house expert or with the help of a consultant (in mid-size to large companies).

But given that we live in the times of social media and where findability of products is predominantly done via online searches, software product managers need to have basic understanding of SEO. It does not matter whether your company sells a dog-grooming product or document security to senior citizens, you as a software product manager must have a basic knowledge of SEO.

But why? Why should you as a software product manager care about SEO? Here is why. You have likely worked very hard in leading your development team to create a product for which you have determined there is a lot of market demand. We know that people are searching for stuff online all the time – doing research on possible solutions, understanding how to buy, what to look out for, reading reviews on products etc. So if your company is not doing SEO, your prospects are very unlikely to find about your product(s) online. And if they don’t, how is your sales team going to meet your product’s sales goals? If you as a product manager are responsible for your product’s business, then you should drive your company’s efforts to make sure your products are found online. This does not mean you do it yourself, but you make sure your marketing department gets it done either internally or by hiring an SEO consultant.

In my opinion, being clueless about SEO as a software product manager is not acceptable anymore. While I am not an SEO expert, here are 7 things that in my opinion all software product managers must know about Search Engine Optimization. My objective here is to give you a basic understanding of SEO such that you can learn more about via numerous resources available on the web.

For the purpose of this blog post, assume that you work for a fictitious company Shenoy Shoes that sells women’s shoes.

1) Keywords – SEO starts with keywords. Think of keywords as terms that users are searching for via the Search engines. You need to find keywords that are highly relevant to your products or business and then decide to optimize your website for that keyword. The strength of a keyword can be expressed as

Keyword strength = function (number of monthly searches for the keyword, competition for the keyword and relevancy of the keyword to your business)

So how do you select keywords? I use Google Keywords tool whenever I am looking to select keywords – whether it is for this blog or for websites I have been involved in.

Be very selective on which keywords you choose – the rule of thumb is not to select the keywords which have the highest search volume because this would also mean that the competition for those keywords is also very high. Instead, find your own niche by selecting keywords with decent volume, decent competition and highly relevant to your business. Selecting very basic keywords such as “tools”, “security”, “cars”, “shoes” “pants” etc. is usually not a good idea – they are too generic and are going to be highly competitive.

For example, for Shenoy Shoes trying to target the keyword of “women’s shoes” (monthly search volume is 45 million+) may not be a good idea given how highly competitive the keyword is. Instead if you optimize your pages for less competitive keywords (provided you carry these products) such as “suede women’s shoes” (monthly search volume is ~300,000) or “women’s boot shoes” (monthly search volume is ~246,000), you may be able to get the SEO efforts for your new website going.

Once customers find your website using these niche keywords, there are things (merchandising, promotions etc.) that you can do to get these customers interested in other shoes you sell. The most difficult step is to getting them to your website when they are searching for stuff you sell.

2) Creating content based on keywords – Once you have selected the keywords you want to target, create content based on these keywords – content that is optimized for these keywords such that Google indexes your pages and dishes out your pages first when someone searches for these keywords.

Bear in mind, SEO efforts do not bear fruit overnight. It can typically take anywhere from 4-6 weeks before you start seeing results. SEO is not easy and is not scientific as far as I know. You need to keep at it and continue to create content that people want to consume. If you are selling B2B products, the idea is to establish yourself as a subject matter expert on the keywords you have selected that people start trusting you. It is all about building relationships first before you offer to sell them what you have.

For example, there are ~246,000 monthly searches for the keyword of “women’s shoes size” and the competition is not that high. This looks to be a good keyword for Shenoy Shoes to build content around. You could write articles on how to choose right shoe size for women, size conversion between different countries, things to watch out for when selecting shoes between different shoe types (boots, suede, walking shoes etc.) – content that will educate your target customers on to how size their shoes. Once they find this page and understand that your company is a subject matter expert on women’s shoes, they are bound to listen to your recommendations when it comes time to buy.

3) Landing Pages – Landing page is simply a page that a website visitor lands on when he clicks a link in the search results or clicking on one of your ads or a link in your marketing campaign. Landing pages are great because you can have as many of them as you want, with each of them optimized for a specific keyword. Think of every landing page as an opportunity to optimize for a keyword. More landing pages you have, more opportunity you have to optimize for specific keywords. 100 landing pages are always better than 10 because you have an opportunity to optimize for 100 keywords.

For example, assume that Shenoy Shoes sells branded shoes such as Birkenstock, Clarks, Converse, Dansko, Ecco etc. Looking at Google keywords tool, we notice that the monthly searches for women’s shoes of these brands are as follows:

Birkenstock women’s shoes – ~33,000
Clarks women’s shoes – ~90,000
Converse women’s shoes – ~90,000
Dansko women’s shoes – ~33,000
Ecco women’s shoes – ~27,000

To get found when users search for each of these shoes, you want to create five landing pages, one for each of the above brands and where each page shows all the shoes of that particular brand. The landing page content should then be optimized for the keyword selected for that page. For example, the Clarks shoes landing page will be optimized for the keywords of “Clarks women’s shoes”.

Warning - NEVER EVER create landing pages that are optimized for stuff you do not carry. For example, if you optimize a landing page for Clarks women’s shoes and you get ranked, a user who clicks on that page link expects to find Clarks women’s shoes, period. So if you don’t carry these shoes and use the landing page only as a lure to get users to a page where you can show them the wares you actually sell, you are doing it wrong. Your visitors will be pissed and will walk away. Remember that on the web, it only takes one click to go to your competitor’s site. Hence always be honest and always establish trust and relationships first. Play only if you can help your target customers make right decisions and eventually purchase from you. Think long term and not just that first sale.

4) Title tags – A title tag is the title text that will appear in the header of the window when a page loads. Search engines pay a lot of attention to title tags. The title tag is also what search engines use as hyperlinks in search results – results users will click on. So it is extremely important that you define a title tag for each page you have on your website. It still appalls me that some well known companies even to this day use the same title tag for every page on their website.

For example, a title tag of “FAQ” for Shenoy Shoes FAQ page is essentially useless in my opinion from an SEO point of view. Instead, if the title tag said something like “FAQ – Women’s Shoes – Shenoy Shoes” it is more meaningful because it provides context. Otherwise, you are ignoring one of the precious SEO elements that has such a high impact on SEO ranking.

I would also advise against using just your company name as your title tag unless your company name is a household name among your customers or prospects and that they would be searching for your company name (I would doubt it).

For Shenoy shoes, the title tag for the home page could be something like

Women’s walking shoes – Shenoy Shoes

Women’s shoes online – Shenoy Shoes

This is likely to give you much better SEO results than “Shenoy Shoes” or something very generic as “Home Page”. Believe me when I see websites using such generic title tags as Home page or Home, I know that the company is missing out big time by not doing SEO.

5) H1 Tags – In HTML, headers of pages or paragraphs are coded using <h1> through <h6> tags. Of these tags, <h1> is the tag of the largest font size. Google thinks that if you’re using a <h1> tag, then the text between the <h1> tags must be more important in relevance to the content on the page than anything else on the page. Hence, <h1> tags have very significant value from an SEO perspective. It is important that you take advantage of this on every page

For example, the Clarks women’s shoes landing page should have the <h1> tag of “Clarks women’s shoes – Shenoy Shoes”.

6) Meaningful URLs
Another SEO element that Google pays a lot of attention to is the page URL. Keywords that occur in the URL are considered relevant to the search being performed.

For example, the page that lists all of the Clarks women’s shoes it carries should not have a url that reads something like

http://www.shenoyshoes.com/10/70/77.html

Instead a better URL would be

http://www.shenoyshoes.com/clarks-womens-shoes.html

In SEO jargon, this is often referred to as URL rewrite.

7) Measure, Iterate, Measure again – Now that you have done the above basic SEO sites and launched your new pages/website. Are you done? No, absolutely not. SEO is a chess game. You are competing with everyone else, especially your competitors.

Your company needs to periodically measure whether your site is getting found by users and how. Many web analytics tool including the free Google Analytics tool can help you understand as to how many users are finding you while searching for the keywords you have selected. If not, you will have to make adjustments along the way. You may even have to choose different keywords if the initial ones do not get you results you intended to get.

So it is all about measuring, making adjustments and then continuously measuring the results again. Even if you get the results you wanted at your first attempt, it does mean you are all set. Remember that your competitors are also competing for the keywords you have targeted. They are going to be making changes along the way and trying to beat you to the top ranking on Google. So there is nothing called resting on your laurels.

I hope the above has helped you in understanding the basics of SEO. Believe me, this is just a start. Like everything else, there is a lot more to SEO than what is listed here – linking, anchor text, site maps, images vs. text etc. Here are some valuable resources I would suggest you read to get more knowledgeable.

Search Engine Optimization Starter Guide from Google

SEO Fast Start by Dan Thies

Internet Marketing Blog by Hubspot – this is a lot more than SEO and all about Inbound Marketing – I am sold that this is where marketing is going.

Your thoughts? How well is your company doing SEO? Do you know of any other good tips or resources for SEO and internet marketing in general? Please share via comments.

Image: Courtesy of Flashdaweb

If you enjoyed this post, please consider leaving a comment or subscribing to the feed to receive future articles delivered to your feed reader.

December 7, 2009

What is good enough? “Lame Duck” vs. Phased Releases

Filed under: business, product management, product usability — gopalshenoy @ 12:01 am

As a software product manager, you are more than likely called to make the decision whether a product/service is ready for prime time.  Often it is a challenge because there is a lot of pressure from internal stakeholders to release it.

There is a fine line between what I call a “lame duck” product/feature and phased release of a product or a feature. Lame duck is a product/feature that is dead on arrival. When customers try to use it, they either cannot figure it out (usability issues), find it to be so slow (performance issue) or basically find it useless (functionality issue). Phased release on the other hand is where a very large piece of functionality is broken down into logical units and delivered in a series of  releases. The latter approach makes a lot of sense because each of these logical or atomic units are still usable by the customer to get their job done. The additive nature of the logical units also usually makes sense to the customer because it lets them start using the new functionality in a gradual fashion and eventually end up automating/changing their entire process over a series of releases.

Unfortunately, “lame duck” product releases are very common. I have heard the excuse of “If we build it they will come” or the reasoning of “Let us release it and customers will shape it for us.” – all of this will hold true ONLY if you have build something that is complete and useful for the target customers. Customers usually have a low tolerance for products especially when they have choices and will only put with something when they absolutely don’t have any. The latter is very rare if you ask anyone other than software vendors. This is even more true with new products especially websites targeted towards consumers. Customers will not give you the second chance if they visit your website, don’t see what they wanted and leave. First impression matters. It does not matter how much effort you put in the second round to make things better and complete, it is a lot harder to convince your prospects/customers to come back and try it for the second time.

I am not preaching “perfection” here by any means – I am a strong believer in “perfect is the enemy of the good”. But I continue to be appalled when companies release products into the marketplace as “lame ducks” and wonder why they are not successful. One of the common places where you can find such products is when a company takes an enterprise product, turns off a few features and releases it as a small business version. This assumes that small businesses don’t have the same needs as the enterprises – not always true.

To clarify further what I define as “lame ducks” vs. “phased releases”, let us consider some examples purely for illustrative purposes.

Lame ducks
1) Photo community website launches with a bunch of photos, but there is no ability for community members to contribute photos. Result, community cannot contribute content and the content becomes stale very fast.
2) Tables functionality inside word processor – can create tables, but cannot add/delete rows or columns after the table is created – have to delete and start over.

Phased releases
1) Photo community website launches with awesome functionality to view, share and upload photos. The experience is outstanding, the community spreads the word and the site takes off. The creators extend the site to support videos within 3 months of launch.
2) Tables functionality inside word processor – all of the basic functionality is included. However, you cannot create rich text inside tables (different fonts, font size, font treatment like bold, underline, italic etc.) is not supported in Release 1. Rich text functionality is released in release 2.

As a software product manager, the best way to avoid having to make a decision to ship or not to ship is to prepare for this during the product planning session than waiting till the tail end. Plan for this, because it is bound to happen. During product planning, make it crystal clear as to what you think is the minimum set of functionality that is needed to release the product into the market. Once agreed upon, all stake holders should be aware that this minimum functionality is not up for negotiation no matter what issues are uncovered during the product development process. The solution could change based on how the product development proceeds, but the functionality set cannot. You should plan on building support for this approach with your executive stakeholders upfront so that you do not have to face the death squad when you vote “No” to prevent the product from shipping.

Have you experienced such a situation? How have you made the right decision? Please share your thoughts.

If you enjoyed this post, please leave a comment or subscribe to the feed to receive future articles delivered to your feed reader.

Image: Courtesy of hwupdate.org

November 29, 2009

3 ways software product managers can work effectively with development teams

Filed under: agile, business, customer needs, product management, team communication — gopalshenoy @ 10:20 pm

As a software product manager, I spend a lot of time working with my development team in making sure that they are well aware of the customer pain points and the requirements of the solution we are trying to build. I have heard from time to time from my colleagues and also from software product managers in the community as to how development team does whatever they want without paying too much attention to the market requirements. While it is true that development does embark on some “skunk-work” or their “sandbox” projects, I have been lucky enough to have my product development teams more in tune with the market research my product management teams have done.

Here are some tips on how you can make sure your development team stays tuned in to the market needs and builds very simple, easy to use products that will delight your customers.Software product manager

1) Involve the development team early – One of the common complaints I have heard from my developer friends is how their product managers do not get them the actionable information they need about customer needs. Go figure! We as software product managers think that development teams want to do whatever they want and the developers are complaining that we are not getting them the information they need. Guess how developers find solace? They start writing code. When they have written enough code to solve the customer problem they perceived to be right, you as a software product manager stepping in with market information is of no use. Here is one of my common mantras to anyone who cares to listen – “Developer resistance to a software product manager is directly proportional to the number of lines of code written.” More code they have written, less chance you have to influence them and get anything changed. And guess what ships – what was written.

So how can you mitigate this problem? Involve the development team early. Trust me there is no time called “too early” to involve your development team. Involve them even when things are fuzzy so that they can start asking you all the questions to which you have to find answers. Make it a collaborative process. Set expectations that you do not have all the answers yet. This puts their skin in the game – it builds a sense of ownership. Product ownership can do wonders. Before you realize, everyone is rowing in the same direction and everyone wants to win by building the right thing. I am yet to meet a developer who wants to create a product that will fail. Yes, there are developers who want to build the pie in the sky solution that only they will use, but you are bound to find such people in every profession including product management. There is nothing you can do to prevent the occasional “skunk work” or “sandbox” projects – but if this is the norm at the place you work, it can only be one of two things – you are not doing your job as a software product manager or you are working for the wrong company. This is because with such state of affairs, market failure can only be a corner away.

2) Be a good strategist, but more importantly be an excellent tactician – Set a good product strategy that will help your company achieve business success. But make sure you remain involved in the execution of your development process. You as a software product manager need to know exactly where the development team stands on your product on a daily basis. You need to know of every bottleneck or hurdle faced by your development team and your job should be to find a way to resolve these issues. This in my perspective is one of the greatest reasons why Agile product development methodology is so successful – every team member is on the same page every day and there are no unpleasant surprises.

Being involved at the execution level will help you build a great rapport with your development team – it has for me. It sends the message that you care about the success of the product and that you are in the trenches with the development team.

3) Be the team’s cheer leader - Being a developer is not a fun job – it is a very stressful job. I won’t be able to do it. Every product development cycle has its ups and downs. Be the cheer leader for your team during these ups and downs. This may mean that you get your team the beer of the week from the nearest micro brewery or you take them out for lunch or dinner once a quarter. Always keep the human perspective – it is not all about work.

Take every opportunity to make sure you stand up for your development team. If your executive management team wants you to give them a briefing on the progress of the development effort, team up with your development lead to do the briefing. If you are going on a customer visit or going to be on a conference call with your customers, invite your development team to accompany you or listen in if appropriate. More you bring them up to speed on the customer’s needs, less battles you have to fight on the problems the product has to solve.

Don’t try to hog the limelight – it is not all about you. It is all about the team. After all your customer really does not care who is getting the internal limelight or who came up with the solution. The only yardstick for the customer is if your company can solve his painpoint with a very elegant solution.

Thoughts? What are your key learnings on how best to work with your development teams?

If you enjoyed this post, please consider leaving a comment or subscribing to the feed to receive future articles delivered to your feed reader.

Image: Courtesy of Bealonghorn.utexas.edu

November 19, 2009

6 “bootstrapping” tools for software product manager

Filed under: business, product management — gopalshenoy @ 8:41 am

You are a software product manager trying to start a software company on your own. Or you work for a startup or a small software company and don’t have much money to spend. But you still need to design a good user experience, do early usability testing with your prospects, do a quick show and tell of your ideas to your management, your customers or potential investors. Here are 6 “bootstrapping” tools that I have used a whole lot to communicate and collaborate without denting my wallet too much.

1) SnagIt – When doing wireframes or mockups, you want to steal UI ideas from different websites you see – you want something quick and dirty to show your product development team or your customers to get some early feedback. SnagIt is one heck of a tool that comes to the rescue. It is super easy to use and helps you capture images from your screen and edit it quickly. Cost: $50

2) Balsamiq – An outstanding, super easy to use tool for creating early wireframes. I am a very visual thinker and need to draw when trying to communicate user experience ideas. This is the best tool I have used to quickly create some quick and dirty wireframes. The wireframes look hand-drawn so your management team or your customers do not think you have it all coded and ready to ship. The palette that is available is exhaustive including the very nice interface elements for developing wireframes of iPhone apps. Cost: $79

3) Google docs – Need to write functional specs? How about revenue modeling or what if product pricing analysis? Google docs works very well. Its collaborative ability where users can markup documents and can compare the different revisions is good enough. You will not find everything Microsoft Office has, but it has a lot of the things that you commonly use (except Pivot tables – can do via Gadgets, but painful to use). But then beggars cannot be choosers. If you don’t have money to pay for the expensive MS office ($149.95 for Home edition per user) and need most of the features that one commonly uses, Google docs does the trick. Plus it is all online and everyone is working off one copy of the document. Nice! I personally have not used the presentation functionality and hence cannot comment how useful it is. Cost: $0

4) Goto Meeting – So you have created the mockups and want to do some quick usability tests with your customers and prospects and none of them are local. You want to do web conferencing for free? Goto Meeting is my favorite tool. So easy to use and works like a charm everytime. In the hundreds of times I have used it, there were only 2 instances where the customer could not use it because of firewall issues on their end. Though it is a little expensive to use, it is something where I would spend the money so that you can easily collaborate via web conferencing. Cost: $49/month or $468/year

5) Skype – Do I need to say anything about this popular FREE tool? I use Skype in conjunction with Goto Meeting so that I get free phone calls. The only thing you need to make sure is that the folks at the other end also have a Skype account. You can get your team members to create an account, but with customers or prospects you may have to use Goto Meeting’s audio. Cost: $0

6) Gmail – Again, want free email without having to shell out money for MS Outlook? Cost: $0

Overall, total fixed cost = $129, recurring cost = $49/month for GotoMeeting.

I am sure there are many more tools out there that one can use. What do other software product managers use? Please let me know.

If you enjoyed this post, please consider leaving a comment or subscribing to the feed to receive future articles delivered to your feed reader.

Image: Courtesy of GuyKawasaki.com

November 8, 2009

Customer Visit: 2 creative ways to get a budget

Filed under: business, customer visits, leadership, marketing, product management, voice of the customer — gopalshenoy @ 11:06 pm

Times are tough, budgets are being cut, there is a travel ban in companies, so as a product manager, how do you get a travel budget so that you can get out of your office for on-site customer visits? It is hard, but here are two creative ways you can make it work.Getting budget for customer visit

1) Think local - It is one thing to walk into your boss’s office and try to convince him/her that you have to fly to Hawaii to do an on-site customer visit. More eyebrows will be raised out of suspicion of your desires, no matter how relevant your product is to the Aloha market. It is a totally different and easy sell, if you want to ask permission from your boss to visit your local customers. Do you have customers within a 75-mile radius of your office that you could visit. If yes, what are you waiting for? If not, do you have any within a 200 mile radius that you could drive to? Yes, it could take 3-4 hours to drive to get there, but by announcing that you are a creative boot-strapper and that you are willing to even drive 3 hours to better understand customer needs, your management will very likely appreciate your initiative. Day-trips are cheap because there are no hotel stays, no expensive dinners or flights involved. Even in companies where travel budgets are tight, I am sure there is still a few hundred dollars to support a product manager’s day trip to a customer site. And if there isn’t, then your company probably does not believe in building products that are in-tune with customer needs or might be in deeper financial trouble than you think and you should start looking for a new job.

2) Piggyback - Are you scheduled to travel for any trade shows? In which case, most of your travel expense is already a sunk cost. Do you have any customers at or near the place where the tradeshow is going to be held? If yes, extend your stay for a day or two and visit those customers. The incremental cost to do this will not be much and approvals are easier to get. Piggyback on that planned trip to do customer visits. Are you going to go on a personal vacation, traveling for a wedding? Is it possible for you to extend your stay for a couple of days and mix in some business as part of your trip? If yes, ask the company to pick up the tab for your extended stay. Get creative and make sure your management knows that you are going over and beyond what is expected of you, to make sure that the products you build are in-tune with customer needs. It is such employees who will be valued the most when push comes to shove.

Does this make sense? How have you managed to do a customer visit during the tough economic times?

If you enjoyed this post, please consider leaving a comment or subscribing to the feed to receive future articles delivered to your feed reader.

Image: Courtesy of piperreport.com

November 3, 2009

What is product simplicity?

Filed under: business, customer experience, product management, product usability — gopalshenoy @ 8:39 am

The KISS principle – Keep it simple stupid – something all of us as software product managers have heard one time or another. But when it comes to products, what exactly is prproductcomplexityoduct simplicity? Product usability and simplicity typically falls into three different categories, in my perspective. This perspective is based on my 13 year experience as a software product manager building products for the mass market – small businesses in particular. Enterprise products may be a different ball game and hence your mileage may vary.

1) Less is more – Don’t overload your product with all the features your users may ever want. Instead focus on those features that 80% of your customers would need. Yes, this will mean telling the remaining 20% one of two things – this product is not for you (sales – yes, be honest with the customer) or get used to the feature set we have because here are the benefits. In the latter case, here are couple of examples that come to mind: Apple iPod comes to mind. I would love to delete songs directly from my iPod, but I cannot. I need to go to iTunes for that. I can choose to complain that Apple was wrong, but given the huge other benefits offered by the iTunes-iPod integration, I get used to it not being there. Apple drew the line in the sand and said No.

One of the common pitfalls companies fall into is full product configurability. Full configurability is not necessary. What it does is create a slew of options, intimidates users and on top of it creates a maintenance and testing nightmare. Majority of the users tend to use products in the default configuration. How often have you gone to the preferences or options dialog to configure something, especially when you are a brand new user? Provide basic configurations and then let the customers guide you with the other configuration options they would need. Again, stick to the 80% rule.

This is hard to do because the 20% of those customers who need all of the complicated features could be your largest customers, the most vociferous ones. But as a software product manager, you should own your product direction and learn to say No to those requests which will take your product in a direction you don’t want to go. I do not mean be arrogant, but reason with the customer as to why you don’t want to do it – in the past, I have been very honest with the customers as to how the general user base would not need the functionality being requested and they have backed down. The trick here is that your product should have such a high value proposition that these things end up to be gravy in the whole scheme of things. And if the features requests (which fail the 80% test) are the meat and potatoes for these customers. then your product after all may not be the right fit for them. Be honest with such customers and recommend the products they should look at – this may even be your competitor’s products. Don’t miss out on building the relationship, you would never know when it will come handy – for all you know they may find the competitor’s product complex/expensive and may dproduct simplicityecide to buy your product instead.

2) Your product behaves the way users expect it to – In this case, it is not about less features. Often, users expect the product to have the functionality to get their job done. To facilitate this, your product could end up being feature rich. But there is a difference – there are many products that are feature rich but not very user friendly. Then there are other products that are equally feature rich, but much easier to use. Personally, I was involved in one such product called SolidWorks which made its mark because of its production readiness and because of its ability to run on Windows with the same ease of use as Office applications at 1/5th the price of PTC’s product called Pro/ENGINEER. Pro/ENGINEER was powerful, super complex to use, ran on Unix workstations and costs tens of thousands of dollars at that time.

The trick here is to minimize the deviation between how the user expects to complete a particular task and how the software allows the user to do the task. Larger the deviation, lower the usability of the product. This is because users will have to learn new ways to do tasks that they think should be very easy to do. Usability testing is key to ensure that there is minimal deviation between the user expectation and actual difficulty in completing a particular task.

3) Your product is a game changer – Your product comes up with a very innovative way to do things the users could never imagine possible with the current systems he uses. Two products that are classic examples are 1) Bose products and 2) Shazam, the nice little iPhone app.

waveradio-shazamWhether it is Bose’s Wave radio or the acoustic noise reducing headphones or the iPod sounddock they sell, their products are game changers. They have hidden all the dials/controls that the user had to muddle with to listen to music and  made it dead simple – no dials, no controls, it just works. This to me is a game changer. Shazam is equally simple. It listens to the music that is being played, analyzes it and identifies the song – number of clicks needed – ONE to start the process. It even integrates with iTunes to download the song. To top it all, it is FREE. Can it get any better than that?

You can do this, it takes effort. When it comes to software, this is easier to do (or at least I think it is because all I have done is software in my career). One technique I have used successfully is to write down each and every step that is currently involved in completing a task and see how many of these can be automated or compressed into less number of tasks. You will be surprised in what you find. But when doing this, you will come across the naysayers who ask you – “What if the user wants to do this, what if they want to do that?”. The best way to counter is by making sure you know what the 80% of your users will need and then stick to the principle of Less is more.

Thoughts? What have you as a software product manager experienced when it comes to product simplicity?

If you enjoyed this post, please consider leaving a comment or subscribing to the feed to receive future articles delivered to your feed reader.

Images: Courtesy of gizmodo.com, bose.com, shazam.com

October 26, 2009

Death by a thousand paper cuts ….

Filed under: customer experience, customer visits, product management, product usability — gopalshenoy @ 10:48 pm
Tags: , , ,

In my last post, I discussed the benefits of doing an on-site customer visit where you get to observe customers/prospects use your product or competitive products to get their job done. In my experience doing these visits, I often discover what I call “death by a thousand paper cuts” issues. These issues are essentially annoyances that your users have to put up with when using your product. By itself, each of these issues will sound trivial. If your users call you up to complain about any one of these issues or to propose a solution, you could easily laugh it off as trivial.

But when you are on-site observing these customers, you will notice that these trivial issues quickly add up to cause significant loss of productivity for your users, especially when your users have to encounter them each and every time they use your product. But these to me are the slam dunk features – they are so trivial and hence are usually very easy to fix, but when you fix them you will be able to significantly improve the user experience. Your customers will notice these small improvements because they will reap significant benefits especially if these issues were in the way of a frequently performed task.

I have had many instances where such simple fixes have generated the loudest applause from the audience where as the big feature we were so proud of was met with very muted applause (to our chagrin, if I may add). Have you experienced something similar?

Thoughts?

If you enjoyed this post, please consider leaving a comment or subscribing to the feed to receive future articles delivered to your feed reader.

October 7, 2009

Five reasons why customer visits “rock”

Filed under: business, customer interviews, customer visits, marketing, product management, product usability, voice of the customer — gopalshenoy @ 6:15 pm
Tags: , , , ,

I am a big fan of customer visits – ones where a software product manager visits customers on-site and observes them using your or competitor’s product. Now why do this? What are the benefits of doing this over talking to the same customer/prospect over the phone, while at a conference/trade show or doing a survey etc. Here are the 5 reasons why I find a customer visit trumps other market requirements gathering techniques:

1) Customers misstate their pain points: Yes, they do. But not because they want to mislead you. But because what customers tell you is often very different from what they do. For example, let us say you are on the phone and ask them to walk you through the different steps they do to complete a particular task. They will tell you what they can remember. When they articulate these steps they usually tend to remember the ideal way they do things or the way they are supposed to do things. But this is often not the way they end up doing things. There are always quirks, there are often painful detours which you will never get to know. These painful detours could be a gold mine for usability issues to solve such that the customer’s life becomes a lot easier when using your product. customervisit

2) They don’t want to look stupid: Usually customer phone calls have multiple representatives from the customer side and often folks with varying responsibilities and varying levels of expertise of your product. It is difficult for someone who is not as good as using your product admit that it is very difficult to do something. Here is a typical scenario:

Bill (a new user who is struggling with or learning your  product):  “You know I wish your product was easier to use when it comes to  doing <insert one of your product features here>. I use this every day and every time I use it, I either lose data or the performance is very slow.”

John (Mr. Power User who is also on the call):  “Oh Bill, that can be easily done. It is because you don’t know about feature X. I will show you how to do it after this call.”

Do you think Bill is going to tell you any more of his pain points? He shuts up from there on and all you get to hear would be from the Mr. Power User, mostly things that are useful for the power users. Don’t get me wrong. Mr. Power User could be the most passionate visionary you want to tap into or could be the most opinionated, smooth talking person who pretends he knows it all. You have to be understand which of these two you are dealing with. The above scenario is difficult to do over the phone, but easier to do when you are meeting them in person (because you can choose to meet in private with Bill or ask him to show you how he uses your product).

3) Surveys: Good data gathering tool when you are ready to do quantitative evaluations, but only to augment the qualitative data gathering you have done via customer visits. Again when responding to survey questions, customers will answer on how they think they are doing something vs. how they really do it. Surveys typically do not capture the real pain points customers experience. The customer also tend to propose solutions when responding to survey questions as opposed to explaining the real problem that needs to be solved. Survey responses by their very nature are monologues and are not a conversation.

4) Customers do not know what they do not know: Humans quickly get used to doing things in one way that it becomes second nature. Once you get used to something or you are too close to the problem – you lose the objectivity. By observing customers in their native habitat, you are able to observe all the inefficient things that they do by second nature. By observing these things and by solving them, you would provide solutions to problems that the customer did not even know he had. You get respected for your ability to look out for the customer.

5) You get to see the customer’s “native” habitat: Where does the customer spend his time when he is working? A nice cushy air conditioned office? Or a dump that is next to the manufacturing floor where it is noisy and dusty as hell? How computer savvy are they? On one of my customer visits, I visited a customer for whom Ctrl-C and Ctrl-V were major revelations. And he has been using the computer for a long time. It is very easy for us when sitting in our offices to assume that our customers are computer savvy. What are your typical customers like? Ones that wear suits to work? Or ones that are in shorts and flip-flops?  How often do they get interrupted when trying to use your product? All of this will help you build up the customer persona you are designing for and also understand where your product fits in the customer’s working life. None of this is possible to do via customer phone calls, surveys or even while meeting customers in your offices or trade shows.

Thoughts?

September 24, 2009

How does a software product manager find usability testing participants?

Filed under: business, marketing, product management, product usability — gopalshenoy @ 11:56 am

In the last post, I talked about best practices for doing usability testing. But how does a software product manager go about finding participants for usability testing. Here are some tips:

1) Define your target user who will benefit from the product/feature you have developed. If it is an IT management software, is it the IT admin? Or is it the CIO who will be using your product? If it is an eCommerce site that sells shoes, do you want women who will buy shoes? Do you want to target frequent buyers or the infrequent buyers? Usabilitytesters

2) Find them – In the B2B software market that I have been involved in, I have typically recruited users who I know have the pain points that are being solved by this new widget. This information has come from our enhancements database, customers I have interviewed and have this problem or users who I know have this problem based on my domain knowledge. Image the excitement such users have when you call them up and say -”Hey, remember the enhancement request you had send in 6 months back? We are planning to implement a widget to solve that problem and wanted to know if you would have 45 minutes to take a look at an early version of that widget. Your feedback will help us make sure that the solution meets your needs and since it very early, we can also make changes to it based on your feedback.” And to make them special, I also add “We are doing this only with few selected customers. Would you have the time?”. 99% of the time I have had heard a Yes. You kill two birds with one stone – 1) send the message that you are responsive to your customer needs and 2) you value their feedback on the new widget before it is set in stone.

3) Paid or Free? - 90% of the time I have never paid my usability testers especially in the scenario I have described above where the new widget is a result of an enhancement request that has come from a customer. The customer is more than happy to be given a chance to be heard and also very curious to see the early version of this new widget. They realize their time investment will pay off. In other cases where I have to find new users who are not customers, I have paid anywhere from $75-100 per test. I typically try to see if the user raises the question of $, before I offer to pay (OK, call me a cheapskate, but I like to bootstrap as much as I can). But whether it is a paid user or a free, I make sure that the user leaves with some company goodies such as hats, mugs, pens, t-shirts etc. If they are a new user, I want them to remember my brand and I want them to advertise my brand. This does not apply if you are a brand new company in a stealth mode.

4) NDA needed? – Depends on how much you can trust the user. If the user is not a customer, absolutely Yes. If the user is a current customer, in majority of the cases I get them to sign an NDA especially if it is a new product or a killer idea that has competitive benefits. But, one NDA per user, please. Typically NDAs cover two-three years. But I trust the majority of the customers I pick. In case I don’t get them to sign an NDA, I make it very clear that this information is confidential. If the user has signed an NDA in the past, I make it a point to mention that what they are about to see is governed by the NDA they have previously signed. The best part is to check with your boss – does he want an NDA to be signed – this will make sure that you are following company policies and also that your manager knows about you showing future functionality to customers/prospects.

Thoughts? Do you have any tips you would like to share?

If you enjoyed this post, please consider leaving a comment or subscribing to the feed to receive future articles delivered to your feed reader.

Image: Courtesy of NUS School of Computing

September 22, 2009

10 Best practices for doing Software Usability testing

Filed under: business, marketing, product management, product usability — gopalshenoy @ 11:18 pm

I have been doing software usability testing for the past 10 years or so and here are 10 rules I go by every time I do a usability test. I have taken the liberty of calling it “best practices” only because these work for me really well. Take that as one man’s opinion if you want, since your mileage may vary depending on your product or service.usabilitytesting

Rule 1: Check your ego at the door before you sit down with your participants. The objective is to figure out if the software behaves the way “real users” expect it to. It is not a test of the users. And believe it or not, your software will NOT always behave your participants would expect it to behave. Do not get ticked off if the user slams your product or the new feature s/he is being asked to test – no one cares how much time you and/or your development team put in to build it, all that matters is if the user can do what s/he wants to do the way s/he expects to.

Rule 2: Make the user comfortable at the start of the test.  Why? Because it is difficult not to be nervous when you have someone watching over your shoulder while you are trying to figure out this half-baked, buggy new piece of software that you may have never used before. Chit chat, get the user some coffee or water. Do not dive right in.

Here is what I tell my participants before we start the software testing. “I want to make sure you understand that we are testing the software “usability” and not you the “user”. There is nothing and I mean NOTHING that you can do wrong in this test. If you don’t like something tell us and tell us why. If you like something tell us and tell us why. It is important for us to know both so that we don’t ruin what you like while trying to eliminate/fix what you don’t like. What we are trying to determine here is the deviation between how you expect to do certain tasks using our product and the way the product actually behaves. I would really appreciate if you could talk out loud what you are thinking while you are try doing the tasks you are about to do.”

Rule 3: Plan the test. Have a written down script for the tasks the user is supposed to do. Don’t change the script from one user to the other and importantly, stick to the script.

Rule 4: Forget about recording the audio/video of the test. Don’t listen to the usability pundits who tell you to do this. For the same reason, I have never spend a dime in renting professional usability testers or the facilities with the one way mirrors etc. Here are my reasons why I do not recommend any of this:

  1. It is expensive – read – $$$$$ and time consuming. I just cannot justify the extra return on investment compared to doing it myself.
  2. It is time consuming to set up and one more thing that can go wrong. I have tried using tools like Morae and even they introduce unnecessary complexities and modes of failure.
  3. I like to keep it very simple. And to me, nothing comes close than having a simple setup with my users. After all, it is my job as a product manager to make sure my product behaves the way the user expects it to.
  4. Getting the user not to be nervous without doing all of this is difficult in the first place. Their nervousness level goes up even higher if they find out that whatever they say or do is being recorded or they are being watched by folks behind a one-way mirror.
  5. No one is going to watch or listen to the recording – do you really think your product team has the time? – putting together the test is hard enough. I would rather spend time figuring out how to resolve the issues found.

So what do I use – the good old pen and paper. I take so many notes while the user is trying to do. Talking, writing and observing is hard to do all at the same time. So this helps you reduce the “talking” part. The main point of the testing is to observe.

Rule 5: Never ever take control of the mouse. Usability testing is not a demo of the brand new widget you have slogged on to create. So if the user cannot figure out, it is not good. After all, when the product ships, you are not going to be there to help the user figure it out. The objective is simple – “Can the user figure it out on his own and does it behave like s/he expects to. If not why not?” On the other hand, this does not mean that you have to leave the user to be lost, frustrated and feeling helpless if he cannot figure it out. Give it some time and if the user still cannot figure out, provide some hints to see if it helps. If it does not, note it down as a serious issue and ONLY THEN show the user how it is supposed to behave. But again, make sure you understand that you may have a serious usability issue.

Rule 6: Never do the usability test alone without announcing it to your product team. Announce it, inform them about the test schedule and make sure you get one person from your product team to help you during the testing. But keep it to one additional person – so that you don’t make the user nervous. My choice for that one person – the developer who worked on this new thing that you are testing. This extra person can help you take notes, can observe it from his perspective etc. Plus, it is one more person who is witness to the test such that later when you present your findings to the team, you do not have to deal with the “data you collected” being dismissed as “your opinion” or because of the incorrect testing method used. Trust me, this happens.

Rule 7: Make the test no longer than 45 minutes. If it is anything longer, you will see a significant drop in feedback from the user. It is very difficult to work while the user is nervous for more than 45 minutes.  How do you keep it this short? Keep the number of tasks the user has to do no more than 2 or 3 that can be easily completed in 20 minutes or so. This will take 45 minutes to complete during the test because of the Q&A and discussions.

Rule 8: Never make any changes to your product unless you have convergence from multiple tests. Don’t run to your development team after one test and ask them to make changes. Wait till you have more data points from more tests before you see a pattern of the issues that are tripping users up. How many tests do you need to do? I recommend at least 5 data points.

Rule 9: Analyze the data After all the tests are completed, read through your extensive notes and process it along with the colleague who observed the test with you. What did the users really like? (make sure your preserve this). What are the things you need to fix? What should be the action plan to resolve these issues. Do it right after all the tests are completed while it is all fresh in your mind.

Rule 10: Act upon the data, execute your action items. Make sure your stakeholders know about the results and what you learnt. Make sure that they know your product team participated in the effort and learnt a lot from it. It is not “your” show, but make sure they understand that it was a “we” show and the product team is on-board to make the changes. Then make the changes and repeat the tests if needed.

Note: I have had a lot of success doing usability testing using web conference tools such as GotoMeeting and have successfully applied these same rules.

Your thoughts from your experiences – are there any other best practices you have learnt along the way? Do you agree or disagree with the above? Please share via comments.

If you enjoyed this post, please consider leaving a comment or subscribing to the feedto receive future articles delivered to your feed reader.

Image: Courtesy of Cadfanatic.com

September 18, 2009

Lots of data, no actionable information

Filed under: business, leadership, marketing, product management — gopalshenoy @ 3:02 pm

I am big about making “data driven” decisions. I have written in the past as to how wiring your product can help you make data driven decisions. You cannot make the right decisions unless you know what is happening in the market, in your product. Data can be collected in a myriad of ways – listening to customers (one of my favorites – talk to real humans who use or will use your product/service), analyzing usage (web analytics, product usage metrics), win/loss analysis (again talking to humans to understand why they bought and why they did not), conversion analysis (who bailed out vs. who put money down etc.). mountainofdata

There are companies that don’t collect data. But there are a whole lot more companies that collect a lot of data. Unfortunately, they find that no one analyzes the data or the large volume of data is not what they need to help them make decisions. Just like how one says that a wrong decision is sometimes better than indecision, to me having no data is better than a ton of worthless data. At least you are not going to spend time analyzing the worthless data and draw wrong conclusions.

The sole purpose of data is to create “actionable” information that will allow you make decisions that will move the needle – increase in revenues, improved profitability, faster performance, higher customer satisfaction or whatever business metric you care about. But what I find is that many companies collect a lot of data, but none of it is actionable. It is almost like someone said “we need data” and someone ran and collected whatever he could.

So next time you or someone you know is going to start a data collection exercise – here is what I suggest – pause, take a deep breath and ask yourselves three simple questions:

  1. Why do I need this data – meaning what decision am I looking to make?
  2. What is the right question I should ask that will get me the “actionable” information? Make sure you phrase the question right.
  3. How many people do I need to collect it from before I can call it trustworthy?

Make sure you have solid answers to questions 1) and 2) and if you don’t, drop the data collection project. Yours truly is also guilty of this rush to go and collect data. Surveys especially are not easy to do – hence put in the right amount of time to make sure you ask only the needed questions (and phrase them right!) to get the right information to make the right decision.

If you enjoyed this post, please consider leaving a comment or subscribing to the feed to receive future articles delivered to your feed reader.

September 14, 2009

Software Product Manager’s tip on Optimism vs. Reality

Filed under: business, leadership, marketing — gopalshenoy @ 5:37 pm

As a software product manager, we have to be cheer leaders for our team. We have to make sure our sales team, marketers, developers, the QA team are all staying pumped up about the products that we have asked them to sell/market/develop/test. But optimism that is not well grounded in reality is bound to backfire.

How many times have you met an optimistic sales person? They are always optimistic about meeting their sales quota – “Oh, I will make my $100K!” – when they very well know that the average deal size is $10K and there are only 3 potential deals cooking in the pipeline. How many times have you heard developers being very optimistic of shipping on time even though they are currently two weeks late and the original ship date is only a week away? It is also common for many of us to overpromise on what we can do for others, just because we hate to say No to someone.

To me, such optimism is very common but when reality strikes, such optimism does nothing but burn trust. Be optimistic about future success, but make sure it is grounded in reality. There are only 24 hours in a day and you are not inventing time to make the impossible come true, just because you are optimistic.

Trust once lost is hard to gain. Push yourselves to do more, but don’t set yourselves up for a definite failure. Under promising and over delivering is always a good option!

September 9, 2009

How many customers does a software product manager need to visit/interview?

Filed under: business — gopalshenoy @ 8:30 am

As software product managers, we are chartered to unearth painpoints by interviewing customers/prospects. But how many do we have to talk to before we feel comfortable that we have talked to enough? How many is too many?

I have always used the following guidelines which I picked up from the great book “Customer Visits” by Edward McQuarrie (If you have not read this book, I highly recommend it. I consider it the bible on how to do effective customer visits). His research shows that interviews of

  • 30 customers in the right market segment will identify 90% of the needs
  • 20 would probably identify 80-85% of the needs
  • 12 will identify 70-75% of the needs.

I typically start with 5-10 customers and see if I am already seeing convergence and then decide if I need to probe any specific areas even more by talking to more people. Make sure that you have randomly selected these customers from the target market segment and that you are not talking to same 5-10 everytime you need to do customer visits.

If you enjoyed this post, please consider leaving a comment or subscribing to the feed to receive future articles delivered to your feed reader.

September 8, 2009

User communities – The 100-10-1 rule

Filed under: business, marketing, product management, social media — gopalshenoy @ 2:40 am

Very often, when building user community sites or sites that will predominantly be driven by user generated content, the question that always gets asked is how many users do we need to attract to ensure that there is a steady stream of new content that is generated on the site. In the book, Citizen Marketers, Ben McConnell and Jackie Huba talk about a very easy to remember 1% guiding principle. The 1% rule says that

  • 1% of the visitors to a website will create new content or contribute content.
  • 10% of the visitors will interact with the content by writing comments or say rating the content.
  • The remaining (a very large majority by the way) will merely read the content

They have validated this 1% estimate (give or take a few percentage points) using leading websites such as Wikipedia, TiVo Community Forum, Microsoft’s Channel 9 website, Yahoo Groups, Quickbooks community etc.

I have found this to be very true in the user community websites I have created, beta programs I have run. This rule which I find appropriate to refer to as the 100-10-1 rule serves as a great guideline to determine how much traffic you need to generate to your website such that it is self sustaining in terms of content generation. If you need say 10 new articles a day from 10 different contributors to keep your website going, then you need to make sure that at least 1000 users visit your site everyday.

It also helps you understand how user communities behave such that you do not set unachievable targets such as “1 in 5 users (20%) who visit my website will contribute content.” – it is very likely not going to happen.

July 29, 2009

Agile Product Owner – New Name, Same Old Problem

Filed under: agile, business, leadership, marketing, product management — gopalshenoy @ 9:16 pm
Tags: , ,

This is a guest blog post by John Mansour, Founder and Managing Partner of ZIGZAG Marketing

In the world of agile software development, the confusion over product owner versus product manager is hardly new. This problem has existed as long as software and product managers have been around. It merely has a new name.

First, let’s cover the basics. There are two key roles in the software product delivery continuum that must precede the first line of code being written, regardless of development methodology.

  1. The “what & why” role – responsible for determining “what” functionality should go into a product and “why” from a market and business perspective. The “what and why” role serves as the conduit for all inputs both internal and external. The end game of this role is to grow revenue by aligning product direction with market dynamics and customer needs. The “what & why” function is typically the responsibility of the product manager. Traditional or agile, it’s necessary regardless of who does it, their title or how it gets done.
  2. The “how” role – responsible for determining “how” product features should work to support the things users do. In its most basic form, this role is a surrogate user responsible for explaining in verbal, written and illustrated forms and in excruciating detail, what users do, how they do it and how software must work “functionally” to support the users. They spend most of their time with developers and they test functionality to make sure it works as designed, along with a host of other responsibilities. And yes, the best people for this role are former users or those who have worked intimately with a variety of users in multiple environments.

The “how” function is typically the responsibility of a functional product designer (for lack of a better title). For the fraction of software companies that have them they go by such titles as Business Analyst, SME (subject matter expert) and Technical Product Manager. In an agile environment they’re called Product Owners. Call them what you want, every company with high user interaction products needs them. They get much of the credit for things like iPhones and TiVo where the cool factor is the usability.

In my humble opinion, the confusion lies in two areas. First, software companies have been trying to combine responsibilities of the product manager and functional product designer for years and it’s a nightmare in every single case I’ve ever seen, and I’ve seen a lot. Plus it creates the same identity crisis as the product manager vs. the product owner in an agile world.

Regardless of development methodology, combining these roles is a recipe for failure because the skill sets and personality types required are distinctly different for each, not to mention the time commitment. When combined, the end result is either the right functionality with poor usability or highly usable features no one cares about. A dilemma on par with, “would you like to lose an arm or a leg today?”

The bottom line – your products will eventually fail. Second, “product owner” couldn’t possibly be a worse title, given the responsibilities of this role. Furthermore, product managers have always been affectionately referred to as product owners because they “own” the ultimate success of a product. Perhaps a dope-slap is in order for the person who coined the title “product owner.”

In summary, two distinct roles are necessary to feed requirements to software developers if you want usable products the market will buy, regardless of development methodology. The titles are less relevant as long as the responsibilities are clearly defined. For more on functional product designers read the article titled, Product Management & The Functional Designer – 3 Reasons it’s a “Must-Have” for Successful Products.

Next Page »

Blog at WordPress.com.