50人两年做到一亿美元：Ramp把速度写进组织设计

Charles, VP of Product at Ramp, describes the company as a finance automation platform and corporate card for small and medium-sized businesses, covering expense management, card payments, bill payments and accounting. He says Ramp has helped 15,000 businesses and sees about a thousand users join each day. Lenny notes that Ramp is known as the fastest-growing SaaS and fintech business in history, and that the newsletter post he and Charles wrote on how Ramp builds product became one of his most popular.

Asked about the one word that defines Ramp, Charles says velocity is everything: how the product process is designed, how teams are incentivized, who is hired and promoted, and how decisions are made. He traces it to the pandemic, when a very small team faced a huge market opportunity and the question was less which path to pick than how fast it could execute. Teams that iterate fast reach impact over time, he says.

He lists further benefits: talent wants to join companies that ship fast, and candidates often tell him they want to know what that feels like. Velocity also de-risks decisions, because when the cost of a decision is low it becomes easier to make. Lenny stresses that many companies say they move fast, but Ramp actually does.

For evidence, Charles says that when he joined there were around ten people, about eight of them engineers, and in three months they built a competitor to Amex. Six months later they built a competitor to Expensify, and they reached $100 million in annual revenue with fewer than 50 people in R&D. A later expansion into accounts payable, a competitor to Bill.com, was done by three engineers, one designer and one PM in three months, and that product now moves billions of dollars a year.

Charles gives the recipe as small teams with single-threaded focus, the resources for big goals, very tight timelines, and shielding from the chaos of the rest of the organization. Ramp doesn't even tell the rest of the company what these teams are doing until they find early traction, and then more resources are pulled in, like gravity. By single-threaded he means one goal the team wakes up to, with other research, production engineering and process removed, almost to the point of saving a room in the office for them.

His example is the Flex product launched the previous summer, a single-threaded team focused on e-commerce companies and their cash flow needs. He doubts they would have hit the goal had the team been distracted. Protection comes in layers: a rotation of production engineers shields core teams from bugs and escalations, and product operators shield PMs from documentation, release management, enablement and customer requests.

Big bets usually mean pulling people from several teams into a new sub-team that owns no existing product, since these are new products. Charles says that is harder when going from one to two than from zero to one. On how to keep goals lofty without being impossible, he points to market comparables like public competitors that de-risk decisions, plus design: designers craft what the future product could look like, and Loom walkthroughs of Figma prototypes keep teams motivated and anchored on the revenue goal.

Charles says one of Ramp's biggest cultural differences was how hands-off his boss, the CTO Karim, was on product decisions, because everyone was aligned on goals. Alignment starts with the goal, the hypothesis for reaching it, the data behind that hypothesis, and only then the potential solution. Junior leaders, himself included earlier, tend to debate solutions when they should debate the interpretation of data, the hypotheses or the goals themselves.

Whenever things went wrong at Ramp, he says, it was when he was prescriptive about the solution without aligning upstream. Teams closer to the ground come up with better solutions, so he spends most of his time repeating himself and sharing context they may lack from forums they aren't in. Lenny likens the role to being "repeater in chief."

The contract with each team is their strategy and roadmap. They highlight risks and one-way decisions they need his input on, and he coaches with firsthand data. Direct reports post goals every Monday and review each other's, one-on-ones focus on what they need from him, and a biweekly team meeting shares missing context. This evolved with trust; early on, he admits, he micromanaged some areas.

As Ramp reached 10 to 15 PMs and 20 to 30 mini pods, it added a product review for large roadmap items, where Charles and the head of design give feedback on specific risks and tradeoffs. Mostly people ship, and the leaders plug in at the move from beta to general availability, when sales starts selling. Because Ramp moves so fast, he says, pulling something back wastes little time.

