When Coding Is No Longer the Bottleneck, How Should Product Teams Rebuild the "Factory"?

When writing code becomes increasingly effortless, where does the bottleneck in product development shift? Ramp's Chief Product Officer Geoff Charles unpacks this question on Lenny's Podcast using an F1 racing analogy: winning a race was never about pushing the driver harder — it's about continuously finding and eliminating the bottlenecks around the driver.

He laid out the entire "product factory" Ramp has built around AI — from identifying problems and defining requirements to building, coordinating, and iterating. Every step has been broken down into an automatable unit. This methodology offers direct, practical lessons for every product team being reshaped by AI today.

From Racing to Product: Bottlenecks Shift, They Never Disappear

Geoff's core argument draws from a counterintuitive truth in motorsport: in professional racing, the driver accounts for only 15% of race performance. What truly determines victory is the systemic coordination between driver and car, and car and team.

He uses the pit stop as his example: changing a set of tires took 67 seconds in the 1950s; today it takes 1.8 seconds. That 37x improvement wasn't achieved by making mechanics work 37 times harder — it came from specialization, better technology, and relentless practice. At its core, it was about finding the bottleneck and redesigning the entire process.

He also drops a sobering number: of the 16,000 parts in an F1 car, 90% are replaced every year — only 10% carry over to the next season. "What if 90% of your code was rewritten every year? Because that's the standard."

Mapped onto the product world, Geoff defines a complete race track: "The clock starts the moment a pain appears, and stops the moment the customer has a product that solves it." AI hasn't eliminated bottlenecks — it's just pushed them from one stage to the next. The winners are the teams that can find bottlenecks faster, eliminate them, and race toward the next one.

Identify: Making Customer "Pain" Traceable

The first step in product development is identifying the problem. But Geoff points out that pain points are scattered across Gong call recordings, Zendesk tickets, LogRocket session replays, surveys, and even an angry email to an executive — context fragmented across countless information silos.

LLMs seem like the antidote, but he offers a sobering comparison: a one-million-token context window covers less than 0.5% of Ramp's total Gong call recordings.

Ramp's initial attempt was simple — they built a "complaint channel" and pushed all negative customer feedback into it daily. It quickly spiraled out of control. So they started over and built a real customer insight agent: using traditional ETL and data pipelines to pull from all company data sources, combined with vector search and clustering, trained to understand products, teams, and features, and made available across the entire organization.

They then pushed this data to as many people as possible — a Slack Q&A bot, HTML dashboards, and his personal favorite: a "complaint podcast" where you spend each morning listening to a hundred customers tell you exactly what's broken about your product.

He's clear that this doesn't replace talking to customers — it means you know precisely which customers to talk to, because every data point is traceable.

ETL (Extract, Transform, Load) is a data integration process that pulls data from multiple sources, transforms the format, and loads it into a target system — the standard infrastructure for enterprise-grade data pipelines. Vector search is a key technology in the LLM era: text is converted into high-dimensional numerical vectors, and similar content is retrieved by computing semantic distances between vectors rather than relying on keyword matching. Clustering is an unsupervised machine learning method that automatically groups large volumes of text into thematically similar categories — ideal for surfacing high-frequency pain patterns from massive amounts of customer feedback. By combining all three, Ramp is essentially resolving the tension between the physical constraints of LLM context windows and the sheer volume of enterprise data: using traditional engineering to structure and semanticize data first, then applying AI to understand and generate responses on precisely retrieved subsets, rather than attempting to stuff all data into a single conversation.

Define: Connect AI to Your Systems and Make It a Thinking Partner

Once you've identified what to focus on, the next step is turning a vague concept into a complete product definition. Geoff challenges the opening move of most AI tools: they always ask "what do you want to build?" — leaving you staring at a superintelligent agent wondering where to begin. Is that really the best starting point?

His answer: connect AI to your systems. Ramp built an AI agent called Glass for exactly this purpose, giving it all the context it needs to do the job — connected to data in Snowflake, fluent in user research, able to pinpoint the true "jobs to be done" customers need completed, and capable of combining qualitative and quantitative data for specificity.

Glass also understands Ramp's product strategy, how product specs are written, and the entire codebase. This means PMs no longer need to constantly interrupt engineers asking "can this be built? Will it break anything? What am I missing?" — AI becomes the PM's technical lead.

Geoff punctures a key "delivery contract" assumption: engineering teams don't actually want your prototype, and they don't want your lengthy spec — either one alone is useless. What they really want is a combination of all three: qualitative and quantitative data proving this is a real problem, actual requirements that coding agents can work with, and a prototype that actually runs in the product.

Build: Code Review and Testing — the Cascade of Bottlenecks Behind "Building"

"Building is no longer the bottleneck" has more layers than it appears. Geoff is candid: every time you solve one bottleneck, the next one surfaces immediately.

The first bottleneck was writing code. Ramp built its own coding agent, Inspect — and chose to build in-house specifically to own a powerful constraint harness and ensure the agent truly understands their codebase. It runs in Slack, responds within 5 seconds, and returns interactive deployment previews that PMs can try directly.

The numbers are striking: Inspect has accumulated over a million sessions, 75% of PRs are built by it, and in the past month alone, 1,000 PRs were submitted by non-engineers. But Geoff adds an important caveat — coding agents only work well when the architecture and codebase are solid enough to support them.

