Tag Archives: enterprise product management

Product Manager Or Business Analyst

[In a previous post, I had mentioned the overlap between the role of a product manager and a business analyst]

Here’s a scenario, you have several years of engineering experience under your belt. You have also managed to get a part-time MBA during your career. And now your organization has moved you from engineering/dev-ops/tech. support to product management. Here is another scenario, you have been working as a business analyst in an IT services firm, and have worked for a few product development clients. And now a client in that domain has offered you a product management role.

Is it time to celebrate this awesome product management opportunity?

Well…read further. The following job features may indicate that you end up working as a business analyst.

Reporting to Another Product Manager

No brainer, if your reporting is not to senior management, in India or overseas, then only a part of the product management function is delegated to you. This aspect brings the role closer to a functional business analyst role.

Limited/No Engagement with Product Marketing

If your only engagement with product marketing is at an all-hands meeting or a town hall, then you are not engaged in any outbound product management activities. This also tilts your role towards business analysis rather than strategic product management.

No Involvement in 2-3 of the 4 P’s of Marketing

You can figure out if this is relevant to your role, and whether you are able to work on these as a product manager or a business analyst.

Engineering is your Primary (or Only) Stakeholder

If you are working as a product owner, with limited product management tasks, then that is fine. You have a well-defined role which fits into the product management hierarchy, in today’s agile world. But if you are called a product manager, and your reporting is to a Director of Engineering, and your primary stakeholders are the engineering team, then you might be working as a functional business analyst.

Your Main Work Output is a Functional Specifications Document

This is typically true in e-commerce firms or start-ups. Most product managers in such firms are actually working as business analysts, creating functional specifications, providing reports on product usability and usage. And product decisions are usually made by the senior management of these firms. Business analysts handle such activities in most enterprise software firms.

Limited Engagement with Senior Management in Business Units

Product managers play a strategic role in addition to taking care of tactical activities. If you have never presented on strategy, finance, operations, pricing, marketing plan, new product business case or another business metric to senior management, then you may be working as a business analyst.

 Note:

There is nothing wrong with the role of a business analyst. BA’s have a lot more exposure to the product and business domain than a regular product developer. The current challenge in India lies in the fact that firms require BAs and advertise for PMs, which sometimes leads  to an expectation-reality mismatch.

Evangelizing Product Management to Stakeholders – 4 Tips

In my career, I have attended a mind-boggling number of meetings where my stakeholders are absolutely clueless about the role of a product manager in India. And these stakeholders have been from engineering, sales, field marketing, program management and many other teams. So a lot of time in these meetings is then spent on explaining what a PM does and why that is useful to their team/their own goals.

[Hint: most of these guys are superbly competent in their own field, but have a very narrow view of the business, product portfolio]

 Here’s my approach towards enlightening the clueless stakeholder verbally. [Sending out introductory emails can be a blog post in itself.]

1) Identify the type of stakeholder

Without stereotyping too much, an engineering manager would have a very different personality and skill set from an account manager. So we need to identify what facet of a PM’s role he would be interested in. For e.g., if an engineering manager wants the product roadmap, he is probably looking for details on proposed features, that his team needs to prepare for. However, if an account manager wants to know about the roadmap from the PM, it is likely that he is looking for a competitive edge while positioning the product to his account. So you should focus on only that aspect of the roadmap

2) Prepare for the geographical/market context

If you are part of a new setup in India, then you may only need to mention this fact, and that you will be carrying on all existing activities and initiatives. For most stakeholders, this is enough. If you are working with remote stakeholders then be ready to do a lot of follow-up over emails and IM and meetings. I have found that those stakeholders are the hardest to influence.

3) Sell the role

If you meet a sceptic, then the best option is to offer examples and success stories about the benefit of having a product manager in their midst. The challenge here is that you might need to make space to accommodate your role, which means reducing the role of someone else. That someone else is unlikely to ever become your champion, so you need to keep a close eye on such stakeholders.

4) Sell the personality/capability

