Product Management Career Tip – Don’t be an “I” or “they” specialist

On Friday, I had to complete my self evaluation of my Q2 performance review. As I was reviewing myself, I noticed that I had to continously mention how “I” got this and that done. Too many “I’s” were making me uncomfortable that I had to pause and think about it, but was soon to realize that it was appropriate because this was my self evaluation – a self reflection on my performance/accomplishments/mistakes and not the group performance.

However, in the normal working life as a software product manager, there is typically no “I”, there is no “they”, it is always “We”. I get quite irritated when I meet such “I” specialists for whom everything is “I said this”, “I did this”. As a software product manager, there is very little that you can do which is not a group effort. Whether it is working with your development team, your marketing team or your finance team or your product management team, your accomplishments are primarily achieved by working with others. Hence, it is typically “We” did this or “We” should do this or “I” recommend that “we” do this.

Then there are the “they” specialists – folks who refer to their employers as “they”. For example, “I” recommended this, but “they” don’t want to do it. You are far better off pitching this as – “I” am recommending this because “we” can get to X,Y and Z. You come across as a true team player in your internal and external conversations. If you do this well and if you had a primary lead on some of these accomplishments, the right people should notice the leadership role you had to play. That recognition is far better than having to promote oneselves at every possible opportunity.

This is especially important when it comes to job interviews. You want to come across as a team player and “we” is the way to go. If all you do is become an “I” specialist or “they” specialist, it does not come across well. Of course, there are instances where you have to talk about what you have accomplished, but you will still be better off if you refer to some of these with a “We”. “They” when referring to an employer is best avoided.

Agree? Let me know.

Humans crave for predictability, are you providing it?

Last week, Gazelle moved its office from Allston to downtown Boston. No move is easy – new desk, new neighborhood, new commute, everything to get adapted to. My commute to the new office is now 1 hour 45 minutes each way. I have to drive to the train station for 20 minutes, take the train that takes an hour and then walk to the office. Sounds like an awful lot and it is – 15% of my day is now spend commuting. My previous commute was anywhere from 50 minutes to 1 hour 45 minutes. But I enjoy my new commute a whole lot more even though it takes a whole lot longer. For a very simple reason – predictability! I now know that as long as I get to the train station on time, my commute time is going to be 1 hour 45 minutes (barring any train breakdowns of course). Of this time, the 1 hour of the time on the train is actually spent relaxing – whether it is typing this blog post or taking a nap or reading. I enjoy the 10 minute walk from South Station to the office – free exercise. It is 2 hours that I get for myself everyday. Humans crave predictability and are likely to give up things for it.

The same applies for products. Some choose to

  1. Work in larger companies instead of startups because of the predictable hours and also job safety.
  2. Become full time employees than being consultants because of the predictable income.
  3. Buy products from established vendors than fledging startups because it is a safer bet.
  4. Have caps on pay-as-you-go software packages so that they can have predictable expenses for budgetary purposes.
  5. Buy software packages that have more features than they want now, because it is a safer bet to make now.
  6. Buy extended product warranties because it adds predictability that if anything goes wrong during this time, they do not have to spend money.
  7. Pay bills on the same day every month because it allows one to have a predictable cash flow.

In most cases, products are expected to have predictable outputs to given inputs. So, in our lives as software product managers, adding predictability to our customer’s business or personal lives could be a dimension used to enhance our products. And once you do, make sure that this is pitched to your customers – because they may not tell you that they are looking for more predictability, but I will bet you that unknowingly they do.

Makes sense? Let me know.

When does a startup stop being one?

When does a startup stop being one? Is it when:

  • It gets funded – no, can’t be because vast majority of them get seed funding.
  • It gets customers – no, that can’t be it either
  • It gets revenues – no, because customers could be paying for the service
  • It becomes profitable – no, because even profitable companies are sometimes called startups.
So it was something that had been bothering me for a while. I have asked others but never got a satisfactory answer. Then couple of weeks back I attended the simulcast of Lean Startup held in San Francisco – beamed to the Microsoft offices in Cambridge. There I heard the definition of a startup from Steve Blank which makes a whole lot of sense – “Startup is a temporary organization designed to search for a scalable and repeatable business model“. That to me gives a very easy criteria to determine when a startup stops being one.
Thoughts? Kindly share your thoughts via comments.
Image: Courtesy of freeclipartnow.com

B2C vs. B2B product management – 16 differences