With more code being written, code review became the next bottleneck. They built ReviewBuddy, which understands the codebase, quality standards, and security concerns, can identify the right human reviewers, and can even read all the prompts used during the coding process — auditing how AI was used. Today, 93% of PRs are handled automatically by ReviewBuddy, freeing the best engineers to spend their time on the 7% that truly matters.

Next, testing became the bottleneck. They built Testo, a browser-based QA agent that spins up 100 different combinations using real production data and operates the product like an actual user. You give it instructions like "pay an invoice with amortization" and it clicks through, providing feedback — both blocking bugs and qualitative notes about whether the design experience is confusing. In the past 30 days, Testo caught 425 bugs.

A PR (Pull Request) is the code merge request mechanism in modern software development: after a developer completes changes on an independent branch, they submit a merge request to the main codebase, which is reviewed and must pass automated tests before being merged. CI/CD (Continuous Integration / Continuous Delivery) is the combined practice of automating the build, test, and deployment pipeline on every code commit, minimizing manual intervention. When Geoff mentions "1,000 PRs submitted by non-engineers," it means PMs, designers, and other roles are using Inspect to directly modify code and submit merge requests — something nearly impossible in traditional development workflows. The deeper implication: as code generation becomes reliable enough, quality gates in code review and testing become the decisive chokepoint for release velocity. This is precisely what put ReviewBuddy and Testo on the roadmap.

Coordinate: Making the Organization "Legible" to Agents

As products ship faster, Geoff sees the next bottleneck as human attention. PMs get buried in notifications; too much process slows down developers, and too little leaves everyone confused.

He offers a sharp organizing principle: "Every question is an API." Ramp built Gadget to understand the intent behind questions and connect them to the official record — roadmaps and specs in Notion, customer calls, Slack, and Linear tickets.

Here's a line worth sitting with: "To empower an agent, the agent must be able to read the entire organization. The organization needs to become legible to your agents."

For example: someone asks "how is this project going — are we on track?" The agent understands the full picture, knows who owns the next step, answers with evidence, and proactively updates the roadmap, sends status updates, and flags people who are delayed. Sales asks "is this feature available in Brazil? What does it cost?" — handled. When shipping, it can even draft help center articles, blog posts, and customer emails. Today, 85% of questions directed at PMs are answered completely by AI.

"Organization legibility to agents" is worth unpacking on its own. Legibility originally comes from political science and organizational theory, describing how institutions simplify complex realities into measurable, manageable standardized formats. Geoff borrows the term to mean that a company's internal knowledge, processes, and decisions need to be structurally stored in systems that agents can index and retrieve — roadmaps with clear formatting in Notion, tickets with standard fields in Linear, clear ownership attribution in Slack. If an organization's critical information lives in oral culture, email attachments, or people's heads, even the most powerful agent has nothing to read. This places a prerequisite demand on enterprises: AI adoption isn't just about deploying tools — it forces organizations to make tacit knowledge explicit and informal processes formal.

Iterate: Using Automation to Escape the "Small Loop" Trap

Geoff is blunt about a common PM failure mode — always being drawn to small, reactive tasks that deliver an instant dopamine hit. He considers this a serious mistake: "You need to automate yourself out of these small loops."

Ramp has AI running most of the small loops end-to-end: routing to the right team, matching against the backlog in Linear, deduplicating, counting, sorting, executing the plan — with human intervention only at the "is this ready to ship?" decision point in Slack, followed by automated code writing, test and CI/CD runs, deployment, and knowledge base updates. Humans are barely kept in the loop. Thanks to these autonomous cycles, 60% of UX issues are fixed within 24 hours.

Three Hard Questions and Three Evolutionary Paths for PMs

Facing a room of product practitioners, Geoff proactively addressed three challenges.

How do you know when you're fast enough and high-quality enough? He cites the story of Niki Lauda testing a Ferrari in 1974 — telling Enzo directly that the car was garbage, then working with the engineers to fix it. The point: hire a driver who truly knows what "fast" looks like, put them in a position to steer, and let them challenge you.

How do you compete against unconstrained companies when resources are limited? Geoff points to Audi: the car wasn't fast enough, so they focused on fuel efficiency instead — fewer pit stops, more time on track — and won Le Mans three years running. "Constraints force you to choose one dimension where you can be world-class. Embrace your constraints, but don't embrace your bottlenecks." Find the bottleneck where you can genuinely excel and drive 10x growth for the company, and start there.

Will PMs be automated away? He actually sees pulling PMs out of the many engineering-driven loops as a good thing — it creates enormous leverage. The PM role will evolve along three tracks:

• Technical PM: Builds the "factory" itself — identifies bottlenecks, removes organizational friction, and delivers products that help others build products.
• Tastemaker PM: Holds the wheel, does what AI can't, and maintains the standard for what great products and great taste look like.
• GM-type PM: Expands responsibilities beyond product into marketing, sales, growth, and operations — truly accountable for business outcomes.

Closing: The Best Product Is Always the Next One

Geoff closes with three takeaways: speed isn't about writing code faster — it's about identifying and eliminating bottlenecks in the build process; solving the first bottleneck immediately reveals the next, and your job is to move through them as quickly as possible; as a product leader, obsess less over the product you're shipping and more over the factory that helps you ship faster.

The most memorable moment is his final admission: "Everything I've shown you is already out of date. Just like in F1, teams copy each other. I hope you copy us — and then surpass us."

He closes with a line attributed to Enzo Ferrari: the best Ferrari is always the next one. The best product is always the next one you're about to ship. And it all starts with the software factory you build today.