Tag Archives: product manager India

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

Advertisements

Is There A Dress Code for PMs?

I have seen multiple articles in various media about the dress code in different offices. An article in Esquire mentions a lot of options for formals, business casuals etc, and you can read it here. However, that is more applicable to the US and less for India. A quick search for the dress code at Infosys reveals this article. And this is more applicable to Indian offices. However, it is common to see engineers walk in wearing flip-flops and old jeans in top engineering R&D centers. Given these options, what is the dress code that one should follow as a product manager in India?

Based on my experience of various firms and sectors, even for product managers it varies from slippers and ratty t-shirts to spiffy formal suits. The dress code depends on

  • The type of firm’s business (enterprise software, telecom firm, dotcom, app development)
  • The nature of the product management role (customer facing, offshore center, market facing)
  • The closeness with customers/market
  • The occasion (external meeting, internal meeting, travel to an industry conference)

So how do the above impact the PM’s office attire?

Enterprise software and telecom firms are often huge organizations with many layers of hierarchy. Someone in middle management or a junior product manager is expected to dress smart. The smartness however, depends on the geography. Folks in the US will often be clean-shaven, wearing formal shirts and if there is a customer meeting, a tie or suit as well. And for day-to-day attire in India, formal shirt and trousers seem to work well. And this also works when people are meeting other groups within the company, or over video conferences. Not surprisingly, these are also the most common meetings a product manager attends in larger firms.

On the other hand, I have seldom come across an e-commerce product manager who even owns a suit. But in industry conferences, I have seen them occasionally wearing fresh jeans and polo shirts with clean-shaven faces. And engineers who switch to product management might also be seen in sandals and cargo shorts. From what I understand, this is perfectly acceptable in such firms or startups.

And there is a rare product management director who will not be seen in a t-shirt with his company’s logo. As I understand, this is them trying to look cool on Fridays.

As a product manager, there are many things to look out for, when working in India. Suitably dressing up for the workplace will enhance your presence and positively impact your abilities to influence others.

[The rule of thumb is to dress as your director or manager does. It makes life a little easier. In case they are of the opposite sex, look for other folks at their seniority level within the firm.]

10 Reasons why “MBA preferred” appears in Product Manager recruitment ads

10. The recruitment team wants to shortlist candidates from thousands of applicants for an entry-level role, and MBA/PMP is chosen as a criterion. This is fairly common in large firms.

9. The Product Manager is actually required to have business modeling/statistical analysis or product pricing/marketing skills. This is very rarely needed in India, for both offshore roles and for Indian market facing roles.

8. The “MBA preferred” lets the recruitment team decline internal applicants who want to move out of an engineering role into product management.

7. The head of product management/hiring manager has an MBA

6. This product management role reports to the local sales head, and it is actually a category/brand management role for India/Asia-Pacific. Such roles are quite prevalent in hardware/mobile firms.

5. The role requires the product manager to work with vendors/clients/account teams etc. based in India, and a person with an MBA might have an edge in relationship building and management, as per the hiring manager.

4. The ad wants applicants with a full-time MBA from a top business school, but the recruitment team was not sure if they would actually get many applicants. This is often the case with senior level positions.

3. The PM head wants a “business oriented” product manager, even though the role is actually completely engineering facing, and requires strong domain knowledge. This often happens in offshore R&D centers, and often leads to a bad hire.

2. The “MBA preferred” can be interpreted as a code for highly paid candidates to apply for the job.

1. (My favorite) The ad was copied from a standard template and it contained the words “MBA preferred” in the original ad.

Fashionable Feature Sets

In technology product management, it is easy to get tempted by the fashionable trends of the season. Today it is features related to “Big Data“, earlier it was “Web 2.0 Features or SLATES” and the latest trend is to add mobility features and access to your offering.

When such buzzwords become commonplace, the products promoted using this terminology during sales pitches or marketing events also gain credibility in the eyes of the layman. However, the product manager should not be swayed by these fashionable feature sets. It is always the buying customer and his product reviews that are the key to gaining marketshare and increasing revenue.

Fundamentally, nothing has really changed. As a product manager, your vision and roadmap will contain features that are useful to woo customers to try, buy and keep using your products. And these features are either going to give you a competitive edge, retain existing customers, or attract users who are not yet using the products.

If these reasons attracted you to these fashionable features(and of course, the side benefits of tempting developers to build them out and of influencing senior management on thought leadership), then consider this blog post, that talks about the diffusion of innovation, and product adoption. I will leave you to understand the implications, but the key takeaways from this include:

a) Adoption rates of most consumer technologies in this century follow a similar curve

b) There is a real adoption chasm that exists in most product categories, beware that your product does not fall in that chasm

b) Innovative features take time to identify, design and develop

FashionSo how can you cater to the fashion sense of the day, and still follow the established strategic principles? That requires building consensus, and having a market research driven approach to identifying the best features for the various consumer or user segments.

In fact, gaining consensus on the product roadmap is a vital activity, and it takes a lot of time. I will address this in a future post.

Web Product Management and JavaScript

If you ask any product manager at a web firm if he does coding, he will respond with a firm “NO”. Then ask him what his work consists of, and he will explain about¬† use cases, features, experiments and other common responsibilities. At this point, you should ask him if he knows JavaScript and/or HTML and CSS. 90% of web product managers, whether in local market roles or offshore roles, will respond with a “YES”.

Today, it is almost mandatory for web product managers to have knowledge of web software development. And this knowledge is necessary not for software development, but for meaningful conversations about architecture, design and deliverables with the software team. [It helps a lot if you can speak their language!] One of the key components of this lingo is JavaScript, which is surprisingly easy to learn and fairly difficult to master.

