Geoff Charles on Product Teams, Sprint Velocity and Strategy at Ramp

Geoff Charles, Ramp’s vice president of product, tells Harry Stebbings that he moved from management consulting into product through a data analytics company. He learned by getting close to customers, understanding their pain and working with engineers on solutions. He recommends observing people at work and asking open questions rather than seeking confirmation of a preconceived idea.

Charles suggests choosing work by noticing what gives and drains energy. He likes building products, moving metrics and competing, while bureaucracy drains him. At Ramp he says early hiring mistakes often came from not understanding the exact go-to-market role needed or separating an individual’s contribution from the growth of their prior employer.

For individual product managers, Charles describes putting a new hire into an established high-performing team to observe their work. He recommends asking senior hires to do the work themselves before building a large team, so their contribution is visible. His three-month assessment and comparison of one person with an existing team are management heuristics, not controlled evaluations.

He generally values experience at the same company stage over the same category: someone from a large organization may expect resources a startup does not have. In a small pre-product-market-fit company, he recommends that the founder or first product manager join sales conversations and help sell the first 100 customers.

Sales demonstrations can be a source of discovery: notice where a prospect becomes curious, identify pain, then quickly incorporate feedback into a prototype. Charles suggests an early product team can behave partly like a professional-services team for a small number of design partners. The aim is to learn and solve a real problem, though custom work still requires judgment about broader applicability.

He notes that a polite response is not necessarily a purchase. Ramp’s core product was free, making the sales context different from a paid product, and he says the team made switching easier by helping customers move existing card arrangements. This is his account of Ramp’s approach, not a universal conversion result.

Charles describes his two-week sprint: product, engineering and design leads meet to align on the next two weeks, alternating with a longer-term strategic discussion. A team of roughly five to ten then meets to agree ownership of the work; individuals sign up for tasks rather than simply receiving assignments. Other meetings are scheduled for specific blockers or decisions.

Goals and owners are visible, and at the next sprint the team reports what was achieved and why anything was missed. Charles also encourages teammates to acknowledge help. He warns product managers against becoming administrators who write every ticket and chase every update; his preference is for engineers to own their work and escalate risks.

Asked about a team member who consistently chooses unambitious work, Charles says a team may need to part ways. Every quarter, teams step back at a customer-oriented offsite to review results, adjust strategy and process, and refresh before the next cycle. These are the practices he describes, not proof that any particular cadence prevents burnout.

As the company grows and adds sales, support and marketing teams, Charles says planning one or two quarters ahead becomes more useful. Marketing needs coherent groups of features and stories for launches, not a succession of isolated updates. The short sprint remains a delivery rhythm within a longer plan.

At Ramp, people outside a team can comment on product specifications or marketing work. Charles says this visibility helps build trust and improves craft, even if feedback is harder to manage. Stebbings asks how debate can coexist with speed; Charles says the decision-maker must have authority to decide and the rest of the team must commit while holding them accountable for outcomes.

Before product-market fit, he says teams should build durable systems only when the need is highly certain and failure would be high risk; much else may have a shorter useful life. After fit, reuse can accelerate new products. Ramp’s reimbursement product reused employee identity, request and approval flows and adapted an existing money-movement system, according to Charles.

He advises keeping most of the company focused on the first product while a small technical team explores the next one. Do not divert the whole sales and marketing organization before the new product has its own fit, he says. A new product can start with self-service users, then move to a small sales team once the use case, positioning and opportunity are clearer.

Asked whether new releases become too risky as a company gains a brand, Charles distinguishes existing customers from the wider market. He suggests existing customers can use a beta before launch, while marketing communicates to potential customers who may not yet know the product. This is his approach, not a guarantee a launch will succeed.

Charles criticizes objectives and key results when teams debate numerical targets without explaining the strategy for achieving them. He prefers a concrete problem, hypothesis and action—for example, building a product for a defined need and reaching an initial group of customers. He is not arguing that outcomes do not matter.

Stebbings favors value-based measures such as usage and transactions per customer. Charles agrees these can be useful but wants teams to focus on leading indicators they can influence during a sprint, rather than solely on lagging revenue or market share. The choice depends on whether the metric meaningfully connects the team’s actions to the eventual outcome.

He recommends one or two clear, achievable and motivating goals per team, with a small number aggregated for the product organization. A broad mission repeated unchanged every quarter is not the same as a useful near-term goal. A written hypothesis should state the customer, problem and expected solution so the team can learn if it is wrong.

Ramp’s initial hypothesis, Charles says, was that finance teams spent too much time and money managing expenses and employees faced frustrating processes. One early product idea automated receipt collection so the software, rather than the finance team, chased employees. He presents the approach as one hypothesis that worked for Ramp, not the only possible solution.

For postmortems, he recommends documenting facts, involving affected functions, asking curious questions without blame and assigning clear, timely actions. Customer support or account managers may bear consequences even if an engineering team caused an incident. The purpose is to learn and avoid repeating the same failure.

Ramp had staff in New York and elsewhere. Charles says in-person time helps build trust and makes remote collaboration easier afterward. This is his experience; he does not present a controlled comparison of remote and in-person productivity.

On the “right to win,” Charles argues large incumbents often struggle to change their incentives, business models and organizational structures for a new product. He sees startups addressing a narrow finance problem as a more immediate competitive concern for Ramp than established spend-management providers. As a Ramp executive, he has a commercial interest in that assessment.

Asked when to sunset a product, Charles says Ramp has not always been good at removing features. He weighs the cost and complexity of keeping them, including clutter and stability, against the option to show them only to relevant segments. A further investment should depend on a credible next hypothesis and the effort needed to test it.

One hypothesis failed when Ramp assumed the person paying a bill could authorize a loan embedded in an invoicing product. Often that person was an operator rather than the financial decision-maker, Charles says. The team had to change the product to involve the appropriate finance authority. This is a company example, not a claim about every business.

Charles sees product work as both art and science: a shared process can yield different results across teams, and design and creativity matter. In early B2B startups with little quantitative data, he values strong intuition grounded in customer listening and quickly tested with qualitative evidence. Larger data sets can later support more robust testing.

He expects AI to change interfaces from tables and forms toward more dynamic or conversational experiences. He says Ramp uses AI to flag relevant transactions, but the interview does not independently measure the system’s accuracy. His broader prediction about interfaces and strategic work is a forecast, and Ramp has a commercial interest in its products.

Charles disagrees that a founder must retain the product-leader title forever. He says Ramp founder Eric Glyman focuses on vision, brand and culture while an empowered product and technical team makes sequencing decisions. He describes the arrangement as working for Ramp so far, not as a rule for every company.

To hire for velocity, he asks why candidates want to join, whether they have pushed through obstacles and how they created impact. Ramp uses take-home cases related to its space but not work it intends to use, he says. He looks for preparation, clear thinking and the ability to influence a team.

Final interviews with product, engineering and design include cases such as a system failure or customer complaint. He looks for a coherent framework, useful questions and a quick path to the underlying problem. In the rapid-fire round he compares product development to distance running: short intervals, measurement and repeated practice compound over time.

For an early product career, Charles recommends developing a strong skill in technology, business or design. He advises founders to provide context and close guidance at first, then give new product leaders authority over how to achieve agreed outcomes. Product leaders, in turn, should communicate decisions, trade-offs and requests for help clearly.

He says his team posts weekly updates on completed work, upcoming work and decisions requiring help. Charles is unsure he wants to become a CEO because he prefers building products to fundraising and external storytelling. He closes by admiring Apple’s product craft and ecosystem, and hopes Ramp can build comparable loyalty; that is his aspiration and assessment.