AMA: Oracle Cloud Infrastructure Director of Product Management, Devika Nair on Technical Product Management

Two constant challenges for me in any product role has been finding the right way to say no. This could be to your customers asking for a particular feature or your organization that has decided to prioritize certain aspects differently. The best way to overcome this challenge is by having your facts and data clear. For example, it is easy to convince leadership about your prioritization rationale if you have data to back up your claims, whether it is potential revenue or customer impact.

It is rare to have a technical product manager and another product manager working on the same product. When this happens, it is usually in organizations where one of the product managers work in a more inbound or engineering facing role and the other in a more outbound and customer facing role. In general, technical product managers work on technical products with tech customers while non-technical PMs might have products whose primary target customer isn't technical.

This depends on the goals of your product. In general, you want your key metrics to be aligned with what you and the organization considers the top goals of the product. For example, this might be revenue from your product, or number of other products customers use alongside your product. There would also be secondary goals like your adoption, retention and growth.

For Product Management, my general advice is to experiment with it. Try to understand your customers and market, define the product vision and work through requirements for your features. You can also go through exercises with side projects. For Project Management, I don't have personal experience, but I would say try getting hands on experience alongside your current role is the best path.

The first step to building the vision for a product or program is to ensure you have a clear understanding of the organizational goals and how your product or program fits into it. Second, have a good understanding of the market and customer. To me the most important piece when I am building the product/program vision is being clear what problems you don't want to solve or what should be out of scope. Once that is clear, use the qualitative and quantitative data at your disposal to identify what needs to be done and what direction you want to head.

To me, success of my product managers is measured based on their understanding of the product, ability to deal with partners, customers and executives and influence others. The way I would measure the same is based on their vision and roadmap documents. The product intuition can be judged from these artifacts and the execution can be seen through their interactions with team members, partners and customers. Most of the aforementioned are hard to determine or judge. An easier way to look at how they are able to successfully perform in their role is the depth of their work, understanding and data being their rationales. If a PM is able to make quick decisions and back it up with solid data, they are leading the product successfully.

If you are already working in an organization with an opportunity for such a role, that is the easiest way to transition. If not, look at how your current strengths can be used in the new role. In general, you want to show potential employers that you aren't new to all aspects of the job. For example, product (or engineering or program if those are the roles) skillset, domain knowledge and culture fit could be the top requirements for a role. If product skillset is the only one you lack, and you can show side projects/college projects were you demonstrated these skills that would help. You want to make sure you can show your domain expertise and culture fit alongside these side projects for the teams to find you the best fit for the role.

That depends on the organization. I've found that it differs based on the organization, and the impact you make on the projects. Certain organizations and leaders give more authority and control to TPMs vs EMs. That said, EMs usually have authority over the people on their team while Program and Product managers are influencing without authority. Respect doesn't come with authority, but it can help get a start if that's your way of working. 

Yes. If you are willing to transition, its simplest if there is a role in your organization. I am assuming this question was about TPM = Program Managers rather than product managers. If the question was about tech product managers, the focus should be on understanding the product and customers rather than execution.

I would not say I had a single point where I made this decision. I had the opportunity to lead a few PMs which I initially picked. I transitioned back to IC from this role a couple of times based on my interest in the product goals. My final (or I should say current since I could transition back to IC someday) decision was when I realized I was happier seeing success of my PMs than the success of the products. The slow transition helped me prepare both with the help of my mentors and advisors, and through "learn by doing". 

I've usually found that it is best to start with organizational priorities, and map the projects to the same. I've usually not been a proponent of prioritization frameworks, though I've found plenty of PMs including members of my team who find them helpful. I just don't find a one size fits all when it comes to frameworks. My usual method is to start with org priorities, including data arojnd the customer ask, additional constraints (e.g., dependencies, market timing) and create a roadmap that balances different types of projects. 

