Internal-tooling vs customer-facing product management (at Twilio and VMware)

I was catching up with my friend and fellow alum from UCLA Anderson, Harshal Patil (product manager at Twilio) about how work was going, and I was bemused by how different our jobs are even though we’re nearly identical on paper i.e. both engineers, MBAs, and now product managers at enterprise tech companies.

We thought this would be an interesting conversation to have and document because it highlights that product management can be so different based on team, product, company, and industry. On the other hand, we also reaffirmed that the core skills and competencies needed as a PM stay pretty much the same!

This to me drives home the point that as a PM, your skills are very transferrable, however they do require you to understand and adapt to nuances of the role based on the team, product, and the company.

Here are the questions both of us answered.

  • How is your role defined and what are your responsibilities?
  • Who is your customer?
  • Given the differences in your roles and the customers you serve, how do you approach prioritization?
  • Which other teams do you interact with most frequently and why?
  • How does customer research work in your role at various stages of the product lifecycle?
  • What are the challenges unique to your role?
  • What helps you thrive in your role?
  • What are the pros and cons of your role?

How is your role defined and what are your responsibilities?

Harshal

I work as a product manager on the Billing Platform at Twilio. Twilio provides APIs for customers to communicate with their end-users via channels such as SMS, voice, WhatsApp, or email, thus providing a customer engagement platform to our customers. Twilio charges on a pay-as-you-go model, i.e. we charge customers per communication in real-time. The Billing Platform is responsible for accurate and timely processing of these micro-transactions including pricing each transaction based on customer contracts, charging credit cards automatically, and providing customers and Twilio’s finance teams visibility into usage via web portals and invoices.

At Twilio, I’m responsible for systems that

  • process over 100,000 monthly invoices to customers
  • show usage via API or web portal for hundreds of SKUs
  • charge taxes to customers in compliance with regional laws

My focus is split between internal and external customers, as well as business-savvy non-technical stakeholders. These two factors bring interesting challenges to my role.

On a regular basis, I work closely with my engineering team, peer PMs, and cross-functional stakeholders. I consider prioritization and describing customer problem statements as my value addition to the team. On a day to day basis, I look at tasks that include

  • monitoring projects post-launch to ensure customer success
  • reviewing customer or stakeholder complaints and internal process inefficiencies
  • investigating customer behavior and compliance requirements so that I can describe product requirements to my team

Nikitha

I’m a product manager for VMware’s flagship product, the compute platform called vSphere. To those less familiar with enterprise software, vSphere is to data centers what AWS is to the cloud. vSphere is software that is installed on servers in customer data centers that makes them easier and more efficient to run and manage.

My role is particularly interesting because I get to have a foot in both worlds—the traditional one where applications are deployed in virtual machines, and the newer cloud-native one where containers are the preferred choice for modern applications. 

My role is a traditional one as far as product management goes. I own several functional areas of our product, and given how technically challenging our product is, no two days are the same. If I had to chalk out where I spend my day, about 50% is with my engineering and UX counterparts, 30% is devoted to responding to emails, thinking about and writing product requirements, and the remaining 20% is spent talking to customers.

Who is your customer?

Harshal

My product serves both external and internal customers, and I need to consider both when enhancing the product. 

My external customers are the accounts payable, procurement, and product manager personas of Twilio customers. 

My internal customers comprise product teams and finance teams. Product teams request enhancements to my product when a new product (say, a new chatbot) is being launched or there is a change in how products are being charged or priced. Finance teams request automation of financial tasks such as tax collection, reporting, or invoice generation.

Nikitha

vSphere is built for enterprise customers of varying sizes. Startups usually start with the public cloud, they don’t need to have their own data centers. Our largest customers are among the Fortune 500 companies that have their own data centers (especially regulated industries like healthcare and financial services).

Overall, my product is external facing and the primary user persona is called an “IT administrator”, a person responsible for IT infrastructure at an enterprise company. Our customers though are threefold

  1. we build software for IT administrators so that 
  2. they can provide a state-of-the-art platform for their developers to build software in order to 
  3. keep CIOs and CTOs of their organizations happy

Given the differences in your roles and the customers you serve, how do you approach prioritization?

Harshal

