How Ramp Rebuilt Its Product Org Around AI

Geoff Charles, Ramp's chief product officer, has a phrase that keeps surfacing in his conversation with Rex Salisbury: "it's not about the solution you've built, it's about the problem that you own." He says it in the context of Ramp's data querying stack — a journey from SQL to Looker to Slack bots to Snowflake CLI to custom semantic engines, each layer deliberately replacing the last — but the logic bleeds into everything. How they hire. How they structure teams. What a product manager is even for anymore.

The picture Charles paints is of a company that has done something genuinely hard: built an institutional culture where engineers are expected to obsolete their own work. Whether that's as clean in practice as it sounds in a podcast conversation is a real question — but the structural reasoning behind it is coherent enough to engage seriously.

The DRI as answer to an old governance problem

The central mechanism Ramp uses to distribute product ownership without inflating PM headcount is the DRI — directly responsible individual. The idea, as Charles explains it, is that any product initiative gets one named owner regardless of their title. FedRAMP compliance was driven by an engineering function. A site rebrand was owned by brand and design. "We only have 22 PMs at Ramp," Charles says. "We have 1,600 people with 22 PMs."

People in open-source governance will find this familiar in both the good and the uncomfortable ways. The Apache Foundation has used a similar model for decades — one committer who holds the thread, accountable even when the work is distributed. The Linux kernel's maintainer hierarchy is essentially a DRI stack. Kubernetes SIG leads operate on the same premise. The model works when the accountability is real and when the DRI has genuine authority, not just the title. It breaks when "ownership" becomes a label that gets applied after the fact to whoever was left holding the work.

Charles seems aware of this. He's explicit that the failure mode is accountability without authority: "If something goes wrong, if a customer is not happy, if the product isn't performing, if we're not making enough revenue, that one person needs to be accountable." What he doesn't dwell on — and this is the gap the model has always had — is what happens when a DRI nominally owns a problem but has to work through processes, teams, and constraints they don't control. That's not a Ramp-specific failure mode. That's the governance problem every distributed organization eventually hits.

The engineers who built the thing that got replaced

Charles tells a story about Ramp's internal research tool. The data team built a version, another team built a better one, and the data team looked at it and said: "Yep, this is better in every regard. We're going to sunset ours."

He presents this as a cultural success — and in a narrow sense it is. The team didn't defend their work for its own sake. They evaluated on outcomes. That's genuinely hard to achieve at scale.

But I've spent time in developer communities where this cycle plays out without the clean resolution. The open-source graveyard is full of projects that got "sunsetted" because a better-resourced team built a faster version — and the original maintainers didn't sit down and graciously acknowledge the superior work. They burned out, felt erased, and stopped contributing to anything. The difference at Ramp is that Charles is describing an employment relationship with aligned incentives — the engineers who get replaced are still employed, still working on problems, not abandoned volunteers watching their years of unpaid work get deprecated by a VC-funded foundation.

That distinction matters. But it doesn't fully neutralize the human cost. Anyone who has shipped something and then had it shelved knows the specific low-grade grief of it — the thing you built is running somewhere in production, or it was, and now it isn't, and the next one probably won't be either. Charles's framing asks engineers to hold their work loosely, to care about the problem rather than the solution. That's a real skill and a real ask. Whether Ramp has actually built the psychological safety that makes that feel okay rather than just being expected of people — he doesn't go there. The AI coding velocity question is partly a technical problem; the human side of it is governance and morale, and they're not separable.

The proficiency ladder and the talent gap

Charles describes Ramp's internal AI framework in three levels: L1s have customized agents with their own context and instructions. L2s have automated end-to-end workflows — a full product release process, quality-controlled. L3s are the system builders, the ones building the tooling that lets everyone else operate at L2.

The expectation is that the whole company reaches at least L1, most people get to L2, and Ramp finds and invests in the L3s. It's a clean framework. It also highlights a real staffing problem Charles is candid about: there just aren't many people who are genuinely at L2 or above right now in the PM market. "The talent pool is much smaller," he says, and his preference is internal promotion — people who came up through product ops, customer-facing roles, the CX team. Ramp identifies a CX agent who became the company's top token user; that person becomes a candidate for a product role.

