Platform & Developer Experience
Developer Experience needs a product owner, not another tool
Most DX programs stall for the same reason: everyone agrees it matters, nobody owns it. I run developer experience as a product discipline, measured and defended like any customer-facing line. 10+ years across Revolut, GitLab, Jimdo, and Hermes Germany.
The Situation
Where DX Programs Get Stuck
Your DX initiative has a budget, a Slack channel, and no owner.
Engineers complain about tooling. Nobody can say what the friction costs the business.
The platform team ships steadily, but internal adoption is flat.
Leadership wants a number on developer productivity. You don't have one you trust.
The Work
Four Things a DX Product Owner Actually Does
Measurement that survives a board meeting
A compound index combining developer survey data with system signals like build times, review latency, and deploy frequency. Baselined, benchmarked against comparable orgs, reported quarterly next to commercial metrics. Not a vanity dashboard.
Platform as a product
Internal platforms get what customer-facing products get: a roadmap, named users, adoption targets, and someone accountable for outcomes. A ticket queue is not a product strategy.
Friction removal, ranked by cost
Local setup, CI duration, flaky tests, docs, review turnaround. Every candidate gets sized by what it actually costs in engineering hours, then prioritized against that. The loudest complaint is rarely the most expensive one.
Adoption and internal advocacy
A platform nobody adopts is a cost center with extra steps. Internal tools need onboarding, migration paths, and a reason to switch. That work is go-to-market, and it needs to be run like it.
The Method
The First 90 Days
Days 1-30
1.Baseline before opinions
Survey the engineering org, pull the system data, sit in standups and retros, read the incident history. I change nothing in month one. You cannot prioritize friction you have not measured, and a DX program that opens with someone's pet fix loses credibility it never gets back.
Days 31-60
2.Three visible wins
Fix the three most expensive things the baseline surfaced. Small enough to land inside a sprint or two, big enough that engineers notice without being told. These wins buy the patience needed for the structural work that follows.
Days 61-90
3.Make it durable
Ownership model, reporting cadence, and a roadmap that survives my exit. The measure of success is that DX stays on the leadership agenda after the engagement ends, and that someone in-house owns the number.
My philosophy hasn't changed in a decade: great platforms are invisible. If your developers have to think about the platform, it's still a product problem.
Track Record
Receipts, Not Theory
Engineering Culture
Making Developer Experience a Business Priority
Turned DevEx from an engineering-internal concern into a company-wide north star metric, moving a mid-sized SaaS org to the 75th percentile for developer experience in its cohort.
Reliability Engineering
Joining the Five Nines Club
Took infrastructure and APIs to 99.999% uptime in under a year, without a single customer-facing outage during the migration.
Founder / 0→1
Building RevoBill: From Side Project to SaaS
Designed, built, launched, and operate a SaaS product solo, taking it from zero to paying customers with no marketing budget.
Companies I've worked with
Engagements
How This Gets Delivered
Fractional
2-3 days a week · Typically 6-12 months
Embedded senior product leadership: roadmap, stakeholders, delivery. Part-time cadence, full accountability.
Interim
Full-time · Fixed term, 3-9 months
End-to-end cover for a product leadership gap: from first-week triage to a clean handover.
Advisory
A few hours a month · Open-ended
Sparring for founders and product leads: pressure-test strategy, unblock the hard calls.
Most DX work runs at a fractional cadence. If you need broader product ownership, see fractional CPO or interim Head of Product.
FAQ
Questions, Answered
Isn't Developer Experience an engineering problem?
Engineering owns the implementation. Nobody owns the prioritization, and that's why most DX programs stall. Deciding which friction to remove first, justifying the investment, and holding the org to a target is product work. Engineers are usually too close to the tooling to rank it by business cost.
What is a DXI and do I need one?
A Developer Experience Index is a compound metric: qualitative survey data combined with quantitative system signals, rolled into one number you can trend. You need something like it if leadership keeps asking about engineering productivity and the honest answer is a shrug. You don't need it if you already have a metric your CTO and CFO both trust.
How do you justify DX spend to a CFO?
In hours and risk, never in developer happiness. Slow builds and manual release steps convert into engineering time at a rate you can calculate. Poor onboarding converts into ramp-up weeks per hire. Reliability gaps convert into incident cost. Framed that way it stops being a culture ask and becomes a capacity argument.
Do you write code?
Not in your production repos. I read code, run your local setup, and go through onboarding as if I were a new hire, because that's the fastest way to find where the friction actually is. Your engineers build the fixes. I own what gets built and why.
How is this different from hiring a platform engineering manager?
A platform EM runs the team and the technical roadmap. I run the product side: who the internal customers are, what gets prioritized, how success is measured, and how the investment gets defended upward. The two roles work well together. One is not a substitute for the other.
How long before we see results?
Visible friction wins inside 60 days. A defensible baseline metric inside 90. Moving a full org into the upper quartile of its benchmark cohort took the better part of a year in my experience, because the hard part isn't tooling, it's changing how the business decides what engineering capacity is worth.
Put a Number on It
One discovery call: 30 minutes, no pitch. Bring your worst developer complaint and we'll size what it costs you.