Lenny cites a conversation with Nicole Forsgren in which research found that quality rises as velocity rises, because fixes are quick and there are no big batches to review and release. Charles agrees, but says you must build control mechanisms so high velocity doesn't tank the business. Ramp feeds every negative review back to the tech lead, PM and designer monthly, and reports NPS, CSAT and operational overhead, meaning tickets from a product area normalized by its users.

Bugs are assigned directly to the on-call engineer so they feel the pain, and Ramp doesn't keep a bug backlog: almost every bug is fixed once surfaced, as part of the production engineer's job. For usability, Charles tracks support tickets caused by confused customers. If the number is elevated, the team can't ship new features until it is fixed. In his words, "velocity is just a magnitude, it's not necessarily a specific direction."

Lenny asks what PMs should do when their CEOs, inspired by Ramp's story, demand velocity. Charles first credits Ramp's speed less to culture he amplifies than to the quality of its engineering and design talent. His first piece of advice is for leadership to treat R&D as a first-class citizen, pay up for the best people and build a culture of empowerment, where the CEO sets the vision but has less say in the exact product sequence.

Second, he calls meetings and status updates the biggest waste of time, and says he has never scheduled a status meeting; statuses should be async and in real time, with meetings reserved for collaboration, ideation and decisions. Third, leaders often want everything at once, such as more products in one segment and also a move into another among SME, mid-market and enterprise. He suggests presenting clear tradeoffs as a menu of what you will and won't do, because executing four things is faster than eight, and that this is increasing velocity rather than pushing back.

Lenny summarizes the point as using the demand for speed as leverage to change how things operate, and Charles agrees fully: you can't ask for velocity without empowerment, trust, less process and more focus. He adds that few things motivate more than a leader commenting "this is awesome" in a project channel or design crit, and that founders at Ramp read the projects they care about.

On whether the pace burns people out, Charles says the debate over working hard misses the point, which is impact and how good you feel about the work. When he felt burnt out it was at his lowest velocity, when he was putting effort into things that weren't moving. He says he isn't asking for endless hours but for people to get out of their own way, reach a flow state and focus on building great products, comparing it to how the best runners love running.

Lenny agrees that his most fulfilling projects were often the most intense, as long as the work was meaningful. Charles stresses that it must be meaningful to the individual, not the boss's boss, and that management's role is to make everyone feel the goal is theirs. If people feel the team is their own mini company they radically avoid burnout, but if the work is pushed onto them without alignment or empowerment, burnout is certain.

Charles tells every new joiner they have signed an implicit contract that velocity comes before almost everything else, so things will be chaotic, products will ship that don't work and demo instances will change under them. He also says planning has a cost, so accuracy should be concentrated on high-value moments such as big market launches coordinated across product, marketing and sales, which come once a quarter or every six months. Elsewhere, pods can be autonomous and chaotic from the outside.

Lenny recalls Sheryl Sandberg saying that constant change is the problem you want because it means you are growing. Charles cautions that chaos shouldn't be an excuse for weak strategy: Ramp has been consistent since the start as the spend management platform that helps you spend less. Goals and vision are stable while timing and quarterly scopes change, and he says most code Ramp has written is still in customers' hands.

Charles defines strategy as how you reach your goals, sitting between a vision and a roadmap. Each pod writes one covering the goals, the hypothesis for why this will work, why Ramp is uniquely positioned, the metrics, initiatives, risks and long-term outcomes. He then checks the documents for alignment with the higher-level product strategy and the financial strategy, and notes that making teams think like him gives leverage over time.

On planning, Ramp once ran OKRs with financial goals and quotas, which made planning long, political and annoying, and the R&D team effectively said to execute the roadmap and drop the OKRs. It moved from quarterly planning that took a month of every three, about a third of the time, to a biannual one-pager of company priorities. A financial plan whose levers each have an owner is one contract, and the roadmap is the other.

For the "uniquely positioned" question, he uses bill payments as the example: a bill is an invoice to the company and an expense an invoice to the employee, both liabilities that must be processed and paid. Ramp already had money movement, accounting integrations, a risk process and employees on the platform, so it had a right to win. He says reusing components like this increases velocity.

