The Curse of Being an Internal Tools PM

Ask anyone at Amazon about the internal tools they use all day and you’ll get some version of the same answer: they can’t stand the UX. Every level, every function. I felt exactly the same — right up until I became one of the PMs building them.

I’ve been an internal-tools PM. People have different ideas about what that job is, and most of them are a version of “the minor leagues.” It isn’t as sexy as launching something public-facing — who doesn’t want their product to come with a press release and real external users? And there’s a notion that the bar for internal products is low, because you have a captive user base and they don’t really have a choice.

Here are four of those assumptions, and what my experience actually taught me about each.

1. It’s not as glamorous as building for external customers. A little true.

It depends on what you built and what future you want. Some internal tools — Amazon’s supply chain systems, for instance — run at a scale and complexity most companies never touch, and are among the most advanced anywhere, internal or commercial. There are takers for that experience in the job market. And it’s certainly more glamorous than building yet another copy of an already popular app/service that does exactly what its next ten competitors already do.

2. It limits your job opportunities. True — with a caveat worth stating.

Your experience can get boxed into a niche. You’re usually not owning growth, top-of-funnel engagement, or GTM — the first things a company hiring for an external product looks for. And internal PMs tend to sit in large companies where the product has massive impact but the team you lead is small. Those things make a switch harder.

That said, an internal-tools PM still needs user empathy — and, I’d argue, a far deeper understanding of user needs than someone building for external customers. You’re not guessing at a faceless market; you sit next to the people who live in your product all day. And you still pull many of the same levers to build a successful product and drive real user adoption.

“Harder” isn’t “niche and done.” The judgment you build shipping products with no benchmark and no competitor to copy — deciding what’s worth building on qualitative signal alone — is exactly what a genuinely hard problem needs, external or not. The work doesn’t limit you as much as the framing does.

3. It’s easy to build for internal users. Yes and no.

Yes, because you have a captive user base — they have no option other than to use your tools. But there’s more to it. First, you don’t have an external benchmark or signals: no competitor to compare against or even borrow ideas from. Second, you’re often operating at the cutting edge of the field (again, Amazon’s supply chain systems are more advanced than what most companies run, so new product and feature ideas have to be invented by you. User feedback is another problem. You can’t look at engagement metrics to judge whether a product worked. Your best option is to talk to your users — your coworkers — directly. And therein lies the biggest problem: there’s no benchmark for success. That becomes acute when you’re proposing new features to your dev team. The first question is always “is this even required?” — and you’ll have qualitative responses at best, your intuition at worst (which, as I soon realized, isn’t a good enough reason to put a story into a sprint). Simply convincing your team to build something becomes far more complex.

4. Internal tools PMs don’t know how to build polished UI. That’s not true.

When I was a program manager, the UX of most of Amazon’s internal tools frustrated me — and, as I said, everyone hates it, at every level. Yet it stays crappy. The reason is simple: there’s usually no ROI for better UX. I learned that the hard way. Early on, I made some really sleek hi-fi mockups for the products I was building. The tech team shot them down, brutally. They built whatever they could with the least effort.

I met them halfway. I learned the UI framework and component library our internal teams used, and got a feel for the complexity our SDEs were comfortable with. Then I built my mockups from those same components — naming the exact component in the spec. That’s when I started getting UX that was almost 90% of what I’d asked for.

Could I have dreamt up better UX? Oh yes. Just to console myself, I’d build the sleeker version too, look at it, and keep it to myself — hoping that one day my time would come.

Some day.