Most of my product management career has been spent doing B2B product management. For the last year and a half, I have switched over to B2C product management in my current role as Director of Product Management at Gazelle. Last 12 months has been a lot of fun learning a whole lot of new things in the consumer world. Given this learning, I have been able to create a long list of things that matter a whole lot more doing B2C product management that may not be as important doing B2B product management. Here we go:
  1. It is a millions game – Victory is declared when you have million+ customers, not hundreds or thousands (if your goal is to become the “brand” in the space you are in) unless you are in a niche market.
  2. There is one buyer most of the time – no technical buyer, no economical buyer, no user. The consumer is coming to your website with intention to buy something for themselves with their money. (exceptions do exist – for example, if I am buying something for my wife or kids or my mom – though this is not the mainstream use case).
  3. Short sales cycles – Ideally you want every customer to buy from you on your first visit (never happens, but the goal is to get as many to do this). There are no RFPs, no demos, no data sheets, no whitepapers, no lunches with prospects to convince them to buy. Your website is the demo – if they don’t like or understand something, they will leave and may never come back.
  4. Show me the money  – It is harder to monetize consumer products. A lot of apps, services are available for free, and consumers are used to getting products and services for free online. Consider a limited-feature free product or limited-time free trial offer, setting the stage and expectations that they will need to pay. Make sure that the value proposition is crystal clear to the customer.  Remember, they are spending their hard earned money and not their employer’s.
  5. Short attention span – KISS (Keep it simple stupid) principle applies so much in B2C. Use middle-school reading level language on your site – short, simple, easy to digest. None of the gobbledygook you can get away in the B2B world with (the reliable, scalable, innovative, high performance, architecture marketing BS) works.
  6. Details matter even more – Given the short attention span and the high propensity to go elsewhere (one mouse click away), everything from page load times count. If your page takes long to load (read that as more than 2 sec), chances of your prospect leaving go up exponentially, unless you are an established brand (read Amazon or Google).
  7. Product experience rules – Site usability matters a whole lot. There is no consulting, no professional services in the B2C world. Either the customer gets it the first time or by quickly looking through your FAQs or they just leave.  If your product is not easy to use, expect it to be returned (or if it’s a website, abandoned). Consumers rarely RTFM.
  8. Customer experience rules – You need to deliver a “crazy awesome” customer experience to every customer.  Over and above the product experience, you need to deliver an awesome experience at every touch point – whether it is customer care, online content, surveys, newsletters – you need to aspire to beat your customer’s ever rising expectations. Why? See #9.
  9. Social proof is mandatory – Consumers look for social proof – who else is using it, what do other think about it? Is this site real and trustworthy? Again, remember, they are spending their money and not their employer’s. And by social proof, I don’t just mean canned testimonials (which by the way lot of buyers do not trust), but instead they expect to read both positive and negative reviews about your service on the web, Facebook, Twitter etc. If you deliver an excellent experience, they will tell others. And if you deliver an awful experience, they will tell even more people and you will not even know. However, they do not expect you to deliver an awesome experience to everyone – some customers can just not be pleased and no company is perfect – you are bound to screw up at least in some cases. So if all they see are positive reviews, it could be a cause for concern (trustworthy?). So, instrumenting your product to allow your customers to easily share their experiences (good and bad) is important.
  10. Building brand equity matters – You need to appeal to the masses right from the word “go”, but it will take time. There is no fast way to get there. But once you have built and earned good brand equity, you will retain the consumer mindshare for a long time. For example, when it comes to buying books, do you think of Amazon or Borders? When you think about mp3 player – do you think of ipod or zune? When you think about search, do you think Google or Microsoft? When you think social media, do you think Facebook or Orkut? It took a lot of work for all these companies to get to where they are now. Why? Read #1 again.
  11. Web analytics – In the B2C world, you live and breathe “web analytics” – unique visitors, bounce rates, traffic sources, conversion rates, conversion lifts, funnels etc. become part of your everyday terminology. It is all about getting more customer traffic to your website and getting them to buy or do whatever that helps you make money. If you are running an eCommerce site, you want to make sure they find the thing they want and then buy it from you.
  12. Test, test, test – Getting ready for continuous A/B testing and multi-variate testing becomes part of your DNA. Consumers are fickle, they change their mind all the time. Hence, no matter how many usability tests you have done before you release changes to your site, it can never guarantee success. You need a lot of data points to declare a winner. The only way to find out is to release changes to production and then conduct A/B or multi-variate testing before you declare a winner. Be prepared for surprises, because what you think will win could turn out to be a sore loser.
  13. SEO, SEO, SEO – every page you create on your website needs to be SEO (search engine optimization) friendly. Why? Your highly qualified prospective customers will find you primarily via two mechanisms – 1) search engines when they are about to buy what you are trying to sell or 2) by word of mouth. So as a B2C product manager, you need to have a decent knowledge of how SEO works.
  14. Keep them loyal – As I have mentioned before, word of mouth is huge in the consumer world. Because it is not one person telling another, it is one person telling 10 of his/her family or friends. Consumers love loyalty programs – it is your way of thanking them and keep coming back. I still fly American Airlines because that is where I have the most miles. (I hate their customer experience, but I still remain loyal because of the miles).
  15. Respect their privacy – Ask only for personal information that is absolutely needed. If sensitive personal information is asked, explain how you would use it. If a consumer opts out of receiving marketing material from you, respect that.  Do not require them to “register” with your site to use your product/service unless required. Allow for “guest checkout”.
  16. Stay in touch – via newsletters, Facebook. Get them to “like” your FB page – use your page for periodic product updates, contests, relevant news, etc. Remarket to them with relevant content, coupons etc. But never, ever spam your customers.
Do you agree? What else are the differences between B2C and B2B product management that you have come across? Kindly share your thoughts via comments.

My recent Product demo experience – 3 key learnings

In the past few weeks, I had the opportunity to sit through three product demos that were all done using web conference (Goto Meeting and WebEx). Two of these demos went very well, we understood everything we wanted to know and we figured out whether the products will meet our business needs. More on that later.

The third one was an outright disaster. This particular  demo was in an area that not many of us knew enough about and we were looking to educate ourselves with not only on the product but also get a better understanding of the underlying methodology. When the demo was set up, we had clearly communicated to the vendor (at least we thought we had) on what we were looking to get. We had also indicated that time was tight and that we probably had 45 minutes max. To make the whole situation tricky, there was the software vendor, a potential professional services partner and an internal consultant who was introducing us to the software vendor.

Here is how the demo went (remember the 45 minutes equates to about 20 min of demo time if you account for the time needed to answer questions during the demo):

  1. 15 minutes were spent on the corporate slides – here is who we are, when we were founded, we do blah blah blah (nothing I remember right now), here is how much profits we made last year, here are the complex equations that are underpinnings of the technology (I am not joking, there were equations on slides), here are the Fortune 500 clients that use us etc.
  2. Another 15 minutes of the admin console where everything can be looked at etc.