In my opinion, JavaScript and Java and 2 programming paradigms similar to RISC and CISC microprocessor architectures. In earlier times, CISC dominated and it required a strong mastery over the instruction set, to construct good quality programs. Later, RISC (and parallel processing in multi-core microprocessors) made life easier for not-so-skilled programmers to churn out software. However, to build really good programs for RISC chips, you still need to learn a lot of “other” constructs apart from the chip’s instruction set. These other constructs are similar to the vast amount of libraries for JavaScript, which make life easier for a master programmer, but difficult for a product manager, if he wants to master coding. Even then, this is far simpler than the hundreds of patterns, libraries and classes that you will need to work on for many years to become a master at Java programming.

More formally, JavaScript is a client-side scripting language, which can be learnt quickly, and will definitely set you apart from the “non-techie” product managers. There are several tutorials that explain the syntax (Hello World!, decisions, loops etc) of JavaScript, and after that, it is just a matter of practising these learnings. Of course, you must have a basic knowledge of software development to fully “speak Javascript”.

So how does this help you as a product manager? As I mentioned before, it is useful in 3 scenarios:

1) Prototyping

No matter which prototyping tool you learn to use, a mockup will rarely be interactive unless you add JavaScript. HTML forms, pages and dialogs will become more clear than basic wireframes when you present the concept to the engineering team. This may even allow them to improve on your efforts during development.

2) Discussions

When your engineering team starts explaining¬† the benefits of designing “multi-threaded JavaScript objects” running parallelly versus a simple object pool, you should be very sceptical. And knowing JavaScript basics will allow you to research on the net why this could be a bad idea from a time, complexity and engineering resource point of view.

3) Career Development

While a JavaScript certification may never be a career changer, having JavaScript in your skill set, even with an MBA, will set you apart from the other product managers. It’s easy to learn, you can practice it on any laptop and use it practically when needed.

Apart from JavaScript, it is useful to learn HTML and CSS. And recently, there has been a lot of talk about “Big Data” technologies such as Hadoop, Hive, PIG etc. More on that in a later post.

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

How To Start A PRD

Background

The Product Requirements Document (PRD) and the product roadmap are the two key artifacts that a product manager must have mastery over, for success in this role. In many firms, the PRD is called something else, such as a Business Analysis Document (BAD!), Product Requirement Specifications (PRS), Marketing Requirements Specifications (MRS) and so on.

Here are a few links to articles on different websites about what a PRD should contain.

One challenge you will face is that there is no easy way to start a PRD from scratch. And you will encounter such a situation if you join a startup, or begin work on a new product, or start working in a new firm. Here are some tips that can help you start the work:

A PRD Follows A Template

The PRD for a consumer electronics product, a web-based product or a VAS product such as caller ringtones are very, very different. Still, all the PRDs follow a common template used within the organization. You should pick up the most recent template in use based on past available PRDs and start filling out the different sections within the PRD.

If you are working in a startup, a quick web search will give you many links where you can download PRD templates. Use the template as a starting point, and simply remove all sections that do not seem important. What remains will allow you to begin writing product specs.

A PRD Is A Live, Versioned Document

As you start writing use cases, functional specifications or other details about the product and product usage, you will quickly realize that this is an iterative process. So you can take 2 approaches to make a good PRD – cover it depth-first or breadth-first.

The depth-first approach is good if there are multiple product managers, or if you have an external dependency. This way you completely scope out a set of features for the engineering team to review, and then to start their work.

The breadth-first approach works best when you are not sure of the specs., and have multiple engineering teams waiting for the PRD. This way, you have something for all the teams in the first draft.

Remember, even after a PRD is reviewed, and specs are accepted after modification, you can make changes and add those to the appendix. This way, a new joinee can see the document history, and understand the product evolution.

Start With Functional Use Cases

Unless the product is a set of API for scripts on the web to use, every product will have use cases. These will include how the product is installed, how it is started, how the controls function, what are the roles of the users and so on. These are easily translated into straightforward use cases.

You should list out all these use cases, write a one line summary for each of them and then break them into functional groups (error handling, security, startup etc). These will help you build the base of the PRD.

Break Up The PRD Into Sections

One section of the PRD must cover the business problem you are solving and the potential revenue opportunity. If you have those, and the functional use cases, you are very far along on the first draft of the PRD. Additional sections that you need to write specs. for will include the performance requirements, usage constraints, security specifications, dependencies and so on. You should spend a lot of time to write these, as these are the tricky issues that can cause major problems after product release.

Make Lots Of Diagrams

Any time you feel that there is a complex use case, or a particular system component is hard to describe, make a diagram. You can make block diagrams, flow charts and navigation maps and anything else required. And you can either add them to various sections of the PRD, or keep them at the end in the appendix. Make PPTs if required and insert them in the appendix.

More Is Good

A PRD must have a lot of details about every feature, requirement and scenario. This will remove ambiguity, simplify the design process and avoid trouble down the line. Use as much detail as possible for every facet of the PRD. It is actually for this reason that many firms use 2 versions of the PRD, a smaller version in PPT format summarizing the product release for external audiences, and a detailed version in a DOCX or XLSX format for review and referral.

Forget The Competition’s Features

Sometimes, a PRD will contain comparisons with a competitor’s product or even specific features. This is a waste of time, as you are comparing a current feature set with something you team will deliver much later. Such comparisons should not enter the PRD, however, you can add a list of internet resources on the competition to the references section of the PRD.

Summary

Writing a PRD is a prestigious task for a Product Manager. Following the guidelines listed above will let you create a high-quality PRD within a few weeks, that will be acceptable to all groups, and will allow engineering to build the solution that you describe.