This preference for slope over pedigree is one of the more interesting structural positions Charles takes. In a market where the definition of "good PM" has shifted faster than any portfolio could track, external credentials are mostly noise. The person who has been building internal tools, shipping in the current environment, demonstrating judgment with the actual tools — that person is legible in a way that a résumé listing past companies isn't. The AI adoption gap between companies is partly an identification problem: winners are finding capability inside their existing orgs, not buying it from outside.

What gets automated and what's left

The conversation gets genuinely interesting when Charles talks about what management was actually for. His answer: information synthesis and context distribution. A management layer existed partly to compress knowledge upward and fan it back out — to summarize team updates, route context to the right people, make sure the CPO had a working picture of what was happening across the org.

All of that, Charles says, is now automated. Agents scrape Slack channels, generate Notion summaries, route them to the right people by role. "My job isn't necessarily context gathering anymore," he says. What's left for managers is end-to-end ownership at senior IC level, and talent development — hiring, training, firing. He thinks that's scalable to 10-15 direct reports, which is why he's planning to move from seven to somewhere around 10-12 directs.

The logic is consistent: if the coordination tax goes down because teams have larger scope and fewer interdependencies, and if information synthesis is automated, then the reason to have many layers of management largely disappears. You flatten not because you're cutting people but because the justification for the layers has evaporated.

Where this gets complicated is the same place it always gets complicated in flattened orgs: coaching, disagreement resolution, and the slower human work of developing someone who isn't yet good. AI can summarize a Slack channel. It cannot, at current capability, tell a junior PM that the way they communicated that roadmap decision damaged their relationship with the engineering team and here's how to think about fixing it. Charles doesn't claim it can. But the pressure to reduce layers can crowd out exactly that kind of management if you're not careful about it.

The hackathon as organizational mirror

Ramp's internal hackathon — Charles describes 300 individual submissions deployed to their internal environment, evaluated by a scoring LLM that surfaced the top 20 for live judging — is the piece of this story that lands differently when you look at it through a community lens rather than just a product management lens.

The structure Charles describes is actually closer to how healthy open-source communities run contribution drives than how corporate hackathons usually work. Individual submissions, not team projects. Opt-in participation with a lightweight signal (a Slack thumbs-up). AI mentors paired with non-technical builders at a 1:10 ratio. Groups organized around themes to share context, but each person building their own thing. The scoring automated, the judgment public.

That structure matters. The classic corporate hackathon failure mode is that it produces demos that get applauded and then never shipped, because there's no pathway from "impressive prototype" to "thing someone owns." Charles explicitly addresses this — submissions went to Ramplify, a real deployment environment with environment variables and security, not a slide deck. The DRI model is presumably the mechanism that turns a hackathon win into an actual product initiative. Whether that handoff reliably happens is a question for Ramp's next year of hiring.

---

For the mid-level PM who reads this and recognizes themselves — the person who's been doing reasonable work in a reasonable org and is now looking at a job description that asks them to demonstrate they can "build with AI" on a live exercise — Charles's advice is to stop managing upward and get extremely good at the craft again. He's blunt about it: "it's probably the worst time right now to be managing anyone unless you love management." Go back to IC. Ship something. Figure out the new stack personally before trying to coach anyone else on it.

That's not comfortable advice. I've seen what the transition cost looks like in developer community Slack channels: people who spent years getting good at the old version of this job — the stakeholder alignment, the roadmap strategy, the careful management of engineering relationships — now facing an interview process that starts with "prove to me in real time that you can build." The craft has moved. The question isn't whether you were good at the old version; it's whether you can get good at the new one fast enough to matter. Some people will. Some won't. And in communities built around craft, we tend to underestimate how much that asymmetry costs the people on the wrong side of it.

— Dev Kapoor, Open Source & Developer Communities