Here is what transpired amongst the audience which btw had all the relevant stakeholders:
  1. In the first 2 minutes of the corporate slides, most of those in audience lost interest and were busy checking their emails
  2. By the time, 15 minutes were up, we had still not learnt anything that we came to learn about. People were feeling cheated – why are we wasting time on this?
  3. What followed was tech focused, nothing addressed the business problems we were looking to solve.
  4. Nothing was professional about the demo, everything looked like a hodge podge.
At the end of 45 minutes, we did not get much out of it. Half the folks had to bail because they had other meetings to go to.
Now allow me to compare and contrast the above experience to the two successful demos:
  1. These two vendors did discovery work to find out the business problems we were facing and they did this directly with me – before the demo. To their advantage, there were no middlemen.
  2. During the demo, they focused on our business problems and not themselves (not one word on who they are, how big they are etc.) until they had completely addressed how their solutions could solve our business problems.
  3. Everything was done in the allotted time. They followed up with emails to check if we had any outstanding questions and enquiring about the next steps.
So what are the key learnings from all of this for those folks putting together product demos. Here are my recommendations:
  1. Do the discovery call before the demo: If you are the one doing the demo, try your best to engage directly with the customer for a discovery call. Avoid leaving this to a third party unless these folks can educate you well on the customer’s business problems. Find out the business issues faced by the customer, how they are solving the problem today, what solutions they are using etc., timeframe they are looking to solve the problem and if they have a budget. Budget and timeframe to purchase are very important – if there is no budget, it is a lot harder to sell.
  2. Business problems first: Your prospective customers don’t care who you are, how big you are or how great you are, unless you can solve their business problems. The only reason they are engaging with you is to find out if you can help them. Satiate that need first, nothing else. Everything else can wait. Stuff for the economical buyer (financial viability, your revenues etc.) or for the technical buyer (technology underpinnings etc.) can come later – not in the first demo. Selectively disclose stuff – peel the onion one layer at a time – don’t bury the customer with information, keep it simple.
  3. Respect the customer’s time: Find out ahead of time how much time you have and who will be in attendance. If the time is insufficient for you to do the demo effectively, ask for more time. Explain why it would be beneficial to allot more time – start becoming an advisor to the customer. Once you know your constraints, honor them. Make sure you hit the salient points customer is looking for during the allotted time. If you do this right, two things will happen – you will get more time right there and then or a follow up demo will be set up to take this further. If either of this happens, you now have an engaged prospect and you are making progress towards closing a sale.

You can choose to avoid doing the homework to your own peril or spend the time during discovery to start building effective relationships with your prospects.

Thoughts? Do you agree?

If you read this post, please consider leaving a comment, share this blog with your friends and colleagues or subscribe to the feed to receive future articles delivered to your feed reader or via email (use the text box at the top of the right column)

Image: Courtesy of carecleaningandprotectionexperts.com

Prioritize based on frequency, not size ….

When I have done customer interviews to better understand customer pain points and ways to enhance the product, often times I have been asked one of two questions:

  1. Are you really interested in solving this or listening to my problem? I only have 2 licenses of your software. Don’t you only listen to customers who have 50 licenses or more?
  2. But this is a simple issue, will this ever make it into your list of things to improve on?

I remember giving the same answer each time for question 1) – my job as a product manager is not to worry about how many licenses (“size”) you have, but to understand your pain point and then extrapolate to see how many other customers will benefit from solving the problem (“frequency”). Innovative ideas typically come from one individual (think about all the great inventors – many of them invented things in their basements individually) and not from organizations. So before you ignore your small customers, think twice. Instead worry more about the “frequency” of the issue.

The second concern has some validity. Companies under the false pretext of being innovative are looking for problems that are big news – the one that will make a splash. Agreed!  Product managers should always look for differentiated ways to solve “common” problems to stay ahead of the competition. But this should not be at the cost of ignoring simple issues with your current product. Here is a simple formula I have used to prioritize all of the issues.

Determine:

  1. How many times a typical user encounters the said issue? (Once a day? many times a day? once a week, once a month, once a year etc.) = A
  2. How much time in minutes do they waste each time they encounter this issue to find a workaround? = B
  3. How many users will encounter the same issue? = C

Importance of the issue (priority) = A x B x C

For example, if the user encounters an issue with every 3rd mouse click (because of the delay the software responds to the click) and if a large number of users encounter it, it will be amplified a whole lot even if the delay is only a few milli seconds. Compare that to an issue which occurs once a year for a very few users. It maybe something you could easily de-prioritize because it could very well be a niche problem.

Don’t get me wrong, lot of emotions do get involved in whose issues get fixed – one with executive mandate, one from a vociferous customer, one for the customer that will make a huge purchase etc. But as a product manager having the above data will help you justify the prioritization you are making and then if someone wants to override your decision for valid/invalid reasons, that is perfectly fine. At least you should be able to sleep in peace that you did your homework.

Thoughts? Do you agree? How do you do prioritization?

If you read this post, please consider leaving a comment, share this blog with your friends and colleagues or subscribe to the feed to receive future articles delivered to your feed reader or via email (use the text box at the top of the right column)

Image: Courtesy of fiscalgeek.com

5 things I learned about Software Product Management in India

I am currently enjoying my week long vacation in my hometown of Ernakulam after a week of software product management seminars and workshops in Bangalore and Hyderabad. As a bonus, my host Pinkesh Shah, CEO of Adaptive Marketing and I were invited to the Indian School of Business in Hyderabad by the students who were keen to learn more about product management.

