Is there any role called internal PM?

As a Product Manager I lead two teams developing auto-scalable cloud-based tools for internal use in a large corporation. These tools are part of a larger toolset, consisting of hundreds of systems and frontend pages. I have minimal autonomy and am closely involved in scrum rituals, daily calls, retros, reviews, planning efforts, technical refinement, backlog prioritization, negotiation with client teams, and handling incidents. I also act as a product owner in Scrum roles and manage people.

My doubt is, since I am manage a product that is solely for internal use, and has no external user base, am I still a PM?


The majority of product roles are internal facing. They focus on improving internal processes and systems. However, there are also product roles that have an external focus, such as driving customer engagement and satisfaction. The internal product roles involve working closely with stakeholders and devs and gathering their feedback to inform product development and improvements. They play a crucial role in ensuring that the product meets the needs and expectations of the internal users.


Really? I’ve always had the impression that product roles are focused on mobile and Internet websites. However, it seems like there is a broader scope for product roles beyond just mobile and Internet websites.


It is significant to remember that SaaS PMs exist. They create software that businesses license for internal use. They work in PM. It’s very likely that your business created some of those tools internally; the PMs who work on them are still employed there.

PMs are employed by Facebook, Google, and Amazon to work on such things. more so in the advertising space. They assert that they perform more elaborate work, but they follow orders based on payment. similar to how your VP sets priorities for you.


When discussing products and PM, many people, especially those new to or attempting to break into PM, only consider those that are (external) customer-facing.

Not sure why internal products are viewed as less seductive; perhaps because they are frequently more abstract than B2C.


I oversee the development of internal systems for internal “clients.” In addition to working with my agile team, I’m also expected to complete PM tasks like user interviews and creating a strategic roadmap. We don’t complete all of the business’s requests, projects, or priorities. My responsibility is to suggest whether we should work on the requests from the business (using data to support my case), suggest additional items based on my own research, determine how everything fits into the overall roadmap, and ensure that everyone agrees on the final roadmap that we do deliver.

My manager constantly emphasizes that if all we’re doing is implementing project requests from stakeholders, then we’re acting more like project managers than product managers.


You would have a line of products and lots of fans if you were to survey your internal customers to learn what tiresome tasks they perform on a daily basis and figure out a way to automate them. Put some money aside to expand the team and divide the work. Iterate, and demonstrate the expanding value to the bigger organization.

Each environment contains undesirable elements that hinder us. How do you get rid of the biggest, stenchiest items in your workspace?


Why don’t you conduct a research?

I lead internal product teams, the role definitely exists.


Would be interested in your definition of research and very concretely how you put iron practice with concrete steps? One of the things I’m trying to improve on.


Hey OP,

Assuming you are also an internal product manager, I’ll give you some tips here for free.

What is the pulse of the business, and what is or isn’t scaling with growth?

For example, are you seeing a lot of issues or fires pop up because there’s a lack of visibility and/or a systematized process in place?

One thing many people don’t realize is that operational friction isn’t just a cost factor. It usually directly impacts the ability to increase revenue.

The concept of “we can throw people at the problem” used to be true to an extent, but it’s the thinking of old timers. People are hard to get to do frontline jobs. Even second tier roles, including supervisors and managers.

When doing discovery, I want to have an insanely accurate picture of what’s going on currently. Then start thinking about what success looks like in that space.

What are your stakeholders ideas of success? They may or may not have one, and it may or may not be aligned with what you’re seeing.

If you have a strong business stakeholder that you feel his expertise in what they do and are good collaborators, start mapping out the and aligning around what you both believe isn’t working today… and what the most critical next steps are, but making sure they are steps in the direction of the North Star.

I used to create a stack ranking like spreadsheet together where I rank each area of the business across each other which helps explaining priorities if you own multiple departments / areas.

It was scalability focused vs what I usually use for customer facing stack rank templates.

Examples of metrics I would use:

Compliance Risk (1-5) This represents the level of risk involved in the work that’s being done. Underwriting is high risk. Customer service for a non Fintech product could be low.

