"Internal Platform Teams need Product Managers too!" the organizational design books told us. "Treat internal customers like external customers! Apply the same rigor!" It sounded logical. We were building tools for developers—an internal developer portal, CI/CD improvements, shared libraries. That's a product. Products need Product Managers.
So we staffed our platform team the "right" way: a Product Manager leading the roadmap, with a team of engineers executing against it. We hired a PM with a strong background in developer tools—she had worked at a dev-focused startup and understood technical workflows.
For 18 months, we followed the standard playbook. The PM interviewed internal developers ("users"). She synthesized their feedback into PRDs. She prioritized the backlog. She wrote detailed specifications. Engineers built what the specs described.
The output was technically functional. And almost universally disliked.
Our internal CLI had awkward command names. The API was inconsistent—GET endpoints that should have been POST, nested resources that required five API calls to accomplish simple tasks. The deployment tool had a "workflow" that made sense on a flowchart but was maddening to use daily.
The feedback from our internal developers was consistent: "This tool clearly wasn't built by someone who writes code."
They were right. The PM understood product management. She did not viscerally understand what it felt like to use a CLI for 6 hours a day. She couldn't feel the friction because she didn't live in the codebase.
After a particularly brutal internal survey (35% satisfaction rating), we made a radical decision: we eliminated the PM role from our internal platform team entirely. The senior engineers became their own product owners.
Within 6 months, satisfaction rose to 82%. Adoption of internal tools tripled. Here's why Product Management for internal developer tools requires a fundamentally different approach.
Section 1: The Empathy Gap—Functional vs. Ergonomic Requirements
To build a good chef's knife, you need to be a chef—or spend thousands of hours observing chefs and understanding how they move, grip, cut, and clean. A knife designer who only understands metallurgy will produce a blade that's sharp but uncomfortable to use for 12 hours.
The same principle applies to developer tools. A non-technical PM can capture functional requirements with high fidelity. "The tool must deploy code to staging." "The tool must run tests and report results." These are observable and documentable.
What they miss are ergonomic requirements—the subtle UX considerations that make a tool feel natural versus awkward:
- Tab completion: Developers expect CLI tools to support shell completion. If I type
deploy --en[TAB], it should complete to--environment. - JSON output for piping: The tool should output JSON when stdout is piped, but human-readable text for interactive use.
- Respect existing conventions: If
gituses-ffor force, our CLI should too. Developers carry muscle memory. - Semantic exit codes: Exit with 0 on success, 1 on failure, 2 on usage error. Scripts depend on this.
- Idempotency: Running the same command twice should be safe. "Deploy to staging" should not deploy twice.
- Fail loudly on errors: Don't swallow exceptions. Print the stack trace. Developers will debug it.
These requirements never appeared in our PRDs because the PM didn't know to ask for them. She asked "what should the tool do?" not "how should the tool feel?"
When a developer on the platform team suggested tab completion, the PM said "that sounds like nice-to-have polish, let's prioritize features first." She was optimizing for the roadmap, not for daily usability. The roadmap moved forward, but adoption stalled.
Section 2: The Telephone Game of Specifications
Traditional product development involves a communication chain:
End User → Product Manager → Specification → Engineer → Implementation
Every link in this chain introduces translation loss. The user describes their need; the PM interprets it; the spec captures the interpretation; the engineer implements the spec. By the end, the implementation may solve a problem nobody has.
A Real Example: The CI Hook Request
An internal developer asked: "I want to run a custom script before my tests run."
The PM captured this as: "Users need extensibility in the CI pipeline."
The spec described: "A plugin system with a lifecycle hook interface supporting pre-test, post-test, pre-deploy, and post-deploy phases. Plugins will be registered via a configuration file and discovered at runtime."
The engineers spent three weeks building this plugin system. It was architecturally impressive.
The original developer didn't use it. It was too heavyweight for their actual need—they just wanted to run npm run prepare before tests. They eventually added a bash script that wrapped our CI command.
If the platform developer had talked directly to the internal developer, the conversation would have gone:
"What do you need?"
"I want to run npm run prepare before tests."
"Oh, you just need a pre-test hook. I can add an environment variable for that."
"Perfect."
One environment variable. Implemented in 30 minutes. Instead of a three-week plugin system nobody used.
Direct Communication Is Faster
When platform developers talk directly to internal customers, the feedback loop accelerates dramatically:
- No spec-writing delay (can happen in real-time conversation)
- No translation errors (both parties speak the same technical language)
- Immediate clarification (can demo, can share screen, can look at code together)
- Scope naturally right-sized (developers scope by implementation difficulty, PMs scope by perceived importance)
We eliminated weeks of overhead by removing the specification layer entirely for internal tools.
Section 3: Senior Engineers as Product Owners—Dogfood Economics
When we removed the PM, we told our Staff and Principal Engineers: "You now own the roadmap. You talk to users. You prioritize."
Some engineers protested: "I just want to code! I don't want to do product management!"
Most, however, thrived—once they realized what "product management for internal tools" actually meant.
They Are the User
Our platform engineers use our internal tools every day. They deploy code. They run tests. They debug pipelines. They don't need to interview users—they are users.
When a platform engineer feels friction ("This command is annoying"), they experience the problem viscerally. They prioritize fixing it not because a PRD told them to, but because they personally want it fixed.
"Dogfooding" stops being a checkbox activity. It becomes automatic.
They Prioritize What Matters
PMs often prioritize by perceived value to stakeholders—what will make leadership happy, what will look good in a quarterly update, what has the most requests in the feedback system.
Developers prioritize by impact-per-effort and pain severity. "This is a 30-minute fix that will save everyone 10 seconds per deploy" gets prioritized. "This is a three-month project with unclear ROI" gets pushed.
Our platform team started shipping more frequent, smaller improvements. Instead of quarterly "major releases," we had weekly quality-of-life updates. Each update was small, but they compounded. After six months, the tooling felt completely different—polished, responsive, developer-friendly.
They Can Make Technical Tradeoffs
A PM asks: "Can we add real-time streaming logs to the deployment view?"
An engineer thinks: "That requires WebSocket infrastructure, which we don't have. Polling would be simpler but add latency. We could use Server-Sent Events as a middle ground."
A PM-to-engineer conversation becomes a spec that says "must have real-time logs." The engineer then has to push back, or over-engineer a WebSocket system, or deliver something that doesn't match the spec.
When the product owner is an engineer, they make the tradeoff directly: "SSE is good enough. We'll get 90% of the benefit with 20% of the effort. Ship it."
Section 4: When You Still Need PMs—External Customers, Not Internal
We didn't eliminate PMs across our company. We still have them for customer-facing products—and they're essential there.
External Customers Are Different
Our external customers are accountants, marketing managers, HR professionals. They don't think like developers. We genuinely don't understand their daily workflows, their constraints, their mental models.
We need a PM to bridge that gap. Someone who does user research, translates business requirements into product requirements, and ensures we're solving real problems for people unlike ourselves.
The PM's value is gap-bridging. When there is a gap between builder and user, the PM bridges it.
No Gap = No PM Needed
For internal developer tools, there is no gap. The builders are the users. The platform engineers sit 20 feet from their "customers" (the product engineers). They share the same Slack channels, the same codebase, the same frustrations.
Adding a PM to this situation doesn't bridge a gap—it creates one. The PM becomes an intermediary where no intermediary was needed, adding latency and translation errors to previously direct communication.
The Decision Framework
Ask yourself: "Do the people building this tool deeply understand the daily lived experience of the people using it?"
- If yes: They can be their own PMs.
- If no: You need PM support to bridge the understanding gap.
Developer tools for developers: no PM needed.
Developer tools for non-developers: PM needed.
Non-developer tools for non-developers: definitely PM needed.
Conclusion: Build for Yourself, Eliminate the Middleman
Product management exists to solve a communication problem: builders don't understand users. When that problem doesn't exist—when builders and users are the same population—the solution is unnecessary overhead.
It's okay to teach a senior engineer how to prioritize a backlog. They can learn to balance competing requests, gather feedback, and make roadmap decisions. These are learnable skills.
It's much harder to teach a generic PM the nuances of a Kubernetes ingress controller, or why tab completion matters, or what makes a CLI feel "UNIX-y." This requires years of lived experience as a developer.
The domain expertise is harder to acquire than the process skills. Invest in the harder side.
For internal developer tools, let developers lead. Remove the intermediary. Build what you yourself need. The result will feel like it was made by someone who actually uses it—because it was.
When you're building for yourself, eliminate the middleman. Nobody knows what developers need better than developers.
Written by XQA Team
Our team of experts delivers insights on technology, business, and design. We are dedicated to helping you build better products and scale your business.