So what did I actually observe and learn from the 125 product professionals I interacted with? What is the real state of software product management in India? What are the software product managers doing now and what are they looking for? Though I did not get to meet with software product managers from large MNC’s such as Google, eBay, IBM, Cisco etc. that have large operations in India, my numerous conversations with Pinkesh indicate that the picture there is not that different from what I learnt from the product managers I met with.

So here are the top 5 things I learnt about software product management in  India.

1) Current focus is on requirements management and software delivery: Software Product Managers in India currently are playing the role of requirements managers or product owners (in the world of Agile). They are responsible for defining the product functionality and working very closely with engineering teams co-located here in India to ensure the iterations/releases get delivered on time.

2) They manage products sold in the United States: The products they work on are primarily (if not all) for the US market. Hence, the amount of direct customer facing activities they take part in is very limited at this time. They do not seem to have many opportunities to travel to the US to meet with their customers. They understand this as a major pain point. In most of the cases, the Indian product managers (I got to speak with) do not have a product management counterpart in the US. Input for the product enhancements were coming directly from marketing, sales or the executive management, as opposed to someone who was spending time listening to the customers in a non-sales situation. This is very worrying because those of us who are experienced product managers know how frustrating listening to just sales to drive future product direction could be.

3) Titles are one too many – Just like in the US, there are too many titles for product managers in India. Technical product manager, product owner, product manager, product professional, the list goes on.

4) Engineering talent is itching to find new career opportunities: Folks who have spend a lot of time in engineering and project management are now starting to ask – what next? I heard this during my seminars and it is also a common question I get from the readers of this blog – how to transition into product management. Training demand and opportunities for vendors who provide training on software product management are bound to increase.

5) They are confident, fearless and hungry: What impressed me the most was the talent and the confidence of the software product managers in India. There are some that work on very successful products in the marketplace – for example, the product managers Mukesh Marodia and Ramesh at OpenText were working on a very successful portal product used by a number of Fortune 500 (apparently 1 out of 3 pages on the internet is powered by Open Text web cms). The product managers at Nokia were working on the different software components such as messaging and video capture used in all of the Nokia mobile phones. Then there was Chaithanya from Inmage Systems, the lone product manager in the company responsible for his company’s data recovery solution sold in the US. I could go on, but all in the all I was so impressed by the budding product management talent in India.

So what is the future? I am convinced that the talent in India has a bright future ahead. I am making a bold prediction here, not based on facts but based on the trend that I have been reading about. Given the size of the Indian market in terms of number of consumers and their total purchasing power, every company on this planet will be looking at building new software products for the Indian market. Software products that are not watered down versions of products build for the western markets and then adapted to the Indian market, but instead software products that are designed from the ground up in India for the Indian market. We already read about this trend in companies such as GE and automotive markets, but I am predicting that this trend will heat up in the next 5 years. When this happens, the current software product management talent in India would have matured enough to play a significant role. They will soon find themselves in an enviable position where they will no longer be concerned about lack of opportunities to meet with their end customers because they will be living right amongst them. These software product managers are hungry, smart and more importantly they are confident. I am so happy to have met these budding product managers and their future cannot be any brighter. Product Managers in the western world (including myself) take note, I treat the talent here in India as competition for sure.

If you enjoyed this post, please consider leaving a comment, share this blog with your friends and colleagues or subscribe to the feed to receive future articles delivered to your feed reader or via email (use the text box at the top of the right column)

Happy New Year! Top 10 blog posts of 2010

Wishing you all a Happy, Healthy and Prosperous 2011! Thank you for reading this blog in 2010 and for your support.

Here are the top 10 most read posts of 2010:

1) 10 job hunting mistakes you should avoid

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

3) Managing your product management career – Part 1 – Assessing your skills

4) Is software product management needed in a startup?

5) Product Cannibalization ….

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

7) Managing your product management career – Part 2 – Marketing “you”

8) 10 Best practices for doing Software Usability testing

9) 7 questions software product managers must ask during a job interview

10) What to look for in a product manager?

If you have not read them, please enjoy. I will appreciate if you leave me comments. If you have not subscribed to this blog, please do either via RSS feed or via email through the text box available on the right. Happy New Year once again!

Announcing my product management workshops in India (Bangalore and Hyderabad)

I am very pleased to announce that I will be in India to conduct 2-day product management workshops in Bangalore (Feb 1-2) and Hyderabad (Feb 4-5) early next year. I will be offering these workshops via Adaptive Marketing Inc. that I had introduced in my earlier post.

In the past couple of years, many readers who were looking to make a switch into product management had written to me asking for my recommendations on how to go about making the transition from the technical side to product management. It was clear from these questions that there was a dearth of training in product management in India. So when Adaptive Marketing reached out to me a few weeks back to explore possibilities, I knew that offering product management workshops would be the right thing to do. So for all those readers who either have asked me such questions before or are considering transitioning to product management, this workshop will be tailored just for your needs. I will be drawing on all the lessons learnt from my 14 year career doing software product management in this workshop – so it is not going to be just theory, but filled with real world examples.

Here is the outline.

Fundamentals of product management

  • What is product management?
  • Product lifecycle phases
  • Roles and responsibilities of product managers
  • Differences between project management and product management
  • How to successfully transition from project management to product management

Product Management Organization

  • Product Management vs. Product Marketing
  • Product management in startups vs. large companies
  • SaaS software product management vs.  shrink wrap software product management

Market Research and Analysis

  • Market research and analysis skills using qualitative methods (customer visits, interviews etc.) and quantitative methods (user surveys)
  • Who do you talk to? Where do you find them?
  • How to determine what to build?
  • Value Creation
  • Writing business cases
  • User personas

Product Design & Usability

  • Product experience vs. customer experience
  • Importance of product design and usability
  • Best practices of writing requirement documents
  • Product design – wireframes, mockups, working prototypes
  • Market validation

