Tag Archives: offshore product manager

A Program Manager Can Be More Powerful Than A Product Manager

The title of this post may seem illogical to some. After all, the Product Manager (PM) is the one that leads product releases and is often responsible for product P&L (profit and loss). And a program manager (pm) simply tracks activities in MS Project. So how can a pm be more important than a PM?

I first heard this from a Director of Engineering at Microsoft, Seattle. He explained that in consumer products, it is very important to get the pulse of the market, and hence everyone listens when the PM talks about features, use cases, revenues, competitors etc. Whereas in enterprise products, there is often a vast pool of resources to manage that work to deliver a single product release on time and within budget. Hence the teams of pm become very important to the product line. And since they have fewer releases per year of enterprise products, the program manager has a more significant role to play there. Of course, the pm in Microsoft has a different role than a traditional industry pm. [ A description of MSFT program manager’s role in India is given here.]

In offshore roles in India, the prominence of the role of a pm and a PM depends on their level of independent responsibility. If either the pm or the PM’s reporting hierarchy is to the product line management (typically in the US) instead of India operations teams, then they have a strong and important role. Otherwise, given the typical scenario where you have offshore engineering centers, a pm coordinating engineering projects is sometimes more powerful than a product manager. In fact, having both product and program managers report to an Engineering Director is also not uncommon. This can occur in both consumer and enterprise software firms, and in both cases the pm can have a more prominent role than a PM.

So, if you’re researching on alternates to an operational product management role in India, a pm’s role is worth a closer look.

Advertisements

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.

7 Tips for Fresh MBAs working as Offshore Product Managers

[Caution: long post]

Today, most business schools prefer candidates with some work experience, which is also useful during lateral placements. Hence you see an increasing number of candidates with exposure to IT services or software engineering joining these schools and completing their MBA. Post-MBA, it is inevitable that some of them will head towards product management during campus placements or shortly afterwards. This post is about the 7 things to focus on in your first year on the job, apart from working on PRDs or MRDs.

1. Build a rapport with program managers

In most offshore R&D centers, program managers play a key role in organizing projects, resources and schedules. Hence they know the resource costs and availability for any ongoing or upcoming project. And since engineering dominates decision-making in ODCs (offshore development centers), the program managers help to balance the engineering dominance.

2. Get customer exposure on a sales call

An enterprise sale is a complex process, involving dozens of people from different departments, and it typically has a long completion cycle. You must gain a first hand exposure to how this works, as this is the main source of revenue for the firm and for your product line. However, it can be difficult to gain a sales person’s attention, as he is always looking outwards for opportunities. As an incentive to sales folks to get them to talk to you, arrange a product demo or a feature presentation. If the demo is interesting enough, they will make sure that you get in front of the customer.

3. Gain the trust of engineering and service delivery managers

I have written previously about key stakeholders for offshore product managers. If you cannot get these people to trust you, you will never be able to drive product decisions, even with your supervisor’s help. And you cannot keep going to him all the time. One good technique to gain the engineering trust is the show them that you can deliver on the product requirements and are not simply there because of your MBA. Essentially, you need to prove yourself with every engineering resource, right from the VP to the intern.

4. Train yourself

If you are just coming out of b-school, with a few years of pre-MBA IT experience, you have NO relevant skills whatsoever. The people in the ODC do not care that you can prepare kick-ass powerpoint. Neither are they interested in the font, color or direction of arrows in you block diagram. You must focus on gaining survival skills, which today include, UI design using HTML, CSS and Javascript, UML and MS Visio usage, basic analytics, and programming skills in at least C++, Java or PHP. There is a lot more to gaining skills in multiple dimensions, and I will cover this in a future post.

Do not bother to go for a formal product management training yet. Without relevant experience, it will have very little value and you will forget most of it very soon.

5. Prepare for a change to your role/product within 12 months

In today’s connected, global economy, it is almost guaranteed that your first role will last no more than 12 months. The change could be due to external forces or internal restructuring (ODCs are very prone to this), but it will definitely happen. In the worst case, you might feel stagnating in your role, and you will yourself ask for or start looking out for a change. The best way to survive this is to shine in front of senior management, build a rapport with the US teams and network with HR and other support staff.

6. Connect with Solution Sales, Analytics, Customer Service Teams

This is probably the most important task that you can perform outside of self-training. To understand how the product is built, you need to sit with engineering teams. To understand how the product is sold, you need to work with sales teams. And if you really want to understand how the product is used, you need to work with solution sales, analytics and operations and customer service teams, who cover all real use cases that the product was designed for. And remember, you need to proactively seek them out and learn from them. As a fresher, it is expected that you will be learning all the time.

7. Network outside the firm

There are a lot of opportunities for networking in Bangalore, Hyderabad and all the other major tech. centers in India. You must go to these get-togethers (a few of them are listed in the resources section of the blog). It can be a lonely job, working as a product manager, with no outbound teams near you. Connecting with other people in similar situations is a good way to understand the challenges of an offshore product management role, and the different ways in which people are coping.

Summing Up

A product management role, even offshore, can be incredibly rewarding, but only if you take care of your first few years on the job. It is not for everyone, and you should make sure that you are still interested in it at the end of your first year. Else, as an MBA, it will be easy to find something else.

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

Agile and Accountability: 7 Things to Get Right

Very often, Agile is presented as the panacea for delayed releases, disconnect between the business and technology teams and the slow pace and long release cycle of the waterfall method. Well, Agile is simply a process to develop software, with its own positives and negatives. A process by itself can never be perfect, and with human involvement, there is a high likelihood that the new method will also fail, although in different ways from the old software development methods.

In this post, I would like to describe the key challenges that a product manager must watch out for, when he

  1. Joins a team following the Agile methodology and Scrums for software releases
  2. Joins a team that is transitioning from Waterfall to Agile

