The Traps of Borrowed Internal Developer Platform Roadmap Certainty
Delivery is the start, not the end, for testing your roadmap beliefs
This enchiridion entry follows on from, and is related to, these two previous entries:
The trouble with product roadmaps is not that they are wrong. It is that they are certain.
They sit there, smugly laminated in slides and strategy decks, marching confidently through quarters not yet lived, problems not yet observed, and constraints not yet discovered. Q2: Platform Self-Service. Q3: Golden Paths. Q4: Developer Nirvana. It all looks so… inevitable. As if the future itself has already agreed to the plan.
This is, of course, nonsense. The future has not agreed to anything. The future rarely even returns emails.
Every roadmap step begins life not as a fact, nor as a truth, nor even as a particularly well-behaved idea, but as a belief. A hunch. A story we tell ourselves in order to get on with the day. “If we build this, things will be better.” Better how? For whom? Compared to what? What problems, if any, are we addressing? What constraints are being weakened to unleash flow? These details are often considered impolite to ask when the roadmap is being developed, let alone once the roadmap has been published.
And yet belief is unavoidable. Without belief, nothing starts. Without belief, no platform is built, no product is launched, no service or capability shipped, no experiment run. Belief is the price of entry to action. The danger begins when belief quietly puts on a borrowed lab coat and starts answering to the name certainty.
“We confuse coherence with correctness, plausibility with proof, confidence with care.”
In tech, we are particularly vulnerable to this costume change. We live in an industry intoxicated by fluency. The well-phrased argument. The confident diagram. The AI-generated explanation that sounds as if it has read the documentation, the literature, and your mind. We confuse coherence with correctness, plausibility with proof, confidence with care.
The internal developer platform roadmap is especially at risk. It is often abstract enough to escape immediate falsification, noble enough to discourage questioning, silently received enough to mask signals, and strategic enough to be insulated from day-to-day developer reality. When certainty is borrowed—from industry talks, vendor blogs, other companies’ diagrams, or increasingly from AI—it travels quickly and unquestioned. “This is what good looks like.” “This is the maturity model.” “This is the path.” “Our product is essential to your platform!”
The problem is not that these things are always wrong. The problem is that they are rarely yours.
“Delivery becomes the goal rather than the test.”
Certainty, once borrowed, is remarkably resistant to evidence. Metrics become decorative. Research becomes confirmatory. Delivery becomes the goal rather than the test.
And after shipping, something curious happens: nobody looks back. The belief has been promoted. The roadmap item is now history. Whether it helped or harmed flow is an awkward question best left unasked.
This is how organisations accumulate not just technical debt, but epistemic debt—a quiet pile-up of untested assumptions, frozen beliefs, and unexamined claims that feel solid only because they have not been disturbed.
A platform built on borrowed certainty does not fail loudly. It succeeds just enough to avoid scrutiny, while quietly missing the point.
This is not an argument against roadmaps, platforms, or belief. It is an argument for humility, for discipline, and for treating certainty as something to be earned, temporarily, through evidence—and revoked the moment reality disagrees. And to go, deliberately, to look for falsifying evidence, not just belief confirmation.
Because the job of an internal developer platform is not to make the future look tidy.
It is to learn, relentlessly, how work actually, really, flows. And to bring real change that helps it.
Every roadmap step is a belief — Wisdom lies in remembering this long after the slide deck is finished
Internal Developer Platform (IDP) roadmaps often suffer from borrowed certainty: the unexamined elevation of beliefs into facts, imported from elsewhere, insulated from evidence, and never properly tested against reality.
When roadmap steps are treated as truths rather than hypotheses:
Teams optimise delivery over learning
Evidence is gathered selectively, if at all
Negative impacts on developer flow go unseen
Platforms accrete features rather than insight
The result is a platform that looks mature while remaining epistemically fragile and, unless you’re very lucky, lacking real valuable impact.
From Belief to Hypothesis
Every roadmap item begins as a belief:
“If we build X, developer flow will improve.”
This belief must graduate, not ossify. A defensible roadmap step explicitly captures:
The belief – what we think will happen
The evidence so far – research, data, observations
The business alignment – why this matters now
Assumed mechanisms – how change is expected to occur
Expected impacts – positive and negative for a balanced narrative and steer to evidence-seeking
Until this is done, the roadmap is a comfortable fiction that has the tendency to drift into tragedy.
Evidence Is Not Proof (and Never Will Be)
Evidence is partial. Messy. Context-laden. It does not confer certainty—it can reduce surprise.
Good platform teams ask:
What evidence supports this belief?
What evidence contradicts it?
What do developers actually struggle with today?
Where does flow stall, slow, or fracture?
Evidence does not end debate, it sharpens it.
Roadmap Steps as Experiments
A roadmap item is not a promise. It is an experiment in belief-testing.
Each step should define in advance:
What success would look like
What failure would look like
What signals we will observe
What would cause us to change course
Shipping without measurement is not delivery—it is abdication.
The Importance of Falsification
Looking only for positive confirmation is how certainty hardens into dogma.
Actively seek out those signals that hurt your beliefs:
Increased cognitive load
Workarounds and shadow tooling
Slower onboarding despite “self-service”
Reduced autonomy disguised as standardisation
Negative evidence is not a threat, it is the engine of learning.
The Borrowed Certainty Trap
Borrowed certainty enters when teams:
Import roadmaps from other organisations
Accept fluent AI-generated plans uncritically
Treat industry norms as universal laws
Reward confidence over curiosity
Borrowed certainty feels efficient. It is, in fact, epistemic outsourcing.
Some practices to consider for a healthier IDP roadmap
Label epistemic status explicitly — Belief → Hypothesis → Tested → Disproven
Tie every roadmap item to flow friction — No friction, no problem, need for much more justification.
Instrument before you build — If you can’t observe change, you can’t claim impact.
Review post-delivery as rigorously as pre-delivery — Learning happens after shipping.
Retire beliefs publicly — Disproven ideas are progress, not failure.
A good internal developer platform roadmap is not confident. It is careful, curious, and willing to be wrong.
Certainty should never be borrowed wholesale. It should be earned briefly—and surrendered often. That is how platforms learn and this is how flow improves.
Build less certainty.
Build more learning.
If you enjoyed this enchiridion entry, it would be great to meet you in real life at these conferences and workshops:
DevOpsCon Amsterdam - Two Day Mastering Platform Engineering Bootcamp – From Design to Value
JAX London 2026 - Two Day Mastering Platform Engineering Bootcamp – From Design to Value
DevOpsCon San Diego - Two Day Mastering Platform Engineering Bootcamp – From Design to Value
UberConf 2026 - Hands-On AI Agent Engineering - Habits for safe, explainable, domain-grounded AI
UberConf 2026 - Mastering Platform Engineering: From Design to Value