I drive prioritization of internally-focused initiatives based on their cost-benefit analyses. Benefits of a project are often provided by the stakeholder, while my engineering team estimates the effort required to implement the solution. Such prioritization is often adjusted depending on stakeholder escalations or compliance requirements, as priorities are driven by internal stakeholders. Due to a frequent change in priorities, I’ve found myself building agility in my team to quickly jump onto new problem statements for initial investigations. This agility helps us engage with stakeholders to flesh out the request and decide whether we need to reprioritize to meet ever-changing business goals.

Nikitha

Three main factors determine the priorities of features that I work on.

  1. Customers: What the customers want is what we will deliver. Customer feedback is carefully considered and weighed, but if a critical mass of customers is asking for the same feature, it’s a no-brainer to invest in such a feature
  2. Competitors: If one of our friends in the cloud (AWS, Azure, Google Cloud) ships a critical feature we don’t have, that’s an immediate bump in priority
  3. Organizational alignment: While the first two factors above tend to be more bottom-up in terms of being left to the discretion of individual PMs and PM teams, this charter usually comes from the powers-that-be. Whenever we have overarching company goals to deliver on, for example an integrated experience for our customers involving various business units like storage and networking, other team’s requirements can drive our own prioritization

In some planning cycles, the priorities of features are glaringly obvious simply based on a surge in customer demand or the urgency of providing MVP functionality. However, when planning is likely to be more contentious, I will use the RICE framework or the Kano model to structure and share my thinking with stakeholders.

Which other teams do you interact with most frequently and why?

Harshal

I work with three types of teams

  1. Customers or customer-proxies of my products, including support, sales, customer success, who provide feedback or directives for problems to be solved
  2. Problem-solvers including peer PMs, designers, and engineers with whom I solve customer problems
  3. Solution enabler or enhancers including knowledge base team, customer experience managers, product support specialists, data analysts, and vendors

Nikitha

My answer here is pretty similar to Harshal’s. I interact with 

  • Engineers and engineering managers to develop features
  • PMs in my team to ensure that our feature interoperate well and we have a consistent strategy across the board
  • UX designers to simplify user interactions with our product (both in terms of the user interface and the developer experience)
  • Analytics team to measure the usage and performance of features in the product
  • Customers and customer representatives (technical account managers, solution architects) to gather qualitative feedback, and understand pain points

How does customer research work in your role at various stages of the product lifecycle?

Harshal

When my team is solving problems surfaced by internal stakeholders, I will typically

  • conduct research by interviewing the stakeholder to gather requirements, for example revenue accounting or tax compliance needs
  • shadow the executors of a job to understand the current process, for example manual billing, accounting, or invoicing 
  • review impact on other stakeholders, including end customers, by going through support tickets and running queries in the system to understand customer data and behavior

A huge benefit of conducting research among internal customers is the amount of access I have with them in terms of reaching out for clarifications, feedback, shadowing, and so on.

I collect post-launch feedback by talking to the stakeholder to understand their before vs after. It often results in the discovery of next-level problems to solve to increase the value and stickiness of the solution.

Nikitha

During the ideation phase of the product, when we are still in the process of defining the scope of the solution we are trying to build, my research typically involves

  • Talking to customers or customer representatives that have interacted with the area of product I am working on or have asked for the feature in question
  • Working with our UX researchers to get feedback from the regular “product feedback groups” that they conduct with customers on a monthly cadence 
  • Reading documentation pages of our competitors, reviewing white papers from industry experts and analysts
  • Consulting with PMs and senior engineers/architects in my team for their input

Post-launch, my process is pretty similar to Harshal’s in that I make sure to look at 

  • Our product telemetry, which is an internal analytics dashboard
  • Feedback from our beta/early internal and external customers
  • Support requests (SRs) that are opened against that area of the product
  • Discussion on socials, since we have an active community of vSphere users on Reddit and Twitter

What are the challenges unique to your role?

Harshal

A challenge I’ve found in this role is to ensure that it is not the loudest voice that gets the priority, and to ensure that those not present at the table also have a voice, specifically Twilio customers.

Since many enterprise customers have several users, such as developers, procurement, or accounting, out of which only a few care about pricing or invoicing, another challenge is to identify the right stakeholder when looking at customer usage patterns or sending product feedback surveys.

