I’ve done both. And I just changed role again*. So I thought this is a perfect time to jot down my thoughts on the differences between internal- and external-facing PM’s.
If you’re wondering what’s the difference between PM’s who serve external clients vs who serve internal teams, or if you’re trying to decide between these two flavors of product management roles, I hope this article will be helpful!
Before we start: “Internal-facing product management” and “external-facing product management” are quite a mouthful to say; I’m gonna try to refer to them as “Type I” (for “internal-facing”) and “Type E” (for “external-facing”) product management.
Type I PM’s Enjoy Faster Speed of Innovation
Type I PM’s (internal-facing) usually get to innovate faster.
Regardless of which kind of PM you are, you have customers to serve. But depending on whether your customers are also your colleagues, this can have a big impact on your speed of innovation.
All else equal, if you work in the same organization as your customers — in other words you are a Type I product manager whose product is consumed by internal people — innovation cycle could be a lot more expedited compared to that of your Type E counterparts.
How come? To answer this question, let’s consider, on a high level, what constitute the most typical innovation cycle: Product Feedback —> Feature Update —> Release (—> Product Feedback again).
In Step 1, Product Feedback, a Type I PM usually has a much easier time gathering feedback from their customers. These customers (colleagues) are usually searchable in an internal HR system, just an IM message away, whose calendar slots are viewable and up for grabs. And there isn’t a lot of privacy regulations preventing you from reaching out to a colleague because you were interested in why they decided to click this button and not that link. (When I was a Type I PM at Microsoft, I came up with a short saying for this: “Microsoft doesn’t sue Microsoft.” [I think]) All of these are true vice versa: if your customer has feedback about your product, they can usually pretty easily find you and shoot you a message personally, an exercise almost impossible in most other cases (do you have the email of the PM of your favorite or least favorite app — unless you happen to work there?).
In Step 2, Feature Update, having easy access to your customers also helps accelerating the feature design. Many of my PM colleagues will sure resonate with this problem: sometimes when small design questions come up in creating a feature, having a customer(s) chime in is a really good way of getting unblocked. If the customer/colleague is passionate about what you’re building, they may even work directly with you to design it. Type E PM’s don’t have that luxury because it usually takes some paperwork and booking-in-advance to get to their customers.
When it comes to Step 3, Release, internal releases are also usually less cumbersome. Typically, stakeholders that Type E PM’s need to work with regularly (such as legal, marketing, revenue, etc.) don’t need to be involved; the Type I PM can get away with an email or posting to the right audiences. And in case the feature is not well-received, it is way easier to roll back an internal-facing feature compared to a publicly released one!
Type E PM’s Have (And Need) More Allies
Riding on the last point, Type E product management usually deals with higher financial, legal and PR stake for an organization. As a result, Type E PM’s usually have more allies, while Type I PM’s are often more on their own.
In the last section, I discussed some additional hurdles that faces Type E PM’s. Fortunately, a Type E PM does not have to go through them alone (it’s pretty impossible to).
A Type E PM can get a lot of insights about their customers from that customer’s Account Managers, while a Type I PM might be Slacking their customer directly.
A Type E PM could ask marketing to chime in on product release plans, while a Type I PM typically owns all the internal stakeholder announcements of feature updates.
A Type E PM might work with a legal team on product compliance, while a Type I PM — well, they usually have less compliance to do.
As you see, Type E PM’s have more public-facing stake they have to manage for their product than their internal-facing colleagues. But thanks to the various expert teams they get to partner with, their speed to impact is not reduced.
Which brings me to my next point.
Type I and Type E PM’s Measure Impacts Differently
I strongly believe both flavors of product management carry excellent opportunities of impact; no one type has an “easier” time making impact. I have thoroughly enjoyed both Type I and Type E roles throughout my career. However, there is a difference in how impact is measured for them.
For a Type E PM, impact usually translates from some external-facing KPIs. As the face of the product they manage, Type E PM’s have access to many success metrics of the product itself (in fact they usually define these metrics as part of product requirements). Is the product a revenue-generator? Then take a look at the sales number after the release. Is the product meant to be a delighter in UX? Then user satisfaction is usually your best bet in measuring impact. What about a product that bridges a critical functionality gap against a competitor? Then conversion and churn rates can usually tell you something about the impact of the product.
A Type I product manager, on the other hand, will have a different lived experience when trying to measure the impact of their product, because of the nature of their work. Customers don’t spend more simply because you made the internal design system easier to use; user SAT won’t immediately go up after you improve the developer experience of the engineering team; and client conversion and churn won’t do much when you better the quality of the internal team documentation.
How does a Type I product manager measure their impact then? The answer has to be indirectly. Keep an eye on how your product is used downstream to build features that go directly to the customers, and consider how your work enabled, unblocked or accelerated their work — that’s how your impact is measured. This is also why I like to think of Type I product management as high-leverage work: what you do will empower teams much larger than just yourself to achieve more faster.
Of the three differences discussed so far, I think this might be the most important one for leaders of product teams to keep in mind. It indeed requires more work to gauge the impact of the Type I product managers on the team, but that works is absolutely necessary.
Still, We Are All Product Managers
I want to conclude this discussion on the differences between Type I and Type E product managers by with the commonalities between them:
Based on my experiences as both types of product manager, I do believe their differences are miniscule compared to their commonalities. Different speed of innovation does not negate the mindfulness, the investigative curiosity, and the “diagnose before prescribe” mentality they must all bring to all customers, internal or external. The difference in the sizes of their immediate ring of collaborators doesn’t change the cross-functional nature of their roles. And whether they measure impact directly or indirectly, their opportunities of impact are no different — just need to be grabbed from different dimensions. They can also both make impact outside of the realm of product development, such as in contributions to team vision, culture and roadmaps.
I certainly enjoyed being both, and if you’re considering either, I assure you it will be a really fun and rewarding journey.
*I recently got a new role within StackAdapt: I’m now leading the Inventory and Pixel product team (both client-facing adtech areas). Previously I led an internal-facing team on our internal design system, dev experience, and infra modernization. I also did both at Microsoft, where I worked on both an internal-facing engineering systems team under Windows and then a B2B SaaS team under Azure.
(Copyright note generated by Bing: This Photo by Unknown author is licensed under CC BY-SA.)