Is software product management needed in a startup?

Note: I had written this as a guest blog post last year on Subrata Majumdar’s blog called Confessions of a Digital Immigrant, that I am publishing here.

Is a software product manager needed during early stages of a startup? If yes, what should be his/her role,  given that everyone tends to wear multiple hats and the distinction between Product Management/Marketing and Architecture/Development is blurred. Is this a healthy cross-pollination or a disaster in the making?

I will offer my opinions on these questions drawing on my 13+ years of experience in the software industry and having played a role in the creation of successful products and utter failures.

1) Is a software product manager needed during early stages of a startup?

Yes, a software product manager is absolutely needed right from the early stages of a startup. A bunch of engineers can band together and write awesome software. But often, engineers fail to ask the fundamental questions – nothing against my development colleagues, they have enough to worry about to begin with.

1.    What problem does it solve?

2.    How many customers have the said problem?

3.    Are the customers willing to pay to solve the problem?

4.    Who is going to buy the darn thing and will they pay enough for us to be profitable?

5.    Does this solve the problem the way the customers expect it to work or do they have to change their ways?

It is a software product manager that will help a company to answer the above questions and make sure product development is aligned with customer problems. Only then will a company be able to create a business, sustain it and be successful.

Otherwise, you run into the infamous argument (I call it a trap) that I have heard over and over – if we build something, they will come. No – unless you have something they absolutely want at the price they want, they will NOT come. If the user experience does not save them time or money, they will keep solving the problem the old way because a) they do not have time to learn new ways and b) humans by nature are resistant to change.

There have been very successful products that created paradigm shifts, but more so because of the tremendous value and differentiation they offered the customers. For example, in mid 80’s, Pro/ENGINEER the 3D mechanical design software from PTC was the pioneer in creating this market segment by switching a lot of users from AutoCAD 2D design software to 3D. It was hard to use, it was expensive, it needed designers to completely switch their ways, but the design benefits were very obvious to those users that switched (and not to mention PTC’s very aggressive marketing and sales force). But paradigm shifts are rare. I am not suggesting that you do not innovate and create new ways to solve existing problems, but new ways should always have easily understood customer benefits. Otherwise, you will face adoption resistance.

You could also argue that one could launch a product and let the customer community take the role of helping you discover problems the product could solve. Yes and No. I would argue that it needs to solve one particular customer problem well enough to get noticed even by the early adopters. Unless you do this, no one is going to even consider buying/using your product. Unless this happens, no one is going to help you shape the future of the product to solve other problems it could potentially solve. I will draw an analogy – does anyone ever get out of the house and start driving hoping that you will end up somewhere nice by chance. Not very likely. But we are willing to take such a risk developing products, hoping that we will strike rich?

In this day and age of the internet and its free products, there are companies that have created free products that have sustained themselves for very long (Facebook and Twitter come to mind), but in the long run even these companies have to figure out ways to monetize their business to survive.

2) What should be a software product manager’s role in a startup given that everyone wears multiple hats and the distinction between Product Management/Marketing and Architecture/Development is blurred?

The roles of Product Management/Marketing are blurred primarily because the industry does not have consistent job descriptions for these roles. In some companies, Product Marketing does market sizing, segmentation, positioning and pricing decisions and Product Management figures out the customer problems in the selected segment and then works with engineering to make sure the right and usable product is being built. In other companies, all of this ends up with the software Product Manager and this is usually true during the early days of a startup.

But are there limits to what the product manager needs to do, such that he/she is not spread too thin? Yes, there are. I tend to use a very simple litmus test to determine activities in which a product manager must be involved – Does this activity help the product manager in listening to the market and making sure that the right and usable product is being built? If the answer is No, free up your time by getting it off your schedule.

I would especially shy away from getting involved in architectural and development related decisions for a very good reason. As a product manager, it is your role to think like a customer and then inform engineering what problems need to be solved and how. You can advise engineering in terms of customer expectations in terms of scalability and performance. But it should be engineering’s sole responsibility to figure out how to architect/design the product to solve the problems a product manager has identified. If you get involved in the latter, very quickly you are going to look at problems in terms of implementation details rather than from a customer’s perspective. Not a good idea.

Having said this, I will not hire a product manager if he/she is not ready to wear multiple (but relevant) hats even in a mature organization, leave alone a startup. Product manager’s role is one of the most cross-functional roles in an organization. Hence, by definition, such a role requires one to wear multiple hats, supporting sales, supporting marketing efforts, making sure the right product is being built by engineers and so on.

Thoughts? Comments? What have you learnt from your experience as to what works and what does not?

Products/features don’t ship with inventor’s name tag

All products ship with one label – your brand label – IBM, Microsoft Office, HP Pavilion, whatever your company’s brand name is. That is all what your customer gets to see. No product/feature ships with the name of the person who came up with the idea. So it “was my idea” or it was “Tom’s idea” actually does not matter in the scheme of things. So anytime spend worrying about who came up with the idea instead of collectively trying to make the idea better for the customer is wasted time. Your customer really does not care. There are only two outcomes – the product is a winner or it sucks. All of “us” are going to be considered a bunch of heroes or a bunch of idiots. Which would you rather be? So if we focus only on the opinion that matters, that of the customer, we should all come out ahead. But often this is easier said than done, isn’t it?. Unfortunately, we are human. But let us try darn hard reminding ourselves and our team members that products/features don’t ship with the inventor’s name tag!

Started my new gig at Gazelle

This week, I started my new job as Director of Product Management at Gazelle.com (aka Second Rotation Inc.) What do we do at Gazelle?

  1. We allow consumers to get cash for their used electronic gadgets such as cell phones, GPS, laptops, camcorders, MP3 players and even ebook readers.
  2. You can find out right on our site how much we will pay you and then if you accept our offer, we even pay for you to ship the item to us. If the item has no monetary value, we will even recycle it for you provided you send it along with some thing else that has a monetary value.
  3. We then find new homes for these acquired items to other consumers in the secondary electronics market.

We thus prevent these electronic gadgets from ending up in landfills. Want to know more and see if you can get cash for your gadgets? Check us out at www.gazelle.com – want to see how we all of this happens inside gazelle? – check out the nice slideshow on Gazelle put together by the Wall Street Journal.

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 column on the right.

4 lessons from Massachusetts Senatorial election

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.

Communications – RASCI approach

I am currently reading the book The 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.

Donations for Haiti earthquake victims

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.

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

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

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

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

SEO Basics for Software Product Managers

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) KeywordsSEO 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 keywordsOnce 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 PagesLanding 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 tagsA 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 shoesShenoy 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 againNow 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.

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

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

3 ways software product managers can work effectively with development teams

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

6 “bootstrapping” tools for software product manager

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

Customer Visit: 2 creative ways to get a budget

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

What is product simplicity?

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

Death by a thousand paper cuts ….

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.

Five reasons why customer visits “rock”

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?

How does a software product manager find usability testing participants?

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

10 Best practices for doing Software Usability testing

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 cross-functional product team. Announce it, inform them about the test schedule and make sure you get one person from your cross-functional 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

Lots of data, no actionable information

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.

Software Product Manager’s tip on Optimism vs. Reality

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!