Happy New Year 2019

Happy New Year to everyone.
Last year saw a lot of changes in the Indian product space. If you have been following the news sites, you will know about many of them.

Some big highlights from the e-commerce space
  • The government has finally tightened norms on various practices followed by e-commerce firms.
  • Multi-billion dollar valued Ola has actually invested in another mobility startup Vogo. This is surprising considering that Ola is actually large enough and capable enough to launch their own business unit in this space.
  • And the online delivery space has seen a lot of action from investors, which included Swiggy's $1 billion funding.
Accordingly, hiring in the technology industry has also picked up, with a lot of movement at both senior and junior levels. Bangalore remains a perennial favorite, but Pune, Hyderabad and Gurgaon are not far behind when it comes to people's preferences.

In addition, the B2B software space has finally matured, with a lot of new firms focusing only on the cloud based services, for all departments in an enterprise, from finance to sales to marketing to HR and customer service. It is not difficult to find many new ventures or existing firms that have done well in this space. And I cannot recall many firms that are still doing packaged on-premise software for clients.

The consumer internet space has also exploded, there are a lot of exciting new ventures. These startups are exploring business models, technologies (IoT, Blockchain, Gaming, Reality TV) delivery mechanisms (app only) without losing the focus from a scalable revenue model. India has become an exciting destination for new ventures and finally there is some focus on innovation as well, rather than the traditional IT outsourcing (which has also matured significantly).

Here's hoping for a fantastic 2019!!

Engaging the Cloud Organization for Successful B2B Application Delivery

[In this post, I identify various cloud stakeholders vital for successful application deployments]

A product manager/owner is typically responsible for the functional specifications developed by the engineering teams. However, for cloud deployments, one should also consider the non-functional requirements (scale, security, data confidentiality & isolation etc.) that can impact the use cases offered, as well as the business, financial and legal requirements of offering the product and services in different environments globally.

For an organization running its own cloud operations, there will be someone covering the following functions:
  • Cloud architecture (the people who define what containers, servers and API contracts are available for any application)
  • Cloud ops (the team that runs the cloud, including storage, network and compute)
  • Cloud security (the team that defines the standardized security offered within the cloud)
  • Cloud application support (the team that interacts with customers and users who face problems)
  • Cloud delivery (the team that configures multiple applications within the cloud for a specific enterprise customer)
  • App customization and development (the team that creates plug-ins, extensions and enhancements specific to a customer)
  • App integration (the team that makes sure data flow is managed as per requirements and for compliance needs, between various applications)

Sometimes the last 3 capabilities may be covered by service delivery teams via paid engagements. And in smaller firms, these teams can be outsourced, distributed or merged with other cloud teams.

For the success of your application, it is important to make sure that these customer-facing and operational teams are successful in their tasks. So apart from regular engineering interactions, you may also have to allocate time and resources to engage these stakeholders.

Always keep the following points in mind:
  1. These cloud teams are supporting your application, and there is a symbiotic relationship between development and cloud teams. Do not underestimate their significance.
  2. Application architecture is very different from cloud-based deployment architecture. Listen to your cloud architects and mediate between architect teams as required. If the cloud supports multiple products, your cloud architects may rule.
  3. If you have a team of product owners reporting to you, keep at least one PO focused on cloud platform requirements. From time to time, these requirements can impact your backlog, leading to delays in delivery.
  4. Keep demoing your application to all these stakeholders. Sometimes it can be via hands-on access in a sandbox, but you can also hold a brown bag session to explain new features or enhancements.
  5. Whenever possible, keep sharing customer feedback with the cloud teams. With their focus on ops, up-time, performance etc. they sometimes miss the point of why the cloud exists in the first place.

Building A Product Timeline - Useful slides available for download

As a product manager, you will have to make presentations that indicate timelines, progress, status, resource utilization etc. Unless your firm has a standardized template for these, making such slides gets tiresome.

While there is never a perfect timeline slide for all occasions, I have created the attached template, that can be useful on many occasions. There are 3 slides in this template, that can be used in different ways. Feel free to modify or use them in any way. Tip: The long term monthly slide is useful for communicating with senior management, to show the big picture.

Annual slide with months

This slide is useful when you want to show a long term roadmap with key milestones called out. This is typically used for marketing, or for summary presentations to senior management. For example, you can use this slide to show when the product concept will be defined, engineering specs delivered, marketing tasks completed and the new version released over 18 months. If you want to add more details, then you would add rows indicating different people or departments where these milestones will occur.

Monthly slide with weeks

Sometimes, you have to show the weekly progress being made towards internal milestones. This slide is typically used when you want to show when each feature is being released. The attached slide shows a timeline over 3 months, and is formatted for the 52 week calendar year. Again, if you want to provide more details, add rows of data for the audience.

Daily progress in a month

This slide is useful for showing tasks to be completed within a month. You can show each day, and exclude weekdays, while indicating when each task is to be completed, using icons from slide1. I have used such slides to show the cross-functional deliverables for a product, when there is a tight deadline to be met. Apart from this, you can also color holidays or internal "dead" days.

So will you ever use all these slides in a single presentation? Unlikely, as these are meant for different audience.

How is an enterprise software product planned, designed, built and released?