Product Development

  • Build, buy vs. partner
  • Product Development processes
  • Working with engineering
  • Working in an Agile environment
  • Market validation of the built product – usability testing, alpha programs, running Beta programs etc.
  • Pivoting your product based on the initial market success

Go to Market Plan

  • Preparing for product launch
  • Alignment with internal cross functional teams
  • Working with Product Marketing and Marketing Communications

Product Metrics

  • Measuring market success
  • Quantitative measurements
  • Qualitative measurements
  • Future releases of your product

Product Management Career

  • Technical skills needed for success as a product manager
  • Soft skills needed for success as a product manager
  • How to successfully manage your product management career so that you are positioned for success long term.

Who should attend:

Managers and executives who are currently engaged in: 

  • Service delivery
  • Project management
  • Program management
  • Development
  • Quality Assurance

and even current Product Managers who want to further enhance their skills.

Pricing:
$990 per person. $850 if registered before Dec 31st. (Less than half of what other US based professionals charge in India and 1/3rd of what workshops in the US cost).
Groups of 3 or more from the same company can get a special Corporate discount of 15%

If you are interested, please register on Adaptive Marketing’s website. If you have any questions, please let me know and I will be happy to address them.

State of Product Management in India

It has been 20 years since I left India as a young graduate. Indian software industry was unheard of at that time or was in its infancy. But since then, India has become the global powerhouse in software services. Initially, the industry grew mainly through outsourced projects for clients in the United States. Big powerhouses such as Infosys and Wipro grew to what are now worldwide brands. Then, over the years, as companies worldwide realized the talent available in India, multi-national companies started arriving in droves. Microsoft, Intel, IBM, GE, Google,  you name it, started opening development offices in India.

But, will India be a one trick pony in software – delivering just services? This has been a common topic during dinner discussions with my friends as to whether Indian software industry will ever see product companies emerge that will become as well known as Infosys or Wipro. There have been some successes such as Zoho whose entire development group is based in Chennai. Then there is Tally that owns the ERP market in India. I have always wondered as to the state of product management in India. It was refreshing to see an Indian product management forum emerge on LinkedIn where very engaging discussions are now taking place.

Then, a few weeks back Pinkesh Shah, CEO of a Bangalore based  company called Adaptive Marketing reached out to me. Pinkesh was former VP of Product Management for McAFee here is the US and had now moved back to India. Pinkesh has now set up a product management training and consultancy company in India. Adaptive has also published the first product management and marketing survey – you can download the report for free. The survey has very useful information that is worth reading both for product companies in India (local or MNCs) or for those here in the US that are thinking of establishing offices in India.

The big question is what will product managers in India do – would they be working on products for the Indian market? Or for the Far East or Middle East that are all experiencing explosive growths? This would make logical sense given the proximity of Indian software product managers to these markets and also given their knowledge of the cultures in that part of the world compared to those of us in the Western World. One of the interesting tidbits I found in the report was how even professionals in the IT services companies were performing some of the product management tasks such as requirements management and competitive analysis under the titles of Business Analysts, Client Engagement Managers and Business Development Managers.

What do you think? I would love to hear from my blog readers based in India on their take on the state of product management in India.

Product Cannibalization ….

Last week, I got mail from Netflix indicating that my subscription fees was going up by $3 a month from $20/month to $23/month. They suggested that I instead switch to $8/month internet streaming plan. They mentioned that they were fast expanding the library of movies available via instant play. I switched to the $8/month plan immediately – we were getting less and less DVDs by mail and were watching more and more movies via streaming using our Wii console plus we did not care if we had to wait to watch the latest movies. So it was a perfect solution for us and Netflix.

As a software product manager, of course it got me thinking more. What is happening at Netflix to me is product cannibalization, except that they were doing it to themselves. They were pushing their own customers from their bread and butter business of DVDs by mail to another product of theirs that costs 1/3rd less. Imagine that. And Netflix is a publicly traded company that has to live up to Wall Street’s expectations. I commend Netflix for doing what not many companies will dare to do.

I can count the following advantages for Netflix from pushing customers to streaming:

  1. Scalability – you do not have to increase buying DVDs, increase warehouse space to handle all of the DVDs and of course the increased shipping costs as your customer base grows. Internet streaming has no touch costs and no shipping costs involved.
  2. Possible international expansion – more and more people overseas have high speed internet connections. They are now a potential market – instant scalability again without having to worry about huge infrastructure and operational costs, import restrictions, fear of not getting DVDs back etc.
  3. Response to competitive threat – technology  for high speed streaming is here. This is a big threat to Netflix’s DVDs by mail business – if they don’t adapt, they could go Blockbuster’s way.

The DVDs by mail business is expected to be around for a long time, but Netflix is seeing the writing on the wall and is positioning itself to take advantage of the new technologies and retain its leadership position in the industry. I am quite impressed by what they have done and will continue to remain a loyal customer of Netflix. I am sure it is fun to be a software product manager at such a company.

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.

Image: Courtesy of netflix

Field of dreams is not a product strategy

I have written in the past about how “if you build it, they will come” is not true when it comes to product management. So it is refreshing to read another product person Joe Johnson from High Start Group echo the same comments when he writes about “Field of dreams is not a product strategy“. Cannot agree more with him. Enjoy this very short and sweet post.

Managing stakeholder expectations via Product Council

From time to time, when I talk to other software product managers about their biggest challenge, they often say that managing internal stakeholder expectations is their biggest challenge. Yes, of course. After all, product management is like herding cats. Sales goes and makes promises to customers without asking the product group, marketing wants their projects done first, your development team has their own pet projects, customer support wants customer’s burning issues fixed first, professional services want projects that will make them do implementations faster. And all of this needs to be done in a short time with limited engineering resources.

