Geoff Charles
VP of Product at Ramp
Where to hear and read about Geoff Charles1 episode or test
Geoff Charles is VP of Product at Ramp, where he helped a small R&D team reach $100 million in annual revenue in about two years. The most useful thing to learn from him is to give small, single-goal teams context instead of control, and cut process so speed compounds.
You can't ask for velocity and not have empowerment and not trust and not eliminate process and not increase the focus.
Velocity over everything: How Ramp became the fastest-growing SaaS startup ever | Geoff Charles
Geoff Charles: the story and the lessons
1How Geoff Charles helped Ramp build products at record speed
Charles joined a team of about ten and shipped rivals within months. Three months after he joined, Ramp had a competitor to Amex, and six months later one to Expensify. Ramp built rivals to two public companies with about eight engineers.
Ramp reached $100 million in annual revenue with under 50 people in R&D, the fastest SaaS business to that mark at about two years. Velocity drives its process, incentives, hiring, promotions and decisions.
Charles gives each big bet a single-threaded team with one goal. Three engineers, one designer and one PM built a Bill.com competitor in three months, and it now moves billions of dollars a year. People are pulled from different teams into a sub-team that owns no existing product.
Research, production engineering and process outside the goal are removed, even to the point of a dedicated room. The work stays quiet until early traction, then resources are added. Last summer's Flex product was built this way.
Charles built protective layers so core teams never touch bugs. Rotating production engineers take bug and escalation duty, and product operators take documentation, release management, enablement and customer requests off the PM. Bugs go straight to the engineer on call.
That engineer feels the pain and fixes it fast. Ramp has no bug backlog. Charles says: "we have layers of protective tissue to core teams".
Ramp entered bill payments because it already owned most of the parts. Charles frames a bill as an invoice to the company and an expense as an invoice to the employee. Ramp already had money movement, liabilities, accounting integrations, a risk process and employees requesting payments on the platform.
He calls this a "right to win". The accounts payable product reached billions of dollars a year in volume.
Charles put support under product and rewards agents for fewer tickets. Ramp treats every support ticket as a product failure. Support reports into product, and agents are rewarded for deflection, not only for resolving tickets.
That meant hiring a different kind of person than a typical scaled support team. Over 400,000 users are served by fewer than 30 agents.
2How Charles leads: context over control
Charles aligns teams on goal, hypothesis and data, not on the solution. He debates upstream, on the goal, the data and the hypotheses, then lets the teams closest to the work pick the solution. The contract between him and each team is its strategy and roadmap, and the team flags risks and one-way decisions.
He says things went wrong whenever he was prescriptive about a solution without that alignment. He spends much of his time repeating context the team may lack, since he sits in meetings they don't.
Charles moved from micromanaging to a trust-based contract with each team. At first it was just Charles and one other PM, and he micromanaged some areas. Trust built over time.
Directs post goals every Monday and review each other's goals. One-on-ones cover what people need from him, and a biweekly team-wide meeting shares missing context.
Charles sets hard quality guardrails so speed does not hurt the business. Every team reports NPS, CSAT, operational overhead (tickets from its area divided by users) and tickets caused by customer confusion. Every negative review goes monthly to the tech lead, PM and designer.
If a metric goes red, the team stops shipping new features until it is fixed. Inside those limits a team can do whatever it wants. "Velocity is just a magnitude, it's not necessarily a specific direction."
Charles has never scheduled a status meeting at Ramp. Statuses are async and in real time, in the systems teams already use. Meetings are kept for collaboration, ideation and decisions.
He says adding status meetings, documents and accountability layers in the name of speed demotivates people.
Charles shows leaders a menu of tradeoffs instead of doing everything. When a CEO answers a choice with "all of it", he presents what the team will do, what it won't and why, then asks which to pick. Four goals get done much faster than eight.
He says this is not pushback. It increases velocity.
Charles says burnout comes from lost flow, not hard work. He felt burnout at the time of his lowest velocity, when lots of effort moved nothing. People avoid burnout when the work feels like theirs.
Managers align on the goal, then hand it over with the problems to solve.
3How Charles plans, thinks and works
Charles replaced quarterly OKRs with a biannual company priorities one-pager. Quarterly planning took one month in every three, about 33% of the time, and R&D ignored the OKRs. Ramp now uses a one-pager plus a financial plan whose rows each have an owner.
The product roadmap is the second contract. OKRs stay only for cross-functional goals. Charles is accountable if the roadmap misses company goals.
Charles plans precisely only for big market moments. Coordinated launches across product, marketing and sales happen once a quarter or every six months. Elsewhere pods stay autonomous and somewhat chaotic.
Goals, problem and vision stay constant so people don't feel they work at a different company. "Accuracy has cost", so he spends it only where it pays.
Charles has each pod write a strategy doc that links to company strategy. The doc covers goals, hypothesis, why Ramp is uniquely positioned, metrics, initiatives, risks and long-term outcomes. Charles checks that it fits the product and financial strategy.
Writing it makes teams think like the leader, which gives the leader more leverage over time.
Charles reasons from first principles instead of pattern matching. Ramp is a credit card, payments and software company with both PLG and enterprise sales, so past experience often misleads. His own product process assumed a B-plus engineering team and had to be rebuilt for an A-plus one.
New hires must set aside their experience. He tells listeners to question his advice too.
Charles writes the question on paper and thinks before he reads. He closes the laptop, writes the question simply at the top of a page and answers it himself, then reads to refine. He has used it on decision making, headcount allocation and avoiding politics.
"The best way to increase your capacity to think is to actually do the thinking."
Charles books next week's thinking time every Friday. He picks the top questions for the coming week and blocks time for them, plus one weekend day. Early mornings and late afternoons work best.
He says: "I should never really be in the critical path of anything." Urgent people can call his phone.
4How Charles builds and hires product teams
Charles makes everyone on the product team think like a PM. Ramp counts everyone reporting to the CTO as product. It has about 13 PMs and over 100 engineers, a ratio of one to eight up to one to 15.
PMs never write tickets. Engineers break down the work and create their own tickets, which builds trust and speed.
Charles hires for impact drive and depth of thought over experience. He looks at the impact a candidate has already had. The reason for leaving the last job is a second signal, and "things got too slow" or "too bureaucratic" is a strong one.
He picks one tradeoff the candidate made and keeps probing until he understands how they decide. Ramp's business is unique, so experience matters less.
Charles spots A-plus engineers by mindset, not by a test. They want to win in the market, ask how the company makes money, and set the pace by asking the PM to keep up with specs. They also jump into Slack channels to fix bugs unprompted.
He does not judge technical rigor himself. He accepts that a radically empowered team pushes back, which makes him think harder about what he asks.
Charles says to reach product through an adjacent role, then earn a trial. He went from college to consulting to a solutions analyst role implementing large B2B software in national banks, and moved into product by showing impact. Good starting roles include product operations, business operations, consulting and sales or solutions engineering.
At Ramp, engineers and designers get six months in a new area, and the people they work with decide whether they want them as their PM.
Velocity over everything: How Ramp became the fastest-growing SaaS startup ever | Geoff Charles
Ramp's VP of Product explains how a small team built competing products in months by using single-threaded teams, context over control, and almost no planning or status overhead. The result is a company that passed $100 million in annual revenue within two years with about 50 people in R&D.
Charles joined a team of about ten and shipped rivals within months. Three months after he joined, Ramp had a competitor to Amex, and six months later one to Expensify. Ramp built rivals to two public companies with about eight engineers.
Ramp reached $100 million in annual revenue with under 50 people in R&D, the fastest SaaS business to that mark at about two years. Velocity drives its process, incentives, hiring, promotions and decisions.
Charles gives each big bet a single-threaded team with one goal. Three engineers, one designer and one PM built a Bill.com competitor in three months, and it now moves billions of dollars a year. People are pulled from different teams into a sub-team that owns no existing product.
Research, production engineering and process outside the goal are removed, even to the point of a dedicated room. The work stays quiet until early traction, then resources are added. Last summer's Flex product was built this way.
Charles built protective layers so core teams never touch bugs. Rotating production engineers take bug and escalation duty, and product operators take documentation, release management, enablement and customer requests off the PM. Bugs go straight to the engineer on call.
That engineer feels the pain and fixes it fast. Ramp has no bug backlog. Charles says: "we have layers of protective tissue to core teams".
Ramp entered bill payments because it already owned most of the parts. Charles frames a bill as an invoice to the company and an expense as an invoice to the employee. Ramp already had money movement, liabilities, accounting integrations, a risk process and employees requesting payments on the platform.
He calls this a "right to win". The accounts payable product reached billions of dollars a year in volume.
Charles put support under product and rewards agents for fewer tickets. Ramp treats every support ticket as a product failure. Support reports into product, and agents are rewarded for deflection, not only for resolving tickets.
That meant hiring a different kind of person than a typical scaled support team. Over 400,000 users are served by fewer than 30 agents.
Charles aligns teams on goal, hypothesis and data, not on the solution. He debates upstream, on the goal, the data and the hypotheses, then lets the teams closest to the work pick the solution. The contract between him and each team is its strategy and roadmap, and the team flags risks and one-way decisions.
He says things went wrong whenever he was prescriptive about a solution without that alignment. He spends much of his time repeating context the team may lack, since he sits in meetings they don't.
Charles moved from micromanaging to a trust-based contract with each team. At first it was just Charles and one other PM, and he micromanaged some areas. Trust built over time.
Directs post goals every Monday and review each other's goals. One-on-ones cover what people need from him, and a biweekly team-wide meeting shares missing context.
Charles sets hard quality guardrails so speed does not hurt the business. Every team reports NPS, CSAT, operational overhead (tickets from its area divided by users) and tickets caused by customer confusion. Every negative review goes monthly to the tech lead, PM and designer.
If a metric goes red, the team stops shipping new features until it is fixed. Inside those limits a team can do whatever it wants. "Velocity is just a magnitude, it's not necessarily a specific direction."
Charles has never scheduled a status meeting at Ramp. Statuses are async and in real time, in the systems teams already use. Meetings are kept for collaboration, ideation and decisions.
He says adding status meetings, documents and accountability layers in the name of speed demotivates people.
Charles shows leaders a menu of tradeoffs instead of doing everything. When a CEO answers a choice with "all of it", he presents what the team will do, what it won't and why, then asks which to pick. Four goals get done much faster than eight.
He says this is not pushback. It increases velocity.
Charles says burnout comes from lost flow, not hard work. He felt burnout at the time of his lowest velocity, when lots of effort moved nothing. People avoid burnout when the work feels like theirs.
Managers align on the goal, then hand it over with the problems to solve.
Charles replaced quarterly OKRs with a biannual company priorities one-pager. Quarterly planning took one month in every three, about 33% of the time, and R&D ignored the OKRs. Ramp now uses a one-pager plus a financial plan whose rows each have an owner.
The product roadmap is the second contract. OKRs stay only for cross-functional goals. Charles is accountable if the roadmap misses company goals.
Charles plans precisely only for big market moments. Coordinated launches across product, marketing and sales happen once a quarter or every six months. Elsewhere pods stay autonomous and somewhat chaotic.
Goals, problem and vision stay constant so people don't feel they work at a different company. "Accuracy has cost", so he spends it only where it pays.
Charles has each pod write a strategy doc that links to company strategy. The doc covers goals, hypothesis, why Ramp is uniquely positioned, metrics, initiatives, risks and long-term outcomes. Charles checks that it fits the product and financial strategy.
Writing it makes teams think like the leader, which gives the leader more leverage over time.
Charles reasons from first principles instead of pattern matching. Ramp is a credit card, payments and software company with both PLG and enterprise sales, so past experience often misleads. His own product process assumed a B-plus engineering team and had to be rebuilt for an A-plus one.
New hires must set aside their experience. He tells listeners to question his advice too.
Charles writes the question on paper and thinks before he reads. He closes the laptop, writes the question simply at the top of a page and answers it himself, then reads to refine. He has used it on decision making, headcount allocation and avoiding politics.
"The best way to increase your capacity to think is to actually do the thinking."
Charles books next week's thinking time every Friday. He picks the top questions for the coming week and blocks time for them, plus one weekend day. Early mornings and late afternoons work best.
He says: "I should never really be in the critical path of anything." Urgent people can call his phone.
Charles makes everyone on the product team think like a PM. Ramp counts everyone reporting to the CTO as product. It has about 13 PMs and over 100 engineers, a ratio of one to eight up to one to 15.
PMs never write tickets. Engineers break down the work and create their own tickets, which builds trust and speed.
Charles hires for impact drive and depth of thought over experience. He looks at the impact a candidate has already had. The reason for leaving the last job is a second signal, and "things got too slow" or "too bureaucratic" is a strong one.
He picks one tradeoff the candidate made and keeps probing until he understands how they decide. Ramp's business is unique, so experience matters less.
Charles spots A-plus engineers by mindset, not by a test. They want to win in the market, ask how the company makes money, and set the pace by asking the PM to keep up with specs. They also jump into Slack channels to fix bugs unprompted.
He does not judge technical rigor himself. He accepts that a radically empowered team pushes back, which makes him think harder about what he asks.
Charles says to reach product through an adjacent role, then earn a trial. He went from college to consulting to a solutions analyst role implementing large B2B software in national banks, and moved into product by showing impact. Good starting roles include product operations, business operations, consulting and sales or solutions engineering.
At Ramp, engineers and designers get six months in a new area, and the people they work with decide whether they want them as their PM.
More from Ramp
Austin Hay
Head of Marketing Technology at Ramp, former VP of Business Operations at Runway and VP of Growth at mParticle, Reforge instructor
Ramp1 source · 19 tipsEric Glyman
Co-founder and co-CEO of Ramp
Ramp
1 source · 19 tipsSri Batchu
Head of Growth at Ramp; previously growth strategy and operations at Instacart, early employee at Opendoor
Ramp1 source · 19 tips