Process Visibility (1-5) This represents the percentage of work that teams are doing where their processes have a digital footprint. Things done manually, locally, in google docs and sheets, in peoples heads, or in ways that are fragmented without the ability to analyze activity or outcomes are what I usually eye for a good slaying.

Automation (1-5) this represents the level of automation that exists. I often start in places that are sitting at zero and use this metric to track my projects against until we fully automate massive chunks of work.

Speed to Proficiency (1-5) This represents the metric I use to determine how easy it is to hire someone and get them to full proficiency quickly. Often startups (or larger companies) spend a lot of time training messy process and hope people retain a ton of learned knowledge to execute in later. The funny thing about this is that it requires you to be able to measure performance which leads me to the next metric.

Performance visibility (1-5) This represents the departments ability to accurately and fairly assess employee performance. To really create a strong view into performance that requires you to address the other metrics first building internal tools with this metric in mind. Systems are transactional and like to store data important to a record or object. They are terrible at providing data on how people are using the system and tying that behavior to outcomes. Employees don’t want bullshit metrics that don’t actually paint a picture of what “greatness” looks like but feel pressured to do worse so their numbers look good. A lot of discovery should go into defining what great employee performance looks like then creatively finding ways to illuminate that behavior. I could do a whole Ted Talk on this but I doubt anyone would find it that interesting.

This is actually really helpful for automation efforts as you find ways to replace humans in process. You can’t automate work people do if you don’t have a firm grasp on what it is that makes people great. In fact I have consulted at several robotics companies where they focused on automating outcomes with no awareness around why their process was so much worse until they fully built out products they couldn’t operationalize.

Speed and agility is a constant issue in robotics. I digress.

Anyway those are some metrics that do a lot of discovery in order to to put firm findings there and continue to track them as you make progress. Of course I’m tracking revenue, efficiency, etc. Anyone can BS those numbers. These you have to know well to answer them accurately.

Hope some fit that helps.

Master this and you can charge 350/hr :slight_smile:


Discovery on how the tools are used and ways to improve performance, efficiency, etc.

I manage internal systems and this is what we do. Our internal service is the product and our employees are the “customer”.

I’m always looking at metrics on usage, application performance, and user performance.

Because another thing is if I improve user performance it means saving the company $$$ from either time they can use on other tasks or headcount not hired. Whether they do or not it’s not up to me, but I ABSOLUTELY track and report the efficiencies as product performance.

For example, I improved the order and a specific workflow in a system I manage. This re-order saves 1 customer service agent about 20 seconds PER REQUEST they process. If one person does 100 per day that’s 30-35 minutes saved. Times 1000 global agents that 30000 minutes per day. That’s about 500 man hours daily. 500 hours x$20 base hourly rate that $10,000 per day. 260 business days a year that’s $2.6 million potentially “saved” or at least captured as efficiencies.

I’ll add that to my product stats as well as my resume for the future.


I concur with others, for now, you’re a product owner. If you start getting involved with the business to the point that you are driving strategy and roadmap initiatives for what your platform can do to help the business achieve its outcomes, then you become more of a product manager.

Managing direct reports has little to do with it.


I like to keep it simple, products generate revenue and product managers manage those products. That’s it.

I think the role is used in place of older roles like systems ops, that developed tools and processes. Using PM practices does kind of streamline processes and activities in the company.


No you aren’t but it doesn’t matter. I also do that and it’s fine, just a different job with a similar skillset. A product manager owns generating revenue for a commercial product, we don’t.

1 Like

Like you, I favor product owner @DianneStinger.

I’m unfamiliar with the notion that Product Managers must be in charge of generating revenue for for-profit products, though.

If I were a PO, my boss—who oversees all of my peers—would be a product manager, and his boss—who directs the strategy for all products—would be a group product manager.

1 Like

Product management is managing something that gets sold. Our stuff doesn’t, so we’re not product managers, plain and simple.

What we do is good old IT, which is a job that needs doing and generates money too, but in a different way. There are similarities in the skillset (I was an actual PM before I took this job), but they’re not the same. For example, you don’t do product marketing, you don’t do pricing, you don’t work on competitive positioning, etc.

1 Like