So is there a way to manage these expectations and make sure there is a clear product direction? I have been using Product Council meetings to successfully do this. Product council is a concept I picked up from Marty Cagan’s Inspired: How To Create Products Customers Love book. I strongly recommend this book to all product managers.

So what exactly is a product council meeting and how do you run it?

Product council is a meeting with the executive management (including the CEO) once a month to review the product strategy and the product roadmap and resolve any conflicting product priorities that are currently in play. You as the product manager or head of product management should run this. This way, everything is presented in an impartial way and the whole group is presented with the projects that the product and engineering team is currently working on and need to work on in the future. If there are conflicting priorities, you present the pros and cons of the priorities and ask for a resolution from the product council. Make sure that the stakeholders whose priorities are creating the conflict are in the meeting. Be clear that you want a resolution at the end of the meeting (not afterwards) because the product team needs to start working on the right project(s) based on the decision. Force a decision by the end of the meeting.

I often hold these meetings once a month for an hour. It is a standing meeting that is on every stakeholder’s calendar. The agenda is typically the following:

  1. Review the product strategy
  2. Update since the last product council (what have we done since then)
  3. What are we currently working on?
  4. What is ahead of us?
  5. Review product roadmap
  6. Presentation of any conflicting priorities
  7. Final decision on prioritization

It is important that you as the product manager or as head of product management help the executive management see the conflicts and lead them through a prioritization exercise. Once a decision is reached, there should be consensus from all stakeholders because it is an educated decision made based on review of pros and cons of each priority and more importantly facts (instead of someone’s opinion or support for pet projects).

So are you done after product council? No. You have to make sure that you keep the product council abreast of progress being made on the new priorities. If the project hits a bottleneck because of some unforeseen technical or business related reason, you need to immediately raise it to the product council rather than waiting till the next meeting. Communication is key to managing stakeholder expectations. If you do this well, you should be able to effectively reduce your stress level as a product manager.

Thoughts? How are you as a software product manager managing stakeholder expectations?

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.

Watered down products typically fail ….

A company has success with its enterprise product. But the company wants to accelerate sales and increase the number of customers.

Someone says – how about small businesses? Of course, that is a large market. Why did we not think of them? We already have the enterprise product in the market – so building the small business version should be easy.

The CEO says “Get rolling, I want to ship a small business version next month.”

Everything is fast tracked – product management starts with the enterprise product, cherry picks features to turn off and voila, small business product definition is done. That was too easy. What about pricing? Hummm, let us see, how about 60% of the enterprise product? Done. Product ships, everyone is excited on launch. There is a party, the CEO is thrilled – the team delivered.

Roll forward 30 days – the small business product is not getting traction. Sales comes back to product management with requests for one-offs – “hey, I was talking to this company – they love the small business version, except they want this one more thing that is in enterprise version – do you think we can turn it on? After all it is there, should’nt it be just easy to turn that switch back on.” Sales applies pressure because they have to meet their numbers for the quarter and it is so enticing to do this because no new feature has to be developed – it is already in the product!.

Unfortunately, this is a common story and I have personally lived through months of the above. Welcome to the world of customization hell. It is worse than the enterprise product because what the company has essentially done is allowed customers to demand the enterprise product functionality at steep discounts, now that you have two products – the enterprise version and the small business versions. This is not limited just to small businesses. Enterprise customers get wind of the small business product and want the small business version but with feature X, Y and Z and at the small business price.

When building products for new market segments such as small businesses, companies often make the mistake of creating a product by turning off a bunch of features from their enterprise version and slapping “for small business” on this watered down product.

This fails for one of two reasons:

  1. The product even with some features turned off is still considered too complex by the small business users because the needs are different and also the persona of the target user in small business are different.
  2. Small businesses have the same needs as larger businesses and hence they find that the watered down product does not satisfy their needs.

Let us examine these two issues in more detail by considering two examples.

1) IT network monitoring product: Large businesses tend to have an IT staff in hand to set up their networks. These highly qualified staff typically are geeks and take pride in the fact that they have to use DOS prompts and unix like interfaces to get their job done. Now consider a small business which has to set up a similar network. Very often, in a small business, it is probably the owner that may be setting up the network – he is not an expert at networking, wants to quickly set up his network and get back to business and has no time or expertise to deal with DOS prompts and Unix like interfaces or to understand networking terminology to set up his network. He wants a very simplified interface that hides a lot of complexity, wants to select a few options and have the network up and running as quickly as possible.

Now let us take another example –

2) Performance review management software: Companies do performance reviews either on an annual basis (everyone gets their reviews done at the same time) or at the time of employee’s hiring anniversary date. The software vendor decides to offer these two options only in the enterprise version and turn off the capability to performance reviews at the employee’s hire date in the small business version. This does not work out because even small businesses have the need to do performance reviews based on the employee’s hiring anniversary date.

How to do this right?
So how do you avoid these two traps. Here are some ways to do this right –

  1. Clearly understand the needs of the small business user. It takes the same amount of time and deep understanding as the enterprise product to get it right.
  2. Clearly understand the persona of the user who will potentially use the product before you decide what the product needs to be. More often than not, you will find that usability tolerance to be vastly different between small businesses and large enterprises – not that large enterprises don’t like user friendly products, but they are a little more tolerant because of the resources they have to handle implementation and ongoing maintenance.
  3. Make your product offerings by balancing the needs of the users and your business goals. If the functionality needs are the same, make the product offerings different on other variables. For example, you can impose limits on the number of users who can use the product or by by pricing your product as per user. This way small businesses can get all the functionality they need, but pay less fees depending on the number of users they have. Or limit the amount of data they can store – for example, the enterprise version of a CRM product could allow saving unlimited number of contacts, but the small business version may allow only upto 1000 contacts. If it is a survey software, you could segment based on the number of surveys someone can run per month or by putting a limit on the number of responses you can get per survey.

