Build the Factory, Not Just the Product: How Ramp Chases Bottlenecks Across the Whole Development Loop

Charles opens with a story about racing in the 24 Hours of Lemons, where you buy a $500 car and try to survive a day of racing. He crashed hard, and he uses the episode to make a point: in professional racing the driver is only about 15% of the impact, and the rest comes from the interaction between driver, car and team. Even the best drivers can only perform up to the level of the system.

The pit stop is his main example. Changing tires took 67 seconds in the 1950s and takes 1.8 seconds today, and that did not happen by asking mechanics to work 37 times harder. Teams found bottlenecks and iterated on them with specialized functions, better technology and more practice. F1 is relentless about it, with only about 10% of the 16,000 parts in a car carrying over each year.

Charles asks leaders to imagine what it would mean if 90% of their code changed every year, because that is the bar. For a product team, he says, the clock starts when a customer has pain and stops when they have a product that solves it. AI removes a bottleneck but also moves it, so the winning team is the one that finds the next bottleneck fastest.

Engineers have automated much of their work, so the constraint has shifted to the rest of the loop: identify, define, build and improve. There is more to define, coordinate, test and release than ever. His advice to product people is to be as lazy as engineers and invest in their own factory, because the speed of that loop decides the race.

The first bottleneck is sifting through noise. Customer pain is scattered across Gong, Zendesk, LogRocket, surveys and angry emails to executives, and a one-million-token window holds less than 0.5% of Ramp's Gong transcripts. Ramp first tried a Slack "hate channel" posting daily customer complaints, which got out of hand, so the team rebuilt it from scratch.

The result is a customer insight agent that pulls from every data source using traditional ETL pipelines, vector search and clustering. It understands Ramp's product, teams and features, and the whole company can access it. Ramp then experimented with delivery formats including a Slack agent, an HTML dashboard and, as Charles's favorite, a "hate podcast" that plays customer complaints. The goal is not to skip customer conversations but to pick exactly which customers to talk to, since the data is traceable.

For defining the product, Charles argues that a generic AI asking "what do you want to build?" is a poor starting point. Ramp built an agent called Glass that connects to Snowflake, user research, product strategy, spec formats and the codebase. A PM can ask it whether something is possible or would break something, instead of interrupting an engineer, and use it as a tech lead and thought partner.

Glass can also build a working prototype that respects Ramp's product principles and design system. Charles says engineers don't want a standalone prototype or a long spec. They want the combination of qualitative and quantitative evidence, concrete requirements for their coding agents and a prototype to be inspired by, which he calls the next contract.

Ramp built its own coding agent, Inspect, so it could control the harness and make sure the agent really understood the codebase. It runs inside Slack, is fully provisioned and returns a deployed preview so product managers can use what was built. According to Charles, Inspect has had a million sessions and writes 75% of Ramp's PRs, and a thousand PRs last month came from non-engineers.

His tip is that coding agents work best on a strong architecture and codebase, which expands how much of the company can use AI. But more code means review becomes the bottleneck. Review Buddy knows the codebase, quality checks and security concerns, finds the right human reviewer and can audit the prompts that produced the code. It handles 93% of PRs automatically, leaving top engineers to focus on the 7% that carry real risk.

Testing was next. Instead of PMs spinning up QA environments and clicking through screens, Ramp built Testo, a browser-based QA agent. It runs the product in around 100 combinations based on production data and acts like a user, for instance paying an invoice and amortizing it. It reports blocking bugs and also thoughtful design feedback on confusing flows or breaks from the design system.

Testo's findings feed back into the development loop. Charles says it caught 425 bugs in the last 30 days, which he considers better found by Ramp than by customers. Shipping at this pace creates the next problem, which is making sure everyone stays informed.

With so much shipping, Charles says the scarce resource becomes human attention, and PMs drown in notifications. Too much process slows builders, while too little leaves everyone confused. His principle is that every question is an API. You design a system that understands the intent of a question and connects it to the formal record, such as roadmaps, specs and customer calls in Notion, plus Slack and Linear tickets.

Ramp's agent for this is called Gadget. Asked about a project's status or whether a launch is on track, it understands who owns the next steps and answers with evidence. It also updates the roadmap, posts status updates and pings people who are late. Sales can ask whether a feature is available in Brazil or how to sell it, and Gadget routes to a person when it doesn't know.

Gadget can also help with launches by drafting help center articles, blog posts and customer emails. Charles says 85% of the questions asked of PMs are now fully answered by AI, and unanswered ones are fed back into the system. His advice is to start in one place and watch it expand.

The last piece is automating the small things. Charles says PMs gravitate toward small, visible, reactive wins, and that is a mistake if you want to be ambitious. At Ramp an AI routes an issue to the right team, matches it to the Linear backlog, dedupes, ranks and plans it, checks in with a human on Slack, writes the code, runs tests and updates the knowledge base. Thanks to these loops, 60% of UX issues are fixed within 24 hours.

Charles takes three questions from the audience's likely thoughts. On measuring speed, he notes it is harder than a lap time. His answer is to hire a driver who knows what real speed looks like, put them in charge and let them challenge you, as Niki Lauda did when he told Ferrari their car drove poorly.

On limited budgets of engineers or tokens, he cites Audi's slow car in 2006. Unable to go faster than rivals, the team focused on fuel efficiency, stopping less and spending more time on track, and won three years in a row. His lesson is to embrace constraints but not bottlenecks, and to pick the one bottleneck you believe could 10x your company.

On the future of product, Charles says he is not scared that loops run without PMs, because that gives leverage. He sees three tracks. The technical PM builds the factory and removes drag, shipping the product that helps build the product. The tastemaker is the driver who holds the steering wheel and the quality bar, and the GM extends beyond product into marketing, sales, growth and operations to own business outcomes.

He recaps three takeaways: speed is about finding and removing the bottleneck, each solved bottleneck reveals the next, and product leaders should obsess a bit less about the product and more about the factory. He adds that everything he showed is already outdated and invites others to copy and surpass it. Quoting Enzo Ferrari that the best Ferrari is the next one, he says the best product is the next one, and it starts in the software factory.