Category Archives: True Stories

Share Your Story

If you have interviewed for, or worked as a product manager in the technology industry in India, and would like to use this blog to share your stories or experiences, drop me a mail. I will be happy to include guest posts on this blog, if these posts are related to recruitment/interviews/compensation, workplace stories or challenges faced or another relevant topic.

You can also follow me on twitter @desiprodmgr and tweet your interest in guest posts there.

True Story – “We Intend to Hire”

A well-known e-commerce/internet firm based in North India contacted an ex-colleague in the last quarter of 2014. He works as a product manager in an offshore setup, is very well versed in technology and business management and is originally from North India.

The recruiter first asked if he is willing to move to the NCR region. My friend said that for family reasons he is only looking at opportunities in Bangalore. The recruiter then said that they are establishing an engineering center in Bangalore and that he would only be interviewed for roles in Bangalore. The recruiter asked for his résumé, salary, current designation and a brief description of his current responsibilities. In addition, he was asked about the expected salary, and he said, “It’s negotiable, depending on the package, but I am expecting a 20% hike in salary”. After providing these details, my pal asked them about the role and the next steps in the process. The recruiter mentioned “someone will get back to you” and that was the end of the discussion.

Three months later, in January, a well-known head-hunting firm reached out to him for a role in the same e-commerce firm. When asked about expected salary, he gave the same answer as before. After providing all details, he asked if the role was for NCR or Bangalore. The head-hunter replied that they are actively recruiting product managers for Bangalore and he would only be interviewed for Bangalore. After this call, nothing further happened in the process.

Last week, another recruiter from the same e-commerce firm called him after viewing his profile on LinkedIn. This time, my pal said that he is willing to relocate to NCR if required, although he prefers Bangalore. The recruiter then said that we only have product management positions in NCR at this time but “we intend to recruit” product managers for Bangalore in future. He also said that the Bangalore center is yet to take off. After hearing this, he decided to look elsewhere for a job.

Lesson learnt!

[To avoid such situations you must try to identify the hiring manager at the earliest]

Product Manager Recruitment in India is in Trouble

Some issues which I came across, and have posted about before:

  • Candidates barely get to speak to hiring managers during the recruitment process. A colleague mentioned how he was interviewed by a solution architect and the HR manager for a PM role in an IT services firm.
  • You are likely to find a “young inexperienced star” running the product function in many startups today, who then looks for senior, experienced folks to report to him.
  • Hiring managers in most startups are unable to understand the job needs and make generic job specification (very common across e-commerce websites).
  • Resumes are so filled with jargon that they give no sign of a candidates skills, capabilities or achievements.
  • 90-95% of applications on job portals may not be viewed by a human.
  • PM training is reduced to a few certifications or some short term courses.
  • Promoting from within (along with limited PM training) is reducing the firm’s ability to actually deliver great products.
  • Recruitment teams are not able to filter good candidates, which is why candidates should start networking with anyone at the firm who can promote their application.
  • Many business analysts or solution architects are positioning themselves as product managers, without having the necessary skills to do a good job.

More to follow

Product Management Merry Go Round!

Musical ChairsSeveral years ago, when engineering hiring in dot-coms was peaking, you could see the same resumes making the rounds in top firms (Microsoft, Google, Ebay, Amazon and others) in India’s Silicon Valley.

Some years back, there was a great article in Forbes India that mentioned how the Top Honchos of Tech. MNCs in India keep rotating between the same firms, which led to limited value addition to these firms.

Now it seems product managers resumes are making the rounds in the same way. Many recruiters with such firms are pinging folks on LinkedIn with product manager designations, to fill vacancies in their organizations.

Here’s a true story of what happened with me.

A few months ago, I got a mail from a recruiter at a well-funded startup, offering a product management role. The profile was interesting, with a mix of product design and analytics for a cloud based offering, but it was an entry-level role so I replied back declining the offer to interview with them.

The next day, I got another email, which had the email ids of about 20 product managers from Amazon, Myntra, Ebay, Infoedge, Intuit, Microsoft, Walmart Labs, Flipkart etc. (My guess is that the recruiter wanted to bcc all of us, but messed up).

It said that the recruiter was happy to have made contact with us, and wanted us to refer folks from our companies if we were not directly interested in working in that product management role. Being curious, I looked at the profile for these folks copied on the mail with me. It became clear that most of these folks had:

1) B. Tech. or MBA from a Top College (IIT/NIT/ISB/IIM)

2) Worked in at least 2-3 different product management roles before their current one

3) Rotated between an MNC and a startup in their career, or between different MNCs

4) done at least one stint in a client facing role (marketing/sales/business development) or worked in the US

My guess is that many offshore MNC with a product manager opening will ping these same folks for the PM role (unless internal candidates are available). This may also indicate why many folks are unable to get a PM role in India, if they have not done it before. Finally, my guess is that these firms are also compensating PMs at similar levels which makes hiring easier.

The merits of this hiring strategy are debatable, but let’s leave that for another post.

5 Reasons Why Engineering Teams Say “No”

As a product manager, you should be used to hearing “NO” from every stakeholder, including the engineering teams. Of course, if you are talking to a vendor, or an IT services firm, you face the other challenge of hearing a “YES” for everything.

With engineering teams, sometimes there is a hidden reason behind their refusal of a product/feature concept. Here are 5 reasons why PMs I know were not able to push through product requirements.

1. It’s Not Cool Enough

In the web world, certain technologies and features are considered cool. Others are not. So if you have a strong engineering team, they may simply nix the basic features such as logging, event viewer etc. in favor of features such as cross-domain APIs, “social” features etc. The trick is to keep a judicious balance in every feature review. And in case that’s not possible, just promise them that the “cool” features are coming down the road. And be careful about the ever-present “code conversion” projects where they want to migrate the code from HTML 4 to HTML5 and introduce SVG viewer and other features. Unless there is a business need or a strong performance reason, the “coolness factor” could be lurking.

2. It’s Too Tough

This is what I heard from an intern who joined the team. They had worked on a matrix based hierarchical organizational of real-time data for a year, and then they gave the same project to the intern to take analyze. Additionally, this was always the project that got de-prioritized over other initiatives. By sitting with the intern for an hour, it was easy to understand that this was an NP-complete problem, and optimizations were simply too tough for our data dictionary. (Here is a description of NP-complete).

3. It’s Too Easy

I have been in teams that often said no to easy fixes. After developing the core feature, however badly, nobody wants to simply fix all the bugs or add the security requirements. Again, the workaround is to offer a bundle of features, where they cannot pick and choose. By the way, these are the features that will slip the most in an early release, as they are deemed “non-core” features. Usually, the web-based GUI often falls in this bucket.

4. We Do Not Know That Technology

No true engineering team will agree to this, but this is also another hidden reason why teams say no. In one instance, the team had no idea of the internals of Oracle’s 11g release, so they simply delayed releasing a plug-in based on that. After several weeks of waiting and testing alternates, and with shipping of the core product getting delayed, this is the actual reason that came out during a hallway discussion with an engineer. The solution was to drop the plug-in and release the product.

5. If I Agree To This, I Will Look Weak

This is one of my favorites. Engineering managers in world-class organizations have a top educational background, have often won awards for their work and are viewed as stars. So if a great PM comes along with a perfect PRD, and has all the right features dictated by competitive needs, market analysis and user requirements, the engineering manager will simply say no to many features to satisfy his ego. (I do not know of any way to solve this problem, except to avoid entering such situations.)

As I have blogged about before, this is not about the quality of the PRD, but about saving face. The same feature set might be picked up later, after the PM has moved on.

True Stories: When Engineering Dominates Product Design

Sometime back, Slideshare decided to move from Flash to HTML5. As a PM, I would definitely support this decision if the cost-benefit analysis proved it (and Slideshare agreed with this), and this extended my product’s life-cycle. If this necessitates re-work, then that is the cost of product improvement, and must be accepted. However, if such a decision is taken because HTML5 is “cool” and Adobe Flash is “not cool”, then no self-respecting product manager should support it.

Here are 2 true stories (somewhat modified to hide identities), that illustrate incorrect design decisions.

I – The Perfect Design

A friendly neighborhood product manager narrated this to me a while back (If you’re in Bangalore, there are product managers in every neighborhood). He had joined a crack engineering team working on web technologies. Their mandate was to develop a high-performance, ad-publishing service for e-commerce websites. While he analyzed competing solutions and worked on a detailed PRD, the engineering team decided not to wait, and started building out a complex, computer science Artificial Intelligence (AI) model in a solution.