For a large software vendor, there are several processes and departments that work together to create a product that can license for hundreds of thousands of dollars. This takes a lot of planning, time and effort across multiple functions.

In addition, there can be delays and risks in developing such software.

PLM software is available in the manufacturing domain, from vendors such as Siemens, Oracle, Autodesk and many others. These describe how different functions and processes are used to release products and support customers.

One such PLM diagram that I created is shown below.  Each department in a firm is shown as a swim lane. And there are different product life cycle phases that run from left to right over time.
The flowchart depicts the different activities that occur within the cycle, and the different checkpoints that occur.

You can observe the complexity that a product manager for enterprise software handles, compared to what the simplified role of a product (feature?) manager is in the e-commerce or web world.
PLM for software

More to follow.

Evangelize product management to stakeholders

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 (especially someone working in India). And these stakeholders have been from engineering, sales, field marketing, program management and many other teams. So a lot of time  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. Note: I am not in favor of sending email blasts, unless most of your stakeholders are not in the same location.

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. He wants information on what are the technologies of focus, what are the skills his team needs and so on. 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. He is looking for something to sell to the account. So you should focus on only the business value of your 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. Typically, such stakeholders include C-level leadership, who really need convincing on why someone 10,000 miles away is useful to them.

3) Sell the role

If you meet a skeptic, then the best option is to offer examples and success stories about the benefit of having a product manager in their midst. For example, if the company is facing pricing pressures, then show, with examples, how product managers can create pricing strategies and the impact on margins.
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. He is also expected to be the key expert on customer needs. If you have something unique that you can share, then you must do so. 
I remember a time when I was asked by engineering, 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 outline of a high level PRD. This gave that team the comfort that I am capable of doing the work, even though I have an MBA from IIM Ahmedabad. 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.

Ask Me Anything - Within Reason

It is always great to hear from people who read this blog and have responded over email or comments. Sometimes you use real identities, other times it's an alias. I am fine with both. If your questions are interesting or within context, I will try to respond back quickly.

However, if possible, kindly provide more details before asking for for my opinion on questions such as:
  • How do I get more competitive compensation? (You need to share what you earn now and how you got there)
  • How do I get into product management? (What do you do today and what is your educational background)
  • How do I crack product management interviews? (There are hundreds of resources out there on this topic)
  • How do I grow in my career? (You need to provide your career and current job details)
  • I want to return from US and into a product management role in an offshore setup ( This is a mix of #2 and #4)
I try to answer most questions, but without details, you may not get a good response.
All the best in your career, and I look forward to answering more such questions.
For compensation benchmarks or past interviews at large firms, Glassdoor.com has pretty good information.

Role Overlap: Business Analyst and Product Manager

The number of business analyst is growing within the product management organization. In addition, there is significant overlap between the role of offshore enterprise product manager and the IT Business Analyst. So does it mean that a product manager is simply a glorified business analyst?
Not at all.
A product manager has skills along multiple dimensions, business analysis being one of them. So you can actually think that the activities of a business analyst are a sub-set of the activities that a product manager undertakes. Additionally, the business analysts usually have strong domain knowledge as well as software development knowledge and strong customer interaction skills. This should and indeed does, make them valuable as market facing product managers. And there is a natural career growth towards product management.


Unfortunately, in India today, if a business analyst wants to move to the role of an enterprise product manager, he could encounter strong resistance from various teams.

The top reason for this resistance is the idea of Technology Products development being superior to IT Services. A Business Analyst is seen as supporting IT services and custom application development and is not expected to "cope with" the challenges of product management. This bias eliminates the résumé of even the most competent BAs right at the recruitment stage.

After recruitment, the BA faces the challenge of adapting from a structured, process driven IT services firm to the "chaotic", agile world of software R&D centers. This is a transition that many BAs fail to make, and prefer to return to the world of IT services and custom application development.

Finally, the BA also faces the challenge of learning multiple dimensions of product management, such as sales and marketing support, pricing, UX design, analytics and many others, which he may not have touched before. This is the last competency hurdle that causes many of them to either avoid the transition to product management or often fail in the new role.

If a BA can successfully overcome these challenges, then it becomes easy to succeed in product management, and can offer a very enriching and lucrative career.

Phone interviews can rejected valid candidates due to 7 reasons

In India, a common and costly mistake by the recruiting team in MNC R&D centers or Indian firm is arranging a candidate's phone interview with a peer product manager. This is seen as the first bar to clear, before a full day interview is arranged with multiple people.

The common issue with this process is that it does not account for an interviewer's bias, which often leads to rejection of a perfectly valid candidate. 7 common pitfalls that hamper phone interviews include:
  • Short listing candidates from the same school or former employer as the interviewer, while rejecting others
  • Rejection of a brilliant candidate due to fear of competition 
  • Misuse of informal networking to pre-judge the candidate in his current role
  • Rejecting candidates because the panelist is not trained properly
  • Rejecting candidates not referred by existing employees
  • Rejecting candidate referred to by existing employees
  • The interview is just a formality to complete the process, candidate’s resume is already rejected by the hiring manager
There are more, but if you have experienced rejection in PM phone interviews, you are not alone. Many fully qualified candidates continue to get rejected for inane reasons.