The Languages of Product Management
+ The Harsh Truths
Product managers need to be multi-lingual.
If you do not speak the language of the function you are interacting with, everything becomes more difficult. Conversations take longer. Alignment becomes tedious, if it ever happens. Stakeholders come back after a feature is launched with a list of complaints.
The best PMs prevent these messes by speaking in the language of their stakeholders. My friend Aatir Abdul Rauf calls these, “the languages of Product Management.” From my point of view, it is one of the most powerful concepts in product management today.
The worst product managers forever speak, “Producti.” They just speak in the language of PMs: terms like jobs to be done, user needs, empowered teams, putting the problem first, and product sense. While stakeholders and cross-functional partners have a sense of what these terms mean, they lack the deep neural net of context tied to each term product folks do.
The job of a Product Manager involves a lot of collaboration with these folks. Just like people from different countries and nationalities are most comfortable conversing in their native tongue, each department of a company prefers their own parlance. The most effective PMs pick up on this jargon quickly, to become more relatable and effective.
So, I am very excited to present a deep dive into the six most important languages for PMs to speak - Corporatish, Marketindi, Salesian, Designese, Techugu, and Analytian - with the creator of them himself, Aatir. The goal is to help you speak at least 10% better with your stakeholders. Let’s get into it.
The Languages to Speak
Corporatish
One of a PM’s most important relationships is with the company’s leadership. Leadership tends to speak a language known as, “Corporatish.” This is very different from Producti.
It’s not that leadership doesn't care about the state of the product. However, once the overarching goal is laid out in terms of a business metric like revenue, profitability, or market share, they need to know how product efforts translate into achieving them.
When talking with leadership, product managers need to communicate the health of the product and business metrics using terms that they care about and understand. It also helps, as a product manager, to be able to understand the lingo these folks use.
Key Terms
B2B: MRR, ARR, Logo/ Revenue Churn
B2C: Lifetime Value, Cost of Acquisition, Payback Period, Average Revenue per User
Both: Gross & Net Margin
Generally, the terms to know to speak Corporatish depend on whether your role is in B2B or B2C.
In either case, leadership is going to be interested in metrics around revenue.
MRR is monthly recurring revenue. This is the sum total of revenue the business is getting, stated on a monthly basis.
ARR is annual recurring revenue. It is the annualized version of MRR. It’s not just leadership who cares about ARR and MRR. Everyone from financial analysts to sales are always keeping a close eye on how ARR and MRR are tracking. As a result, the best PMs generally try to keep a close pulse on these rates, and, where they can, measure the impact of their features on them.
For subscription-based products especially, deciding which product features go in each package tier can have an impact on both MRR and ARR.
Thus, a conversation with leadership could look like:
“We’re beefing up our Pro tier with a workflow editor making it a more compelling proposition. We feel this will further motivate our Freemium users to upgrade, hence, bumping up our MRR.”
Logo Churn is the fraction of customers lost during the period over the number of customers at the start of the period. It is sometimes called customer churn. Leadership loves features that reduce customer churn.
The corollary to logo churn is revenue churn. Revenue churn is the fraction of revenue lost in the period, over the revenue at the start. Many think about a metric like ARR in the context of new revenue, existing revenue, and churned revenue.
Revenue churn biases to the biggest customers. As a result, many companies pay attention to both types of churn. But, all things equal, most companies care more about revenue churn than logo churn.
So, it’s very possible for a product to incur low logo churn in a month (say lost 1 customer out of 100) but suffer massive revenue churn if that “lost customer” was a majority revenue contributor.
Conversation Byte:
“We need to open a free trial for our product. This will help us capture more customers in the long run. Diversifying will help us reduce our logo churn. If we don’t work on this, then with just a couple of high-paying clients on board, we’ll always remain at risk of experiencing high revenue churn.”
Lifetime value is the total revenue a customer will generate for the business. Leaders often want to compare this to the cost of acquisition, which is the total cost it takes for the business to acquire the customer.
Leadership is usually playing a delicate balance between these two metrics. They may even measure the payback period, which is the amount of time it takes for the lifetime value to exceed the cost of acquisition.
Conversation Byte:
“Since competition is driving our cost of acquisition up, we need to drive up our lifetime value. To do that I propose, we focus on improving our onboarding experience & prioritize personalized customer service. On the side, we should consider increase our prices in the medium run. It will help shorten our payback period.”
Average revenue per user (ARPU) represents the blended rate of revenue you receive for an active customer. It is similar to lifetime value, however, it is usually calculated on a specific timeframe for financial statements, like the average revenue per user over a year. Some consider ARPU an overall business health metric, while LTV a user profitability metric.
Conversation Byte:
“By launching grocery delivery service alongside ride hailing, we’ll be able to cross-sell to our existing customers. This will kickstart adoption and also lift our ARPU.”
The final concept in Corporatish to understand as a PM is margins. There are two important one’s to understand. First, gross margin. Gross margin reflects the profit ratio leftover after accounting for cost of goods sold. It does not account for things like the sales team, or the product team. These usually fall in Sales/General/ Administrative Expenses, and Research & Development expenses, respectively.
As a result, while many high-burn companies will focus on gross margin, many profitable companies and financial analysts will focus on net margin. This is the lower of the two rates, which takes into account the company’s other expenses:
Conversation Byte:
“Our current SMS vendor is proving to be very costly as we’re scaling. Thus, we’re considering other upcoming players in the market who might be more economical. This will help dial up our net margins too. ”
Good vs Great Corporatish
Name dropping these metrics does not impress company leadership. Just like being an MBA doesn’t make you a magical PM, neither does knowing these terms. Instead, as a PM, the key is thinking through these metrics, and the impact your product will have on them.
Great Corporatish builds trust from the audience that the PM knows what moves these metrics, and has built a roadmap and features to move them.
Company leadership is often looking to harden the product roadmap. So, the conversation for good Corporatish will establish consensus on how the products are prioritized and built to achieve these metrics.
Resources to Learn More
This article could be 100,000 words. To avoid that boring fate, here are some resources if you want to go a layer deeper on these terms:
Visualizing the Interactions Between CAC, Churn and LTV by Gordon Daugherty
A guide to SaaS metrics for product managers by Tarif Rahman
Finance for Product Managers by Stephen Cornelius
As you can see, many of the terms in Corporatish are strategy or financial concepts. So, you can always go deeper by studying those fields.
To learn the other 5 languages of product management - Marketindi, Salesian, Designese, Techugu, and Analytian - as well as the enemy, Producti, read on:
The harsh truths about PM
1. You are not the CEO
2. You are not even a Manager
3. You have to please everyone
4. But you don’t have space in the backlog for everyone
5. Your boss expects you to be accountable for every detail
6. But you don’t have the ability to dictate every detail
7. You will frequently have to present data and user research
8. You will be blamed for the failures
9. You will only be sometimes rewarded for the successes
10. You will have to deal with all of this in relative loneliness
1: The PM does have to inspire the team like the CEO. But PMs don’t have the authority, gravitas, or expertise of the CEO. As a result, PMs constantly have to prove themselves. The CEO can dictate something and it will be done. PMs have to convince.
2: Managers at least have the hammer of controlling promotions and firings. They can push something without a direct report fully agreeing. A PM can’t push Engineers and Designers, who actually build the things, in the same way.
3. Everyone is eager to leave reviews and dish opinions about PMs. The core product team is just one stakeholder. The whole business cares. PMs have to please just about everyone to get promoted.
4: The easiest way to please people is to build what they want, how they want. But that is never possible. The roadmap never has space, and people often want conflicting things.
5: Product leaders and executives expect PMs to drive features to be built optimally. From design to measurement, everything is laid at the feet of the PMs - especially if something goes wrong in any area.
6: Yet, PMs can’t drive every detail. Designers have opinions and their own stakeholders. Business people and engineers have their own thoughts as well. Trying to drive every detail is futile & the team feels micro-managed.
7: As a result, PMs have to leverage data & user research to convince people to do things. This applies to what to build, & how to build it. Designers might want something, but the PM has to show reason to do otherwise.
8: PMs generally get blamed if something goes wrong: didn’t think of the edge case, didn’t push legal enough, failed to coordinate analytics, didn’t research the problem enough, or didn’t consult enough stakeholders. It’s never ending blame.
9: Engineers & designers, the builders, will always get recognized for what they built. Even if PMs put the thing on the roadmap at the expense of something else and helped unblock execution, sometimes they don’t get credit.
10: No one else needs to deal with the precise engineering managers and designers the PM does. No one else has the same set of stakeholders. The PM has to strategize, and despair, alone.
Despite these 10 harsh truths, many find it worth it. PMs are responsible for the product vision and strategy. PM dollar value in the market is nearly as high as engineers. And, PMs get to learn a lot, making an impact.
Probably, one of the best articles that I have read about Product.