In essence, simply watering down products is not the right answer.

Thoughts? Do you agree?

If you enjoyed this post, please spread the word about this blog, consider leaving a comment or subscribe to the feed to receive future articles delivered to your feed reader or via email using the text box in the column on the right.

Events force actions

Events force actions – this has been such a guiding principle for me that it has allowed me to get clarity when there is none, has kept me focused when I have been distracted by too many things to do, has helped me achieve something because the deadline is looming. For example, I am about to leave on vacation and the last two days have kept me laser focused on getting things done.

I have blogged in the past that everything needs a head and a date, otherwise it will never get done. So everytime, you think you or your team is not making progress towards your goals, create an event and drive an action towards it. The event is essentially a milestone such as an alpha launch date, beta launch date, a demo or presentation to the executive team or usability testing with customers. Once you have got others to commit time to an event, you or your team has to react and get moving. You will be surprised how such a simple action on your part can energize the whole team and get things moving.

Thoughts? Are there any additional ways you have energized you or your team to get moving?

If you enjoyed this post, please spread the word about this blog, consider leaving a comment or subscribe to the feed to receive future articles delivered to your feed reader or via email using the text box in the column on the right.

Product Camp Boston – this Saturday

Product Camp Boston is this Saturday – May 22 at Microsoft New England Research and Development Center. If you are a product manager in the greater Boston area, have you registered yet? If not, what are you waiting for?

If I get selected by attendees,  I intend to run a session called Managing your product management career. If you attending and are interested in knowing how to build your personal brand so that you stand out as a product manager, how to market the only product you are fully in charge of – “YOU” and also get some practical job hunting tips, please vote for my session.

Software scalability and Exceptions

Growth in business puts scalability and performance demands on the software product that the company provides. These demands could take the form of site accessibility (number of concurrent users) and also number of exceptions that need to be handled by the system. Issues caused by increase in the load experienced by the product is well known (solved by load balancing, more servers, well written web pages such that it can load faster etc.). I want to touch upon an equally important scalability issue which is related to the number of exceptions and their frequency.

So what do I mean by an exception? I am not talking about exceptions from a software programming sense where the concept of try-throw-catch statements to handle anomalous situations in the code is used. Instead, I am talking about anomalous situations that can happen from a user or a business process perspective. Let me clarify more with a simple example.

Assume that our product does one thing – takes a full name, typed in by the user and splits it into first and last name before storing it into the database. Sounds very simple. If the user types in “John Smith”, first name = “John” and last name = “Smith”. Everything goes well but over time, until the system starts encountering names it had never seen before. Names such as:

  1. John Doe Jr.
  2. Safraq Ahmed Naveed
  3. B. Sunil
  4. Rajeev Kumar P.C.
  5. DÖRTHE Austerlitz
  6. Timo Gärtner

Let us take the second and third names in the above list. In the case of John Doe Jr., you don’t want the system to store the last name as Jr. and refer the customer as Mr. Jr. in the emails it sends him. In the case of “Safraq Ahmed Naveed”, what do you do with the name “Ahmed” – is it part of the first name or last name? Can your product handle special characters such as “.”, “Ö” or “ä” in the names?

Such problems should also be considered scalability problems. It may not cause site performance issues, but it could prevent users from using your product. I have used a very simple example to illustrate the issue. But in the real world, when such exceptions are encountered in the core business process, things can take an ugly turn not only because of the number of the types of exceptions, but more because of the frequency at which each of this happen. What used to be considered an edge case when you had 100 users could quickly turn into a mainstream use case when you have a 1000 users. In my career, I have experienced numerous such issues – all of them sound trivial – but that could have caused major impact on product usage. If you are running a consumer facing website, you may not even know about these use cases that are affecting your business because customers turn away when they find that the website cannot even handle what they consider a simple use case (one that applies to them, but which in your books is an edge case).

As software product managers, we need to be aware of these exceptions that may be raised because of expansion into a new international market, a new vertical etc.

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

Hidden costs of software outsourcing

In my software product management career, I have worked with remote software development teams in India, China, Australia, Ukraine and the UK. In many of these cases, we were working with outsourcing partners. I have been wanting to write a post reflecting on what actions ensured success and what resulted in failures. It has been on my to do list for a while – like a year.

Software outsourcing is always pitched as easy to do. Common benefits that are advertised include 24-hour development day (they are coding while you are sleeping!) and the large cost benefits through hiring cheap but good talent off-shore. While there is an element of truth in this, it is also a double edged sword. The 24-hour development day can be advantageous or disastrous because a lot of bad decisions can be made by your partner team while you are sleeping. The time it takes to discover these and then rectify them is at least 48 hours. Developers overseas are also typically cheap to hire because of the favorable currency exchange rates, but if you don’t set up the right infrastructure, you could lose precious time and money because of bad architectural decisions, poor code quality, major integration issues etc.

Last week, I was forwarded a slide deck on outsourcing and its common pitfalls. This deck captures the valuable lessons I have learnt over the years working with software outsourcing partners. It in fact captures it better than I could possibly have.

This is a must read for anyone who is doing outsourcing, who has been burnt by it or who is looking to explore an outsourcing model for software development. Consider this a good 5-10 minute primer.

As full disclosure, Sitrus who has put this presentation together is the outsourcing partner in Ukraine that I had worked with and are one of the better ones I have worked with. I am not paid anything to pitch their name or to do this blog post.

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