End of the day, a PM is expected to lead the virtual, cross-functional team towards successful software and hardware releases. If you have something distinct that you can share, which might help them relate to you, then you must do so. I remember a time when I was asked why I’m the right fit for the role in the first meeting. In response, I listed down multiple planned improvements for the product, and the high level PRD. This gave that team the comfort that I am capable of doing the work. Sometimes, that is all you need.

 For some people, negotiation or public speaking classes can help them increase their communication effectiveness. If these courses are available to you, do check them out.

The “One-Pager”

I first heard about this in a Microsoft team (I was working elsewhere in enterprise software at that time). The one pager was supposed to be the answer to every product teams’ planning initiative, and the composition of the one pager was given top priority by senior management as well as the product management team.

Well, when the one-pager finally arrived, it was a big letdown. It was not of one page, was really vague, and was closer to a mangled mission statement (follower’s of Dilbert will know this) than any product vision.

So what goes into a good One Pager?

A good one pager, in my opinion, should have the following 5 sections:

The Market Description

This section should give insights into the following:

  • What is the market like in terms of geography, verticals etc.?
  • What are the current solutions in the marketplace
  • Where is it heading, or what are the observed trends?

Do not spend too much time or more than a few sentences on this, as this is a very high level description of the market.

The Problem Statement

What is the exact customer problem? For online clients, it could be something like too much data, or stagnant e-commerce revenues. For enterprise customers, it could be a customer needing a “simple” and easy to use product for his IT Service Desk Management needs across all geographies.

If you know that this is common knowledge within your firm, then you can even get by with a single line problem statement, with subordinate clauses.

The Proposed Solution

This is the section that is of major interest to engineering teams and other internal stakeholders. First, clearly describe what the solution is, in a single sentence. Then use a few words to describe the different components of the solution and the benefits of each component. Finally, describe ONE usage scenario where the solution will solve the customer problem described above.

If you like, you can even fill in a few engineering details, such as the need for Open Source Web Servers, API requirements and so on. A block diagram will probably take too much space without adding value.

You can leave the remainder of the use cases to be filled out during PRD generation.

The Financial Benefit

This part causes the most heartburn in product managers who rise up from engineering ranks. They have been used to precision and results, and building financial models to predict the range of revenues and profit margins of this product over 3-5 years based on multiple assumptions can be a big challenge. My personal belief is that this stems from a lack of confidence, which can be overcome simply by practising this repeatedly.

Do not skimp on this section, and try to put as much detail around pricing, growth in customer base and quarterly revenues as possible. The lack of details around financial benefits can easily kill your vision as it moves upwards through corporate hierarchy.

The Challenges

This is an easy one. If you have an idea of the market and the customer problem then you can describe the external challenges around achieving revenue goals. And if you know how engineering will build your solution, then you can describe the internal risks.

If you have a good sense of what the competition is doing, you can write a line about it here. Although this is not recommended by most experts.

So what do you finally deliver in 5 sections, 1 page and 400-500 words?

Ideally, you deliver a “One-Pager” that is a summary of the goals of a product team, for building a new product or designing a product release. If you can actually deliver this, it will go a long way towards building confidence all around, in your capabilities as a product manager.

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.

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

The “Big 5” of Offshore R&D Centers in India

Based on some basic internet searches, it seems that India has over 1000 offshore R&D centers of various MNCs. And while these are not restricted only to IT, it is the IT R&D centers that of interest to us. So which offshore R&D centers have the most Product Managers in India and which ones offer the highest compensation? Well, these are not easy questions to answer, mainly due to the wide variety of work done by these centers. And very few of them are offering product management in India. But here are my indicative lists.

Top 5 R&D Centers by compensation offered to PMs

Top 5 R&D Centers by Product/Program Manager headcount

Top 5 Enterprise Software R&D Centers

Now the fine print:

  1. The list is completely subjective and based on personal research. I make no guarantees about its accuracy.
  2. These lists cover all product management roles ranging from P&L owners with experience of 10-15 years to business analysts fresh out of engineering/business schools.
  3. Most of these are Bangalore based with a few based out of Pune/Hyderabad/Chennai/NCR
  4. A few organizations have some product management functions in India, focused on the Indian market. I have not included them here.
  5. Microsoft has program managers in India, who do similar work as inbound product managers.
  6. Quite a few IT services firms have product management roles, however, they offer less compensation and are not included here.

Will update this post, based on the feedback I receive