Charles mostly stays away from OKRs for product and uses them for cross-functional goals such as winning a market, and for the financial side. If the roadmap doesn't hit company goals, he says, he is accountable, and he doesn't want teams manipulating OKRs to fit their roadmaps. Lenny adds that he isn't sure what separates an OKR from a plain goal anymore.

Charles says Ramp is a credit card, payments and software company at once, serving SMEs with PLG and enterprises with sales, so you can't pattern-match from past experience. He says hires have to put aside their expertise, and claiming "I've seen this before" or citing a past company is an anti-pattern. He admits he had to rebuild his own process, because it assumed a B-plus engineering team and he faced an A-plus one.

His example is support, which reports to him because "every support ticket is a failure of our product" and product should be accountable for it. Agents are incentivized to reduce tickets over time and increase deflection rather than just resolve them, which attracted a different breed of people. The result, he says, is a very low contact rate, with over 400,000 users and under 30 agents.

Charles uses writing to reach first principles: shut the laptop, write the question at the top of a page and think. Questions have included how to scale decision-making, how to allocate headcount fairly and how to avoid politics as firsthand data fades. He argues that reading makes you wiser but doing the thinking improves your capacity to think, and that writing also helped Ramp's brand and hiring during COVID.

To protect that thinking time, he reviews the next week every Friday and blocks time for top questions, and uses a day on the weekend for deep work, outdoors with a notebook. He says he should never be on the critical path, and Lenny shares a similar practice of blocking Wednesday and Friday mornings for deep work. Charles also tells people to turn off notifications, quit Slack during deep work and check email once a day.

To stay on top of tasks in back-to-back meetings, Charles writes down at the end of every meeting what he owes and what others owe, with clear dates, then grooms the list into tactical versus strategic and important versus less important. He Slacks others what they owe and sets reminders, aiming to free headspace for processing rather than memory. Lenny notes the similarity to *Getting Things Done*, which Charles hasn't read.

Ramp has about 13 PMs and over a hundred engineers, a ratio of one to eight up to one to 15 depending on the team. Charles says the small team forced others to think like PMs, and that "product" means everyone reporting to the CTO: engineers, designers, PMs and data scientists. He adds that designers and engineers are empowered to think about specs and priorities.

Ramp also invested early in product operations, which handles project, issue and release management, enablement, betas and customer research, and cuts low-leverage PM work. PMs never write tickets; their contract is the vision, priority and a high-level spec, and engineers break down their own work. The PM's core jobs are strategy and alignment, building team culture in a pod whose members report to different managers, keeping the team focused and shielded from stakeholders, and being the point of contact.

Asked how to tell whether engineers are A-plus, Charles lists signs: they want to win in the market, understand the business and ask about how the company makes money, and execute without your help. They set the pace rather than waiting on specs, and jump into Slack channels to explain features or fix bugs proactively. He says a PM's job is not to control what engineers do but to ensure they're aligned with the long-term vision and deliver on commitments.

He acknowledges the drawback that radically empowered engineers may think they know the product better than the designer or PM and push back, but says he'll take that culture any day over one where people take things at face value. He would rather have someone who is a bit harder to manage because it makes him think more deeply and grow as a manager faster.

In interviews Ramp looks for a strong desire for impact, often visible in leaving a job because it became too slow or bureaucratic, and for people who can think deeply about a tradeoff they made. He says these matter more than experience given how unique the business is. His favorite interview question is "what's the hardest thing you've ever done?", because working at Ramp is hard.

To break into product, Charles suggests an adjacent role such as product operations, business operations, consulting, sales engineering or solutions engineering, where you prove deep understanding of the customer and the product. Ramp gives such candidates six months in a new area, and the engineers and designers they work with decide whether to keep them. His closing message is to think from first principles and to remember that empowered, talented engineers and designers, hired early by CTO Karim, are the biggest reason for Ramp's success.