Your Coworkers Are Developers Too: Product-Managing Internal Platform APIs

Internal developers are customers with a working alternative always in reach: their own code editor. If your internal platform api is harder to adopt than writing a shim around it, they will write the shim — and you'll have shipped a product nobody uses, just quietly, without a churn dashboard to warn you.

Quick Answer: Treat internal engineers as real customers with switching costs, measure adoption against the "workaround" alternative (not against zero), and use opportunity scoring to decide which internal platform apis deserve paved-road investment versus which can stay self-serve tickets.

Why internal developers are real customers, not a captive audience

Internal engineers behave exactly like external customers because they have the same three levers external customers have: budget (their sprint time), choice (build vs. adopt), and exit (a workaround that technically satisfies their ticket). Treat them as a captive audience and you'll discover, six months later, that half your org quietly forked your auth wrapper instead of calling it.

The mistake platform teams make is assuming mandate substitutes for merit. A CTO memo saying "use the platform team's API" changes behavior for a sprint. It does not change behavior for a year, because engineers under deadline pressure optimize locally: if your POST /internal/notifications endpoint takes four config fields and a Slack thread to get right, and a raw webhook call takes ten minutes, the raw webhook wins regardless of what the memo says.

This is the same dynamic Geoffrey Moore's crossing-the-chasm framing and the bottom-up PLG literature describe for external developer tools — adoption is won at the point of first use, not the point of announcement. If you haven't already, it's worth reading the case for bottom-up PLG selling through developers, because the psychology transfers almost unchanged to an internal audience: the only difference is your "sales team" is a Slack channel and your "pricing page" is a runbook.

What switching costs actually look like internally

External switching costs are subscriptions and contracts. Internal switching costs are invisible until someone quantifies them — which is exactly why platform PMs underestimate how much workaround-building is already happening.

• Time cost: hours spent reading source instead of docs because the docs don't exist or are stale.
• Cognitive cost: needing to understand your internal implementation details to use your "abstraction" correctly — the abstraction leaked.
• Political cost: escalating a platform limitation feels riskier than quietly working around it, especially for a mid-level engineer who doesn't want to be "that person" filing tickets.
• Compounding cost: once a team builds a shim, every future engineer on that team inherits it as the path of least resistance — the workaround becomes the new default, invisibly.

That compounding cost is the one platform PMs miss most. A single team's decision to skip your API isn't a data point — it's a seed. Left unaddressed, forked patterns spread through code review copy-paste and onboarding docs faster than any platform announcement can counter them.

The paved road philosophy: make the right path the easy path

A paved road is an internal platform's answer to a governance problem: instead of banning the workaround, you make the sanctioned path measurably faster, safer, and less effortful than any alternative, so engineers choose it because it's genuinely better — not because they were told to.

The term comes out of Netflix's and Spotify's platform-engineering writing, and it's deliberately not "the only road" — a paved road coexists with the freedom to go off-road, but going off-road should feel like a real decision with real tradeoffs, not the default because the road was never built. If the paved road requires a design review, three approvals, and a two-week SLA to get access, you haven't paved a road — you've built a tollbooth and called it infrastructure.

The three properties a paved road actually needs

Most internal platforms fail one of these three, and any single failure is enough to push engineers to a workaround:

1. Genuinely faster time-to-first-success. Not eventually faster once mastered — faster on the first attempt, because that first attempt is when the adoption decision gets made. This is the internal analog of what public API teams track as developer time to first call, and the discipline transfers directly: measure minutes from "I found this exists" to "I got a working response," not from "I started reading the spec."
2. Documentation that assumes zero platform-team context. Internal docs routinely assume the reader already knows the system, because the docs were written by the people who built it. Treating internal docs with the same rigor covered in docs as product, not afterthought is the single highest-leverage fix most platform teams haven't made.
3. A support model that doesn't gatekeep. If getting unstuck requires a Slack DM to a specific engineer who might be on PTO, the paved road has a bus-factor problem that a workaround doesn't.

A paved road that's slower, worse-documented, or harder to get unstuck on than a workaround isn't a paved road — it's a suggestion, and suggestions lose to deadlines every time.

Paved road vs. workaround: what engineers are actually weighing

Engineers rarely articulate this comparison explicitly — it happens in the fifteen seconds after they hit an error and decide whether to keep debugging your API or write their own call. Making the comparison explicit is useful precisely because it's usually implicit.

The right side of that table is where shims are born. Every row where the workaround looks better than your paved road is a row your roadmap should be fixing before you fund anything new.

An opportunity-scoring approach for platform investment

