Category: product management

It has been a while since I have been in blogging and a lot has happened in the world during that timeframe. My idol Steve Jobs has passed, iPhone 4S is out, Gaddafi is dead, Greece has been in turmoil sending the financial markets on a dizzing roller coaster and the list could go on.

After Steve Jobs death, I have gone through many of his well known presentations of introducing the iPhone and the iPad and many other videos available on Youtube. There have been two videos that are my favorites – one of them is where he speaks about “Focus is about saying NO”. 3 minutes of your life spent watching it would be worthwhile. Watch it once, watch it twice, watch it until you keep repeating “Focus is about saying NO”.

As software product managers, every one of us is faced with the hundreds of things we could do and what others in the company want to do. But what will allow us to succeed is not by building something that does a half assed job for everyone (you will hear this being argued for under the name of flexibility) but by focusing on building something that does a kick ass job doing a few things very well. To do this however, you need organizational support – it needs to come all the way from the top – the CEO.

Thoughts? Do you agree? What have your experiences been?

In an organization, where should product management report to? Sales? Marketing? Engineering? CEO? Customer Support? All of this is possible but where can it be the most effective?

Before we answer this question, let us make sure we are aligned on the role of a product manager.

In my opinion, the best spot for product management is to have it report directly to the CEO. Product is one of the most important functions in an organization because getting the right product/market fit is what brings in the revenues. So I would argue that this needs to be have a direct line to the CEO so that it is not only looked upon as a strategic function but also that it is held accountable for the company results.

Is there a second best place for product management? Every successful organization that I have worked for (B2B or B2C) has had product management report to Marketing. Marketing naturally is an external facing function that is responsible for identifying the target market, figuring out the product positioning and figuring out what will make prospects buy. There is a slight danger here of product management becoming “marketing” driven than “market” driven, but I think with the right leadership this can be avoided.

The slides shown below are my opinions on why it should not report into sales or engineering or customer support.

Would love to hear your thoughts on this via comments. Do you agree?

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.

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

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.

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.

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

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)

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!

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

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.

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

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.

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.

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 – 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?

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.

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.

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.