Balancing Customer and Internal Focus as a Product Manager
A Balancing Act
Recently, I had the opportunity to collaborate with Nikitha Suryadevara on a post to compare internal vs external focus in different product management roles. The discussion made me realize that many product roles have a balance between customer and internal focus. In this post, I would like to describe my experience at the intersection of creating customer-impact and enabling internal-tooling.
I hope this helps Product Managers introspect about their balancing acts and helps aspiring PMs understand one aspect of the PM role.
I’ve reused information from the comparative post while delving deeper into some areas.
The Basics of my Role and Responsibilities
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. charges 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 dozens of regional laws.
On a regular basis, I work closely with my engineering team, peer PMs, and cross-functional stakeholders. I consider prioritization and distilling customer problems 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.
My focus is split between internal and external customers, as well as business-savvy non-technical stakeholders. For this post, we will focus on the interesting challenges brought by these factors.
Customers of the product
My product serves both external and internal customers, which requires a balancing act.
My external customers are the accounts payable, procurement, and product manager personas of Twilio customers. Since customer sizes range from a single developer to Fortune 500 companies, how (and how often) customers interact with billing information also varies.
My internal customers are product teams and finance teams. Product teams request enhancements to my product when Twilio launches a new product (say, a new chatbot) or there is a change in charging or pricing products are being charged or priced. Finance teams request automation of financial tasks such as tax collection, reporting, or invoice generation.
Since my product serves external and internal customers, I need to consider both when building my product roadmap. Further, none of my customers pay for the product, so the budgeting for my team is indirectly influenced by the needs.
My team builds our products as per the needs of product or pricing strategy teams which are indirectly driven by customer needs. For example,
when a product team launches a new product, my team and I investigate the enhancement of the reports, invoices, taxation, billing API, and portal experience to explain the billing of the new product.
when the pricing strategy team launches a new pricing strategy for a product, I investigate the same set of services to explain the resultant charges so that Twilio customers can understand the new pricing.
In these examples, the driver of the change is internal but defining the problem statement and solution require external customer research as well. An example balancing act I recollect is when we launched a new pricing strategy. Although I could understand the needs of our accounting and pricing strategy teams, I also had to understand the customer perspective. I reached out to early adopters (wizard of oz style) of the pricing strategy to understand why they choose this approach and the billing information they search for on the portal or invoice. I could combine this customer research to work with my product designer and engineers to build a solution that worked for internal stakeholders and met the transparency needs of customers.
I drive prioritization of internally focused initiatives based on their cost-benefit analyses. The 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.
I hear about customer requests via sales deals or support tickets and uncover the need and impact by analyzing the data and interviewing customers.
It is often tricky to prioritize between customer needs and stakeholder requests since their impact is on different axes. I find organizational level priorities helpful here to determine priorities between external or internal priorities.
What are the challenges unique to your role?
I can think of four challenges:
A challenge I’ve found in this role is to ensure that it is not the loudest voice that gets the priority and to make sure 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. This is a variant of a common problem with Enterprise software.
Since customers expect billing to “just work” as a basic need, customers are either dissatisfied or indifferent to my products; it is unlikely to delight customers (Kano Model). This makes it hard to survey my product’s NPS score and requires some creativity to understand customer satisfaction.
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”).
What helps you thrive in your role?
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 strive to do a good job of understanding customer needs vs wants. I 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.
Hope this post helps you introspect your own role to understand the balancing act you do and how to define your success in it. I’ve left out some aspects not relevant to the balancing act in this post. If you would like to read more, you can check out Nikitha and my joint post.