Why I am writing about this
I talk to a lot of internal PMs. In DMs, in comments, in hallway conversations.
There's a pattern. Something about this job doesn't match what we were promised.
We read the same PM content everyone else does. Outcomes over outputs. Deep discovery. Empowered teams. User-focused.
Then we sit down at our actual desks, and reality looks different.
Instead of pretending we are doing the classic “product management” job, I think it is much healthier to accept that we do not. Talk about it, assess it and do something about it.
So today I'm naming seven of these disconnects out loud. I am hoping this will help you on your journey of becoming the best internal PM version in your company, and also know that you are not alone in this boat.
Disconnect #1: We're called product managers. The job often looks like project management.
Since I'm dropping some truth bombs today, let's start with the biggest one.
We're called internal product managers. But very often, our work looks like a glorified version of project management.
Is it me, or is it the system?
Should: A product manager works on a specific product, against a vision, building for customers and users. Heavily involved in discovering the business problems, then working with engineering to solve them.
The formula: PM = Discovery + Delivery + Value
Reality: You're handed requirements from the business. You're given a delivery date. Your job becomes coordinating the completion.
You're not focused on discovery, users, or customers. You're focused on delivering something within a timeframe, and coordinating the people who build it.
You're also not thinking about what happens after: will customers be happy using it, does it fit with the rest of the product, does it align with the vision. Your goal is just to deliver.
The middle ground: I don't think internal product management can exist without some overlap with project work. Maybe that's not what the PM industry wants to preach, but the industry is also largely unfamiliar with the peculiarities of building internal products.
When you're building an internal product, your job is to balance these two realities. Own the product, build the vision, and run projects as needed. Sometimes you will have a project delivery resource, sometimes you will have to take on more of that yourself.
What to do about it:
→ Look for ways to strengthen the discovery part of your role
→ Spend time on the vision of your product, not just the requirements in front of you
→ See if you can reorganize the team, get additional project resources to free you up for the product work
Disconnect #2: Product leadership doesn't have a North Star KPI
Should: As a product manager, you work with your product leadership to understand the business's overall goals, and the North Star KPI you're working against.
Reality: Internal product managers often don't get a North Star KPI. You might get availability and reliability targets, but those are ops-focused, not product-focused.
Your work becomes a summary of activities instead of an intentional move toward a goal.
So the path forward stays unclear. You're not sure where you are or where you need to go.
What to do about it:
→ Start with yourself. Study the org's strategy docs and slide decks, join the town halls, understand where the business wants to go
→ Study your users' goals, and where they want to go too
→ Draft a vision for your product, and a few candidate KPIs
→ Bring it to your management. Discuss what makes sense from their perspective. Expect they won't get it right away, but they will, with time
→ You will land on a product goal, and you might discover you need to change it later on. But at least you will be on the journey
Disconnect #3: Some products are just maintenance
Should: Product management is about building new value: shipping features, running experiments, moving a roadmap forward.
Reality: Plenty of internal products are past their growth phase. Your job becomes keeping the lights on: bug fixes, compliance updates, making sure nothing breaks when an upstream system changes. And frankly, it can be boring and busy at the same time.
Maintenance mode is still product management.
The middle ground: Maintenance mode is still product management. But here's a cool thing that's now available: AI. Even for a matured product, we can now envision a future where the work is done by AI agents. And your product is no different.
What to do about it:
→ Define what “healthy maintenance” looks like for your product: uptime targets, an acceptable tech debt ceiling, response time on fixes
→ Look for small strategic bets even inside maintenance mode: consolidation, automation, or sunsetting what nobody uses anymore
→ Look further, envision what your product would look like with AI agents. Can you get behind leading this transformation?
Disconnect #4: Some product teams are just you and one more person
Should: A product team includes a PM, a designer, several engineers, often a researcher too.
Reality: Sometimes it's just you and one developer, maybe part-time. No dedicated design support. No researcher. And you're torn apart trying to push changes and fix bugs, with no capacity for bigger strategic thinking.
A small team doesn't mean small impact.
The middle ground: It means you wear more hats than the textbook says you should, and you need to be smarter about what you do and when you do it. Plus, you have a bigger opportunity, and need, for AI agents as your teammates.
What to do about it:
→ Time-box how much of each hat you wear, so one role doesn't eat your whole week
→ Borrow support across teams for the initiatives that actually need design or research, instead of trying to do it all yourself, all the time
→ See if you can find a critical business problem to solve and get a team assembled behind it
→ See how you can create AI agents to do work for you, like testing
Disconnect #5: Caring about UX is almost impossible
Should: Product managers invest in user research, usability testing, and iterating on design based on real feedback.
Usability always goes last.
Reality: Usability goes last, after functionality fit, technical fit, security and compliance, delivery on time, operations stability, and many others. Usability also gets thrown onto internal product managers who often don't have the UX experience, or even the time, to do it right. In the end, users get something that's functional, but often hard to onboard, understand, or use.
The middle ground: Even though we can't put UX at priority 1, or even priority 2, we need to give it priority 3. That means it needs KPIs, and it needs a place on your roadmap.
What to do about it:
→ Define one UX metric that you will work toward
→ Interview 10 users to understand their pain points
→ Track support tickets, user complaints, questions
→ Get yourself trained
Disconnect #6: Your users are not welcoming change
Should: Users are excited about new features and improvements you ship. They want more functionality, just like external users.
Reality: Internal users often resist change, period. They've built workflows around today's messy tool, and even a better version threatens their productivity in the short term. They're also worried about being automated out of their jobs, or replaced by AI.
The middle ground: Working with internal users is tricky. Some changes will be welcomed, others won't. After all, your client isn't just your users, it's the business itself. If there's a business problem, reason, or value behind what you're doing, your job is to push it through regardless of the users' perspective, but without burning bridges with them. The middle ground here is that you're literally in the middle, between the users and what the future of the business would look like.
It's a change management problem, not a product problem.
What to do about it:
→ Involve users early, before the change ships
→ Communicate the change well ahead of time, more than once
→ Offer training or support during the transition, and treat that as part of the launch, not an afterthought
Disconnect #7: You own your product roadmap. But your leadership has the ultimate say.
Should: The product manager owns the roadmap for their product. They're the expert on the business problem, user issues, and so on. They're the ones prioritizing, sequencing, deciding what initiative comes next.
Reality: It works, until one day management comes in and puts a must-do within the next 3 months on you. Your whole roadmap shifts. You have no choice.
The middle ground: You can't escape this. The best thing you can do is train your narrative. Say yes, we can do that, but that means a trade-off on the following thing.
In the end, the highest business criticality wins.
What to do about it:
→ Name the trade-off out loud when it happens, don't just quietly absorb it
→ Keep a running list of what got bumped and why, it's useful the next time you need to push back
→ Ask leadership to own the trade-off decision with you, not just hand you the mandate
Where this leaves us
None of these disconnects mean you're bad at your job, or that internal product management isn't “real” product management.
It means the job looks different than the books say it should. Naming that is the first step to working with it instead of against it.