Since billing is expected to “just work”, my products can either dissatisfy customers or not make a difference to their happiness; it is unlikely to delight customers. This makes it hard to derive a product NPS from company NPS scores.

As a cloud SaaS platform, Twilio is used by many futurists. However, accounting users from our enterprise customers are often not tech savvy, which results in a clash of values between how billing solutions are ideated (“high-tech”) vs are expected to be provided (“accounting procedures need it to be on paper”).

Nikitha

The challenges in this role for me tend to be the depth and breadth of technical knowledge that I need across a wide range of areas like containers, Kubernetes, and virtualization. As a relative newcomer to the field, it is sometimes difficult to hold my own when surrounded by people who have been in the industry for over a decade. 

The clash of values that Harshal noted between enterprise customers at the “cutting-edge” and those that are “old-school” is something I struggle with a lot too! Customers are always looking for solutions to problems they have today, but as a PM, I think a lot about the future and where the industry is going in the long-term. Balancing both gets tricky.

Like Harshal noted, the loudest voices tend to get heard the most, except in my case, it’s the large customers who can really influence our roadmap. It is challenging to maintain a balance between what customers need to be successful in the short-term, while at the same time setting them up for success by predicting the future. 

What helps you thrive in your role?

Harshal

Juggling various threads of discussions at once has been helpful to me since at any time there are projects in post-launch, execution, design, and discovery phases. Executing a few projects and designing a few others while stakeholders continue to bring up more projects for scoping… all in the same week.

I do a good job of understanding customer needs vs wants. I try to understand the underlying need or job that needs to be done vs what the stakeholder is saying. Stakeholders are closer to the solution-space than external customers so they jump into “solution-ing“, which can hide the real problem.

Nikitha

Along the lines of being able to multitask, having keen attention to detail is really helpful in this role. The ability to drill down on a problem and explain it to others in a clear and concise way is valuable. I personally find that being efficient and knowing where to spend my time (80-20 rule) has helped me do my job without burning out. This was pointed out to me by others but my direct, no B.S. approach seems to resonate with folks who just want decisions made so they can go and execute.

I also find that building deeper relationships with cross-functional stakeholders helps me be better at my job – they always remember to seek me out and keep me in the loop ahead of time, while also being more amenable to responding to ad hoc questions and requests I randomly have!

What are the pros and cons of your role as product manager?

Harshal

Pros

  • A benefit in research with internal customers is the ease of getting time for UX research, clarification questions, and post-launch feedback
  • The number of data points for customer research can often be high, which can make it easier to get a statistically significant metric. For example, every product and every customer uses my billing product as compared to the number of potential users for a new Twilio product feature
  • Another benefit from being at the intersection of all products and customers is that I get to work with 16 cross-functional teams, which is great for learning and staying up to date with initiatives across the company

Cons

  • Since the billing platform is not a revenue center, the headcount growth in the department is not driven by the increase in company’s revenue. Instead, headcount growth is driven by projections of effort involved in the backlog of projects
  • Prioritization can get opaque and fluid at the same time because customers of Twilio may not get an equal seat at the table as internal stakeholders, and because stakeholders can escalate requests to change the roadmap
  • Looking at billing via the Kano model lens, our customers are either dissatisfied with billing or neutral about billing. It gets that much harder to build in a way that delights customers

Nikitha

Pros

  • I am always learning from customers and colleagues, and every day is intellectually challenging
  • The cross-functional nature of my product means I get to learn about and interact with various business units across the company, which keeps things interesting
  • Even though vSphere is a technical product, there are unique user experience challenges, which allows me to flex my design muscles

Cons

  • As an enterprise tech company, software takes a while to build as development cycles are long. Coming from the SaaS startup world, this can be be painful sometimes
  • Imposter syndrome feels like an inevitable part of being a PM in such a technical space
  • Prioritizing and making the case for why my features should be implemented is a hard sell since engineering resources are finite and the opportunity cost of building one feature versus another is high

That brings us to the end of this very long post. I hope you find it useful, especially if you’re grappling with which PM role might be a good fit for you. A huge thank you to Harshal for joining forces with me on this one, be sure to follow him on Substack.

Leave a Comment

Your email address will not be published. Required fields are marked *