Six months later, the software was ready and the team started releasing it for various websites. Unfortunately, severe bugs kept cropping up in deployment, over different product components, which meant that a major re-design was probably necessary. After a lot of back and forth, where the PM was overruled, the team decided to keep their AI model, and started developing AI model version 2. After another three months, that too turned out to be too complex for high-traffic websites. In a bizarre twist, the team decided that the PM was not “technical enough”, and they wanted to promote someone from the engineering team as the PM.

Once the new PM came into the picture, he opened the PRD written by the former PM. The team abandoned the AI model version 2 and rebuilt the product based on competitors’ designs deployed on real websites.

Epilogue: The product was released a full year late, and has few real world deployments. While it has a smaller feature set than its competitors, it’s still shown as the “crowning achievement” of the engineering team in India. The former PM now works for an e-commerce site in the US.

II – The Immature Team Leader

In large Offshore Development Centres (OSDC) several engineering projects are incubated under the “20% Time” theory, popularized by Google engineering teams. These projects can often yield useful results, but many are not worth commercializing, especially if you are in the enterprise software business which is aligned towards solutions now.

Out of one such project, a team leader created a “secure web communication service”. He was feted for this effort, promoted and moved into product management. After he left, the team tried to advance the product into a usable form. They found that it:

  • supported only 6-10% of targeted throughput
  • did not support any browser except Firefox 3,4 and IE 7
  • had massive memory leaks, was crash-prone and hard to debug
  • used up enormous CPU time on the client side

Apparently, all this was suspected when the team leader was developing the product/service. However, as he was a “rising star” and favored by an engineering VP, everyone looked the other way and QA signed off quietly.

A year later, the product was discarded and replaced by a 3rd party product, purchased under a commercial re-use agreement, negotiated by the same PM’s manager!

Conclusion

There are countless opportunities for bright engineers in India to build products. However, the “code” is just a small part of the product, and if you have a bad design or software architecture, no amount of coding will make the product perform as expected. In India, the “development process” is often prioritized over rational decision making, which makes it impossible for the product manager to do his job (make a product succeed in the market over its life-cycle).

“Are You Really A Product Manager?”

Background

Over the years, I have faced many product management interviews with all sorts of firms. A few of these have been with entrepreneurs in India who have launched multiple businesses and have been the CEO of their own firm for more than 10 years. In my experience they are some of the shrewdest people I have interviewed with, and they have a really good grasp of what skills and talent they need in a candidate.

The Incident

This happened during a discussion with a CEO in 2012, who runs an enterprise software firm with clients in the US, EU and APAC regions. The job advertised was for an enterprise software product manager.

As is usual, the interview start with the standard “tell me about yourself”. I gave a summary of my career so far, with details about my work in different roles and the related tasks and initiatives. During my description, I could see him adopting a quizzical look. So once I finished my narrative, I waited for him to take the lead and ask some questions about my background. I was taken aback when he said (paraphrasing here), “the work you have done sounds wonderful, but are you really a product manager?”

headscratcherI was flummoxed, and did not understand why he asked this. I have worked in product management with 2 large enterprise software firms, and that is the relevant part of my work life which I had described to him in the past few minutes. I asked him to explain what he meant, and he said that while the work of building products is important, what is also important is the amount of time spent with sales, pre-sales, account management, clients, prospects, marketing and all outward facing teams. And this is what I had glossed over (according to him).

Now the reason I did that is because the role advertised was for an inbound product manager, and there is little to connect what he wanted to hear and what I was to be hired for. I explained to him that I have done every product management task in my earlier roles (including the rarity in India, product pricing) and since he has a vacancy in an inbound role, that is what I spoke about.

He clarified that hee was really not interested in what I had to contribute on product design and engineering, and his main concern was “Can you manage the pricing, packaging and promotion of the product successfully?”. He wanted someone who could work with anyone in his organization, to get the product “out of the door”. In his mind, those are the traditional success metrics in any product management role. And that is what he wanted to hear about. Needless to say, I did not see a way to bridge this expectation gap, and did not get the job.

Traditionally, this is how senior management uses product managers, especially for enterprise products, and if you only have offshore product management experience you will probably never fit into one of these India headquartered organizations. So unless you have exposure to outbound activities as well, you will remain a one-dimensional product manager, with little possibility of getting a job in an India based startup. This career shift is important, as it is the a surefire way to get a leadership role in the technology industry.

So think about your own career, and ask yourself, “Are you really a product manager?“.