The biggest challenge for any tech product manager (or program manager) will remain your ability to influence. You need to influence members at all levels of the organization on whom you have little authority. The way to overcome this is ensuring your have a clear understanding of why your work/request is important. You would also need to ensure that the recipient finds these important and it is aligned with some goal of their own.

I don't think I've had a single surprise across my various tech product management roles. In general, I would say my most surprising aspects when I moved to a product role has been the amount of work that goes into non-engineering aspects. For example, how much influence marketing or finance can bring into the success of a product. Partnering with these organizations taught me a lot since I came from an engineering background.

If you mean technical product manager vs product manager, that depends on your technical expertise and interest towards technical products. If you mean program vs product, I don't have program manager experience. I'm only basing my response on my observations. I would say a PM cares more about ensuring the right product is being built while a program manager cares more about the execution and timelines. There are lot of other aspects (customer focus vs ability to stay organization and identify risks) but there are plenty of experts who have written about the differences between these roles, so won't go into all of them.

The best tech product managers I know have a very good understanding of their product. This includes understanding the customer needs and market. They use this knowledge to make quick, but data backed decisions about the product direction. They are also able to influence and bring along a wide range of stakeholders in order to successfully execute.

In my opinion, you can be successful in any role by not having the expertise if you recognize it and are willing to learn. The product manager is generally not the most technically advanced person on the team, but they bring in other expertise and experience to the team (e.g., customer data, market insights, etc). What has helped me is identifying key experts in the organization and leaning into them. I've usually not found a single technically "advanced" person on any of my teams. Different members of the team might have expertise in different areas. PMs with the expertise to identify these members and leveraging their knowledge can be successful in any role.

First, ensure you have the right data to backup any claims or decisions you want to make. Second, focus on the goals you want from that audience. Third is to make sure that the content is clear and crisp with the right level of detail. Occasionally, I have to re-write a document for a different audience (e.g., CEO). However, in general ensuring there is a clear summary for anyone without assumptions of previous context and the decisions (or requirements) are clearly articulated in your doc/email/presentation. Include details for anyone who might want to dig in the subsequent paragraphs or include links/appendix for anyone who might want such details.

If your question was about Tech Product Management, it is a solid understanding of the product vision and direction. A tech PM is able to be the voice of the customer in front of engineering or the voice of engineering in front of marketing. They are able to represent the best interest for the product in front of any audience.

To me, the best part of being a Product Manager is that there is no typical day. There is a mix of working with your engineering partners, talking to customers, partnering with other organizations, and sharing info with executives or dealing with escalations. A day to day also differs greatly depending on the phase of your product.

In general, you need technical product managers when the PMs need a deep technical understanding. In most cases, this is because the customers of your product are technical. PMs who aren't technical will be unable to effectively manage a product whose customers are technical folks like developers. There can be situations where your direct customer might not be tech folks, but the product is sufficiently complex and the PM needs to understand enough of the product to be effective. 

Good judgement or product instinct. Product Managers should make quick decisions with the available data. Product Managers should be able to distinguish between the asks and the true needs. In order to build a successful product, you need a good understanding of the market, the customer and potential. The second skill is willingness to do what it takes to make your product successful. The role of the PM differs vastly between organizations, but even within your org you might have to wear a UX hat one day, marketing the next day and engineering on the third day. The move towards a tech PM role depends where you start. For example, if you are an engineer, get more exposure to customers and gain more understanding of the market. Volunteer for product activities like creating your user experience, writing the product definition, etc. If you are in a non-technical role, getting a deep technical understanding of the product area is critical. 

PMs in most technical organizations work with technical teams, so the difference really stems from the customers of your product. Technical PMs typically work on technical products. Typically, your customers are a technical audience (e.g., developers) and you need to have the tech skills to communicate with them.

My approach is usually to have a initial wireframe to convey your ideas. The UX team needs to have sufficient understanding of the customer journeys and need to be involved early in the product definition/creation phase. Start with your vision document and a wireframe and spend some time discussing the details. Involve them throughout the product definition and execution phases to ensure you remain on the same page.