Geoff Charles: The Future of Product Management Is Building the Factory, Not Just the Product

For years, software teams treated engineering capacity as the constraint.

Ideas were plentiful. Customer problems were plentiful. Roadmaps were overflowing.

The scarce resource was the ability to actually build.

AI is beginning to change that equation.

In a talk about how Ramp approaches product development in the age of AI, Ramp Chief Product Officer Geoff Charles argued that making coding dramatically faster doesn’t eliminate the constraints inside a company. It simply exposes the next ones.

And for entrepreneurs, that distinction matters.

Because the companies that win in the AI era may not be the ones that generate code fastest. They may be the ones that become exceptionally good at discovering where work is getting stuck—and redesigning the organization around that constraint.

Speed Is a Systems Problem

Charles opened with a comparison to racing.

In Formula 1, winning isn't simply a matter of finding a driver willing to push harder. Performance comes from the entire system surrounding the driver: the car, mechanics, technology, processes, and pit crew.

A pit stop that once took more than a minute can now happen in less than two seconds.

That improvement didn't come from asking mechanics to work dozens of times harder. It came from redesigning the system.

Charles applied the same logic to product teams.

“Winning the race is about removing the bottlenecks around the driving.”

For a startup, the clock starts when a customer experiences pain and ends when that customer has a product that meaningfully solves it.

AI can compress pieces of that journey.

But as one stage gets faster, another becomes the constraint.

That is the management challenge founders need to understand.

When Coding Gets Faster, Everything Around Coding Matters More

The traditional product-development process might look something like this:

Identify a problem. Define the solution. Build it. Test it. Launch it. Improve it.

Historically, the “build it” stage consumed an enormous percentage of the effort.

Coding agents are changing that.

Charles said Ramp built an internal coding agent called Inspect that understands the company's codebase and can produce working deploy previews. According to the figures he shared in the talk, Inspect had been involved in roughly 75% of Ramp's pull requests, while employees outside engineering had submitted around 1,000 AI-assisted PRs during the previous month.

Once more people could produce code, however, the organization encountered a predictable consequence:

More code had to be reviewed.

Then more product had to be tested.

Then more launches had to be coordinated.

Then more employees needed answers about everything that was suddenly changing.

The bottleneck moved.

That pattern contains an important lesson for early-stage founders: automating one function without redesigning the surrounding workflow can simply move congestion somewhere else.

The goal isn't isolated automation.

The goal is throughput.

Start by Building a Better Problem-Identification Machine

One of Ramp's first challenges was simply understanding what customers were experiencing.

Feedback lived across Gong calls, Zendesk tickets, product analytics, surveys, emails, and other systems.

The problem wasn't a lack of information.

It was fragmentation.

Ramp responded by building a customer-insights system that could pull information from multiple sources, cluster related feedback, and connect those insights to the company's product context.

The important idea isn't that every startup should immediately build a sophisticated internal AI platform.

It's that founders should think carefully about the information architecture surrounding customer pain.

Ask yourself:

• Where does customer feedback actually live?
• Who sees it?
• How quickly does it reach the people who can act on it?
• Can recurring problems be distinguished from one-off complaints?
• Can you trace an insight back to the customers who experienced it?

Charles emphasized that AI shouldn't replace customer conversations. Instead, better systems should help teams determine which customers are most important to talk to next.

That's a much more practical use of AI than asking a generic chatbot, “What should we build?”

AI Becomes More Valuable When It Understands Your Company

Ramp took the same principle into product definition.

Charles described an internal system called Glass that connects product work with company context: user research, quantitative data, product strategy, specifications, the codebase, and Ramp's design principles.

That context changes what an AI system can do.

Instead of operating as a generic brainstorming partner, it can help a product manager investigate questions such as:

Will this idea conflict with something already in the product?

What does the data say about the customer problem?

How would this fit the existing architecture?

What requirements would engineering actually need?

Can we create a prototype consistent with the current product?

Charles's broader point was straightforward:

“The goal with AI is to connect it to your systems.”

For founders experimenting with AI, this may be one of the most useful principles in the entire talk.

A powerful model with no organizational context is still guessing.

A model connected to your company's actual customers, strategy, product decisions, documentation, and workflows can become something closer to infrastructure.

Every Automation Creates the Next Question

Ramp continued applying the same bottleneck philosophy.

When code review became a constraint, the company built ReviewBuddy to automate much of the review process and surface the work most deserving of human attention.

When quality assurance became a constraint, it created Testo, a browser-based QA agent that could interact with the product like a user and identify bugs or confusing experiences.

When coordination became a constraint, Ramp built systems capable of answering questions about projects, launches, product capabilities, and internal documentation.

Charles summarized one of the principles behind that approach with a memorable line:

“Every question is an API.”

In other words, recurring organizational questions are signals.

If employees repeatedly ask:

What's the status of this project?

Is this feature available?

Who owns the next step?

When is this launching?

What should I tell a customer?

…there may be an underlying information system waiting to be built.

For small companies, that doesn't necessarily mean building an autonomous agent for everything.

It means noticing repetition.

Repeated manual work is often the first clue that a bottleneck is becoming structural.

Automate the Small Loops So Humans Can Work on the Big Ones

Charles also warned product teams about something that entrepreneurs will recognize immediately: the temptation to spend time on highly visible, easily solvable problems.

Small fixes feel productive.

They provide certainty.

They create momentum.

And they can consume an enormous percentage of a team's attention.

Ramp's approach is to automate more of those small feedback loops so that humans remain focused on larger, more ambiguous problems.

According to Charles, roughly 60% of UX issues identified through customers, sales, customer experience teams, or Ramp employees were being resolved within 24 hours.

Whether another company could reproduce that exact result isn't the main point.

The strategic lesson is that automation should buy back ambition.

If AI saves a founder ten hours per week only for those ten hours to be filled with more administrative work, very little has changed.

The real opportunity is to redirect that capacity toward problems that previously seemed too expensive, uncertain, or complex to attack.

The Product Manager's Job May Get Bigger, Not Smaller

If AI can research customer problems, produce specifications, generate prototypes, write code, review code, run QA, and coordinate launches, it raises an obvious question:

What happens to product managers?

Charles outlined three potential directions.

The first is the technical product manager: someone who improves the factory itself by finding bottlenecks and designing systems that make the entire organization faster.

The second is the tastemaker: the person responsible for product judgment, standards, direction, and deciding what “great” looks like.

The third is the general manager: a product leader whose responsibility expands beyond product development into marketing, sales, growth, operations, and ultimately the business outcome.

For founders, those categories are useful beyond the PM profession.

They point toward the human work that becomes more valuable when execution becomes cheaper:

System design. Judgment. Ownership.

Don't Just Build the Product. Build the Machine That Builds the Product.

Charles closed the talk by returning to racing.

When one bottleneck disappears, another emerges.

Then another.

The work never really ends.

That's why perhaps the most important shift for founders isn't adopting a particular AI coding tool or copying one of Ramp's internal agents.

It's changing what you pay attention to.

When something becomes dramatically faster, look downstream.

Where does work pile up next?

Where are people waiting?

Where does information disappear?

Where does judgment remain scarce?

Where are highly capable employees repeatedly performing work that could become infrastructure?

The startup that answers those questions relentlessly begins building something more powerful than a collection of AI automations.

It builds a faster factory.

And in an environment where almost every competitor will eventually have access to similar models, that factory may become one of the few enduring advantages left.