The fastest way to lose credibility with engineering leadership is prioritizing platform work by whoever complained loudest this sprint. Opportunity scoring fixes this by separating importance from current satisfaction — the gap between the two is where investment actually pays off, and it's borrowed directly from Anthony Ulwick's Outcome-Driven Innovation methodology, adapted from external customer jobs to internal engineering jobs.

The mechanics, applied internally, look like this:

1. List the jobs, not the features. "I need to authenticate a service-to-service call" is a job. "OAuth2 client credentials endpoint" is a feature someone guessed solves it. Frame every candidate platform investment as a job an engineer is trying to get done, following the same discipline covered in the jobs-to-be-done complete guide.
2. Score each job on importance (1-10, "how critical is getting this right to your team's velocity") and satisfaction (1-10, "how well does the current paved road or lack thereof serve this job").
3. Compute opportunity score: Importance + max(Importance − Satisfaction, 0), Ulwick's original formula. A job scoring 9 importance and 3 satisfaction (opportunity = 15) is a screaming underserved need. A job scoring 9 importance and 8 satisfaction (opportunity = 10) is already well served — resist the urge to gold-plate it.
4. Rank and fund the top decile, not everything above the median — platform teams have finite headcount, and opportunity scoring is only useful if it forces triage.

Where to source the importance and satisfaction data

Scores are meaningless if they come from the platform team's own guesses about what engineers need — that just re-imports the loudest-complainer bias with extra math. Real signal comes from three sources:

• Structured interviews with engineers across teams, not just the ones already vocal in your Slack channel — the quiet teams building silent workarounds are the ones you most need to hear from.
• Support ticket and code-search mining: how often does a job show up as a recurring Slack question or a recurring pattern in internal repos (a strong tell that people are solving it themselves).
• Adoption telemetry on existing paved roads: if usage of an existing endpoint plateaus or declines while the underlying job clearly still exists org-wide, satisfaction is dropping even if nobody filed a complaint.

Combine those three and you get a defensible, repeatable prioritization list — one you can show a VP of Engineering without it reading as platform-team opinion dressed up as a spreadsheet.

A real pattern: internal APIs that win because they're actually easier

The clearest wins in platform history share one trait: adoption grew because the paved road was less work than the alternative, full stop — not because of a mandate. Consider the well-documented shape of internal feature-flagging and internal service-mesh rollouts across companies like Uber, Airbnb, and Netflix, chronicled in their public engineering blogs.

Before a centralized feature-flag service exists, every team invents its own: a config file here, an environment variable there, a homegrown percentage-rollout hack somewhere else. The moment a platform team ships a flagging API where checking a flag is a single function call with sane defaults and instant propagation, adoption tends to follow a predictable curve: teams already mid-crisis with their own flaky homegrown flag system migrate first, because their workaround's maintenance burden has become visible pain, and the paved road's savings are immediate and legible. Teams with no flagging at all adopt next, because building their own now looks strictly worse than a five-minute integration.

The teams that hold out longest are the ones with a workaround that's merely adequate — good enough that switching costs (however invisible) outweigh the platform's marginal improvement. That's the signal a platform PM should watch for: partial adoption plateaus are not solved by more advocacy — they're solved by asking the holdout teams what their workaround still does better, and then closing that specific gap.

Why this generalizes beyond feature flags

The same mechanic explains internal adoption of centralized logging, CI pipelines, and design-system component libraries: the winning pattern is never "we announced it," it's "the old way visibly got harder to maintain while the new way visibly got easier to start." Two curves crossing, not one campaign landing.

Mapping that adoption curve honestly is the same discipline covered in the customer journey complete guide — engineers move through awareness, evaluation, first use, and habitual use exactly like external customers do, just measured in pull requests instead of purchases.

Where Prodinja fits into this

Key Takeaways

• Internal engineers are customers with real switching costs — a shim is their exit option, and it's always cheaper for them to build than for you to notice.
• A paved road only works if it's genuinely faster, better-documented, and better-supported than the workaround — mandate alone doesn't survive contact with a deadline.
• Opportunity scoring (Importance + max(Importance − Satisfaction, 0)) separates real underserved needs from loud-but-already-served ones, so platform investment gets prioritized by evidence, not volume.
• Source scores from interviews, ticket/code-search mining, and adoption telemetry — not from the platform team's own assumptions about what engineers need.
• Adoption wins happen when two curves cross: the workaround's maintenance pain rising while the paved road's onboarding cost falls — not from an announcement alone.
• Partial adoption plateaus signal a specific remaining gap, not a need for more advocacy — ask holdout teams what their workaround still does better.
• Treating internal docs, time-to-first-call, and journey mapping with the same rigor as external developer products is the fastest way to close that gap.