Friction points – Why customers don’t buy from you

It is our job as product managers to find out why our customers “buy”. Buying is a very emotional behavior especially when it comes to consumers. When selling B2B products, the purchase cycle typically follows a chain of events – RFP to demos to pilots to implementation to release to production. But what about consumers? How do they make buying decisions?

It is very important that you delve deeper into the customer’s lives to see what influences them. For example, on eCommerce websites, shopping cart or checkout abandonment is quite common. This is one of the metrics eCommerce retailers keep a close eye on (or should keep an eye on). Why? Consider the chain of events that happens before the customer abandons the shopping cart.

  1. Customer comes to your site instead of going to one of your competitor’s sites. Awesome, they know that you exist and they have selected you!
  2. They find the items they want to buy. Awesome, you have exactly what they want.
  3. They like the price and add the items to their shopping cart. Hurrah, it is wallet time!
  4. They start the checkout process (I see them pulling their wallets out)

Then whoosh! all of a sudden they abandon you. You almost had their money, but in a flash they were gone. Given that it is a website, you don’t know who they were or how to contact them to understand why. All you know is that you just lost a sale.

So what can you do to improve your situation when faced with this? I propose that you pay close attention to “friction points” that cause the customer from not buying from you.

There are many eCommerce “friction points” that have been well documented, but you still see so many sites that make these mistakes.

1)   Form fatigue – every field on the form that you are asking the customer to fill out is a friction point. Especially, if you are asking for information such as fax number, address (especially if I am signing up for an email service), annual income (yes, I am so inclined to reveal this to a complete stranger) and the list could go on. Your marketing department will likely have justifications as to why each of these fields are needed, but you as a product manager must think from your customer’s perspective. Yes, marketing is important, but you have to find the right balance between your needs and the customer’s needs. After all, your marketing department is not the one paying you money to keep you in business.

2)   Required registration – If users don’t understand why it is needed and the value registration would provide them, they will flee in droves. I have seen this in person during focus groups and usability testing. Common reaction: “S***w this, I am out of here”

3)   Surprises – Don’t surprise them! Imagine that you as a customer gets to the end of the checkout process and the retailer springs a $15 shipping fee on you. How will you feel? Would’nt you abandon if you think the shipping fees is a rip-off?

However, there are a lot more friction points that certain verticals take advantage of or there are others that if solved can increase conversions. The classic example I always use is “mailing” – the old fashioned way where you have to deal with envelopes/boxes, stamps, post office

Let us first look at the example where the company is hoping and praying that you will not mail anything. The commonly used marketing gimmick of “Mail-in rebates”. Retailers offer discounts on products via mail-in rebates. The price after mail-in rebate looks very attractive while you are in the store or when shopping online. But these companies make you buy at the full amount and want you to send mail-in a flimsy card to get the rebate. They are banking on the fact that most customers will not mail it in because of the “friction points”  involved in filling out the long form, attaching all the required documentation and making sure they mail it within the specified time period. And they are pretty successful at it because research shows that 90%+ of customers don’t.

Now let us take another example, where it is paramount to the company that customers mail things in for it to be successful. I currently work at Gazelle.com where our customers trade-in their used electronics such as laptops, iPhones, Blackberries, cameras, camera lenses, gaming consoles, movies, video games etc. for cash. We sell the gadgets we buy via eBay, wholesale channels or recycle them responsibly all here in the United States. The process involves the following steps:

1)   You tell us about the model and the condition your gadget is in by answering a few questions on gazelle.com.

2)   We tell you right away what we will pay you if the gadget passes our inspection and matches the condition you told us in.

3)   You mail us the gadget, we pay for shipping.

4)   We pay you via the payment method you selected (check, Paypal, Amazon gift card etc.) after we complete the inspection within 10 business days.

We are experiencing explosive growth, but one of the “friction points” we always think of, is the act of our customers having to ship their gadgets to us. It does not matter if a million customers come to our website and tell us that they have a million items to sell us. Unless they actually put it in a box and mail it to us, it does not matter.

So here are ways we work hard to reduce this “friction point” of shipping:

1)   We always pay for shipping – we email you a pdf that has the packing slip and pre-paid shipping label.

2)   For many categories, we even send you a box free of charge so that you can use it for shipping.

3)   We keep you informed throughout the process once we receive your gadgets.

4)   We pay you as soon as we complete the inspection. In fact, if our inspection shows your gadget to be a better condition than you had told us, we pay you the higher trade-in value, no questions asked. In the event we find the gadget is in a worse condition than you had stated, we send you a revised offer and explain the reason for the reduced offer.

5)   We give you the choice of accepting this revised offer so that we can send you the payment or if you decline and want your gadget back, we ship it back to you free of charge.

Now if you happen to live or work near our office, you can even walk in with your trade (forget about boxes and shipping labels) and we will pay you on the spot.

Now these are the things we do today. Are we done yet, hell no!. We are always looking for new ways to further improve our processes such that we can eliminate the “shipping” friction point.

We continue working on finding economical ways to reduce these “friction points” so that we can stay in business and work on our vision to “change the way consumers consume.” When we still have a vast majority of electronic gadgets ending up in landfills and polluting the environment, we at Gazelle know that we still have a lot of work to do.

As product managers, it is important for us to realize that unless we reduce our customer’s friction points of doing business with us, we are not going to be successful. And the friction points may not always be related to the product, but it maybe within the ecosystem of your product – whether it is customer support, documentation, order management, sales support etc.

Thoughts? What are your customer’s friction points and what are you doing to solve them?

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.

Image: Courtesy of carfullofpandas.com

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?