The information here is useful for both offshore enterprise and consumer product managers.

1. The very first thing he must ensure is that all requirements are clearly defined and documented. When something goes wrong, or the engineering output is not satisfactory, the first thing to do is blame the quality of requirements. My advice would be to never change requirements even if a customer demands a feature enhancement. You can always add it to the backlog, instead of disrupting the existing backlog.

2. The next important thing is to make sure that all processes are clearly defined and documented. If the team is transitioning from Waterfall to Agile, the program manager must remain available until at least 2-3 sprints are completed. It is also vital to make sure that a Scrum Master is designated to track the team progress. The Scrum Master must not report to the engineering manager. Weekly sprints must reach their sprint goals.

3. Make sure that QA is independently accountable, and is testing the weekly output both for new use cases as well as regression testing for existing features. One team I came across had QA also reporting to the same engineering manager. Needless to say, either bugs were not reported or were immediately reduced in priority.

4.  Make sure that the non-functional requirements are adhered too. A common excuse I have heard is that since this is the first version of the use case implementation, we will improve performance later. Well, no client is going to wait for a half-baked feature, and releasing that feature will only cause high priority customer escalations, reducing sprint velocity and causing a cascading effect on other features.

5. At least 20-25% of the development time of the engineering team should be spent on defect resolution. In fact, one sprint out of 4 or 5 can be an exclusive bug-fixing one. This will ensure a reasonable product quality after a while.

6. Make sure that the effort estimations do not vary from week to week. This is the most common trick employed by engineering managers to prioritize features that they want to build, and change the product backlog priorities. There is no easy solution for this, but if you closely track the past performance of each engineer (yes, YOU have to do it, with the help of the scrum master) you can get a good idea of the real vs. claimed effort estimates.

7. Finally, do not hesitate to call out the engineering manager if you see the product drifting, the quality being lowered, or the performance not up to the mark. He will blame someone from his team, perhaps even fire someone to make an example of him, but ultimately, each engineer is accountable for his output. And he is accountable for managing them. If required, escalate to the engineering leadership and make them aware of the release delays. In addition, if you keep your own leadership informed too, then client escalations will not cause too many disruptions.

One final thing, there are never as many engineers of sufficient quality as desired. And recruitment remains a constant struggle in the product development world. It is not your job to manage this constraint. And yeah, the old story of tripling the engineering estimates to plan a future release date makes a lot of sense in India.

There are dozens of tricks and pitfalls to watch out for, when Agile is proposed as a software release process. This post mentions a few, but the key to on-time, in-quality releases remains close tracking of the progress made by the team against the defined requirements.

E-Book Review: Strategic Role of Product Management

Book SRPM

What is it About?
This is a short e-book by Pragmatic Marketing about the strategic value of a good product management team to any technology organization.

Who should read it?
It is a good read for PMs who are not sure of the tasks they handle in their company. It offers compelling arguments for the strategic nature of product management activities. It also clearly distinguishes the roles of sales, marketing, finance and product management in the technology organization. It should be circulated among the senior management staff in offshore R&D centers to make them comfortable with the role of product managers.

Key Takeaways

  • Product Managers understand and try to fulfill market needs, not customer, engineering, finance or sales needs
  • The Product Management team has a variety of tasks, and product marketing, product line managers and technical product managers can co-exist within the same team, working on different aspects of the product portfolio
  • Product Management is a strategic role, and PMs should not report to engineering or other functions, but directly to the CEO

What is Missing?
The e-book does not discuss the software engineering process, and the role of product owners. Agile is relegated to the task list of the technical product manager. It offers little insights into how an offshore product management role could be structured or how someone should work in that role. Finally, there is little information on how to train product managers on the flawless execution of their various tasks.

Relevance for Indian Product Managers
This is an excellent e-book to share with the organization, if you are new to the function, or if the role of product managers was introduced recently. It also evangelizes the value of product management, so getting stakeholder buy-in should be easier once they read it. Finally, if you are in offshore product management (enterprise or consumer) you can expect only the role of technical product manager to be relevant to your work.

Final Thoughts
Read the e-book, share it with everyone whom you are trying to influence, and learn from the examples given in it. Attend the training that they organize, if it happens in India.

Hiring Slowdown in India

A quick look at the number of job ads on popular sites such as shine.com, monsterindia.com and naukri.com will show the obvious. There has been a marked hiring slowdown in this quarter. So what could be the causes of this slowdown?

For sure, the following macro factors have had an impact:

a. Slow Recovery in the US

Most offshore R&D centers have slowed down or put off hiring in India, as their parent firm is itself cautious about spending money. This has affected the hiring for posts of product managers in India apart from the regular engineering roles.

b. Slowdown in Indian Market

Thanks to the awesome policies and the wonderful government here, there is neither growth in industrial investment (apart from some core sectors) nor in consumption (due to uncertainties and price hikes). Overall the job market is usually lacklustre in the 4th quarter, but this year things have been worse than usual

c. “Bring Jobs Back” movement in the US, after Obama reelection

This has definitely changed the number of high-end jobs (read: PM roles) that R&D centers in India could offer. In fact, the “value of outsourcing to India” debate has again begun in earnest.

d. Disinterested VCs funding new technology ventures in India

After a funding frenzy in the beginning of 2011, all major VCs have either shifted their focus from technology, social media and consumer web to enterprise software and other sectors. This has had an impact on the startups who managed to get angel funding but could not get a term sheet approved.

Thanks to these factors, all 4 types of product managers are significantly impacted, with little opportunity for lateral movement or growth. I know of several people who had to take a pay cut and do low quality work, simply to show continuity in their résumé.

Thoughts, comments?