👋 Hey, I’m Lenny and welcome to a 🔒 subscriber-only edition 🔒 of my weekly newsletter. Each week I tackle reader questions about building product, driving growth, and accelerating your career.

I was talking to a prominent VC the other day about what startups he’s watching, and he told me that he’s seeing one company quickly becoming a gravity for the best talent: Ramp. If you’re not familiar with Ramp, they provide corporate cards and a spend management platform, helping startups save money and control spending. They were last valued at over $8 billion, are backed by Founders Fund, Redpoint, Stripe, and others, and in the past year grew 4x, to over $10 billion in annualized spending. I believe they are also the fastest-growing SaaS company of all time, hitting a $100 million run rate in two years. I’m not an investor, but I wish I were.

In part five of an ongoing series on how the best product teams build product (don’t miss Figma, Coda, Duolingo, and Miro—and Notion, Linear, and Snowflake coming soon), I sat down with Geoff Charles, Ramp’s VP of Product, to understand what Ramp has done right (and wrong) over the years in how they approach product. This is definitely my new favorite edition of this series, and you’ll soon see why below.

Here’s what stood out to me most about Ramp’s approach to product:

1. Velocity, velocity, velocity.

2. Their unique product strategy framework, including this template.

3. Anchoring their product strategy to their financial model.

4. Their evolution from two-week sprints to bi-yearly planning with detailed quarterly roadmaps.

5. Focus on efficiency—they had fewer than five PMs and 50 engineers when they hit $100 million in ARR.

6. Teams are organized around business outcomes (e.g. increase attach rate for bill payments).

7. Product, design, and engineering all report to the CTO.

8. Emphasis on thinking from first principles.

9. Their approach to hiring, e.g. hiring ICs vs. managers

For more from Geoff, follow him on LinkedIn and Twitter.

How Ramp builds product

1. How far out do you plan in detail, and how has that evolved over the years?

At Ramp, our culture is velocity. It shapes every process and team ritual. It’s how we develop our people. It’s our solution to nearly every problem. And most importantly, velocity is key to our business strategy. It’s how we deliver on our mission to save customers their most valuable resources—their team’s time and money.

Our entire planning process is optimized toward product velocity. In essence, we believe that doing is better than planning. Any second you spend planning is a second you don’t spend doing. The moment you are aligned in a direction, you don’t need a high level of accuracy. It’s impossible and costly to try to predict what you can do—and part of our competitive advantage has been that we can respond very quickly to the change in environment, strategy, or customer feedback. We learn something new every day that helps us adjust our plan. While the balance between planning and execution has evolved over Ramp’s growth, we’re still very much in execution mode even today:

• Pre-product-market fit, sub-20 people: When I first joined Ramp, our main focus was to find product-market fit. We had a million ideas, but what truly mattered was how we were able to execute. This required being laser-focused on delivering one thing at a time, fast. We planned in two-week sprints because you could easily forecast two weeks ahead. It was all about doing as much as possible, as quickly as possible. The “backlog” didn’t exist. It was all about, what are we doing today? This week? We weren’t planning beyond that.

• Product-market fit with the core card product, 100+ people: We started planning in months for one to two quarters at a time. We needed deeper coordination with sales, marketing, and customer operations teams—teams that operate on cadences longer than two weeks (you can’t change sales quotas in two-week cycles). We also shifted our technology teams toward thinking about the reusability and durability of systems—and this requires you to know what capabilities you would want to build in the future.

• Multiple products in a portfolio, 500+ people: At this current stage, we know we have a sustainable core business that we’re taking upmarket, multiple emerging products, and rapidly growing go-to-market teams to help us tackle expansion in both our customer mix and product/market targets. The upmarket has longer sales cycles, and launching ambitious, coherent GTM campaigns needs much more lead time. Now we plan on a quarterly basis, and reserve the right to toss out the plan the moment it is written.

2. Do you use OKRs in some form?

Oftentimes people start and get very bogged down with OKRs when where they should really start is strategy. The process of OKRs to me feels forced—you know what you want to do, and you have to reverse engineer an objective and a metric to fit into this framework. You sweat the wording and the specific metric. Teams feel like they are being judged on the metric. There is so much iteration. And at the end of all this, not much has changed from the original plan. 

To win in the market, you need to be product-strategy-driven, not sales- or marketing-driven. You need to believe that the product strategy will deliver value to the customer, and that in turn drives value to the business. That belief is earned and needs to start early in the company’s lifecycle.

Here’s the way we plan:

1. Start with product strategy, bottom-up. Define clearly what you want to achieve and why achieving this will lead to outsize outcomes for the customer and the company. The process of developing pod-level product roadmaps is almost entirely bottom-up. Once we align on our product vision and the top two or three goals we have as a company, we empower the folks closest to the problem to develop their own product roadmaps. Then we co-develop the top-level product strategy. The way we write out a product strategy is as follows: 

   1. Goal → What do you want to see in the world?

   2. Hypothesis → Why do you think this will work?

   3. Right to Win → Why are we uniquely positioned to do this?

   4. Metric → How will you measure that it does?

   5. Initiatives → What do we need to do to reach the goal?

   6. Risks → Why would we fail & what should we do about it?

   7. Long Term Outcomes → How will this work compound?

   Here’s a template of our planning doc.

2. Anchor the product strategy with the financial model. A product strategy that is not anchored on the reality of how the company needs to make money will not survive. We need to constantly understand how we will monetize, and the tradeoffs between innovation, monetization, and growth. For example, for one quarter we might be focused on increasing our operating margins, or decreasing our credit losses, or launching a new revenue stream—we align on this with finance. 

3. Publish the product roadmap and align it with the marketing calendar. We share a high-level roadmap, get feedback from leaders across the company, and ensure that it is in lockstep with large marketing moments we co-develop. This helps us amplify our product releases and get loud in the market. Planning is not just specifying goals but also trade-offs. Everyone wants everything to be done—but that simply can’t happen. By making explicit what trade-offs you are making, we were able to engage in much more nuanced discussions around whether we should do X vs. Y instead of the absolute. For example:

4. Define company-level OKRs to mobilize cross-functional teams. Timebox company OKR planning, and stay high-level. We realized that we were planning one month every quarter—that’s 33% of the time. We ended up switching to bi-annually (planning twice a year) and scoped it to be the top priorities for the entire company rather than a laundry list of what every team was doing. The point of the exercise is to make trade-offs—it should be painful. Not everything on the roadmap needs to be in the company-level OKRs. We limit them to a few large cross-functional projects or launches. Here’s a planning template filled out:

5. OKRs should not be used for performance management. Each team is assessed differently. For example, sales are based on quota attainment and “closed won” conversion. Support is based on “solves per hour” and “customer satisfaction.” None of these should be in OKRs. While everything is measured at Ramp through scorecards, we focus OKRs on things we want to improve vs. just maintain. To reach these goals requires deep collaboration between, say, engineering, product, marketing, and sales. If we don’t hit the goal, that does not necessarily mean everyone tied to the goal underperformed. You need to go to a level much deeper than that to assess performance. 

3. How do your product/design review meetings work?

At Ramp, we build in the open and empower teams as much as possible to make the decisions in order to move quickly. What this means in practice is that every spec, design, decision, progress, and status is published in project-specific Slack channels, and anyone is invited to read and opine. Essentially, teams farm for dissent, not approval. Eliminating gatekeepers ensures that things keep moving forward. 

When there were fewer than 100 people, I could actually read everything. I would get notified anytime something was published or a key decision was made, and would review it and share any important perspectives. Three things broke as we scaled:

1. As teams got bigger, I could no longer be everywhere and have all the context. I needed teams to “manage up”—to synthesize context and key decisions for input.

2. As PMs on the team got more senior, more trust had to be built. PMs deserved more autonomy to decide what they needed input on.

3. Design teams were hearing one thing from the head of design in design jams and another from the head of product. If we weren’t aligned, it slowed things down. 

So for key decisions and high-risk projects, we now trust the PMs to bring these up in the weekly product “jam session.” This is meant to accelerate context sharing, decisions, and alignment between product, design, and engineering. Here are some of our design principles:

1. Focus on what truly matters, which is any new product or major change to the core user experience. PMs should ask themselves: If we get this wrong, what impact could it have on our product goals? If the answer is “big impact,” get input at the meeting. Otherwise, take the risk and skip the meeting. 

2. Don’t slow down teams. We needed something lightweight, frequent, and non-blocking. The head of product and design blocked out an hour every week (Wednesdays at 4 p.m.). Folks simply sign up. We are always available. 

3. Ensure alignment between product and design. By having both product and design leadership in the room, you ensure that they are aligned. This speeds things up instead of hearing feedback from two different people at different times.

4. Stick with relevant folks. Include the engineering leaders involved. Exclude anyone outside of tech—their perspective should have been covered as part of the initial spec process as key stakeholders.

Process is like a product—it requires constant iteration, and we’re still iterating.

4. Are product and design part of the same org? And who do PMs ultimately report to? Has this changed over the years?

The biggest lever to high velocity is designing your organization structure so that teams are forced to cooperate. 

1. PM, Design, Engineering, and Data should be equal parts of the same team. This has largely stayed the same since the beginning. I tend to think that if design reports into Product, the UX suffers. Design needs to have some of their own agenda, their own discovery. This is where you come up with truly brilliant ideas.

2. Everyone should report to the same tech-minded leader. There is no better way to force a relationship to happen than by having each head report into the same leader—in our case, we all report into the CTO. If Product reports into the CEO and Engineering into the CTO, then the only way to escalate differences is if the CTO and CEO talk to each other; that’s too high up the chain. You then run the risk of Product being “stakeholders” to Engineering instead of being “co-founders”—and not being product-driven.

3. Design your org the way you want your product to perform. Ultimately, you ship your org structure. Think about what the core competencies are that you want to amplify to accomplish your product strategy. If Data is not an equal, you are not elevating data-driven decision-making, data-science-driven products, and objective accountability. This matters as you get larger.

5. Broadly, do you structure your teams around products, user types, user journey, outcomes, or something in between? Has this changed over the years?

One of the biggest impacts to velocity is how you organize product teams. Here is how we did this at Ramp:

1. Teams are organized based on customer or business outcomes above all else. The team needs to be accountable for something big. That lights a fire behind a team and makes them want to run through walls. Years ago, we gave a team the mandate to drive 50% of our sales qualified leads by automating outbound emails. And they did. We gave a team three months to build a competitor to Bill.com. And they did. Big goals, tight timelines, and fully autonomous resourcing (remove as many dependencies as possible) were the common ingredients. The key here is for tech teams to deeply understand how the business functions.

2. Teams publish openly clear contracts with each other. In order to exist, each team needs to publish, visibly and clearly, their contract and reason for existence to the rest of the org: 

   1. A goal: what they want to achieve

   2. A strategy: how they will win (see template above)

   3. A roadmap: what they will build

   4. Metrics: how they are measured

   5. User flows: the UX

   6. Underlying systems: the tech

   7. Stakeholders: who they work with 

3. Make staffing flexible, regardless of reporting lines. To maintain velocity, we have a very flexible model, where folks can jump to different teams based on the business needs and work with engineers who might report to different people. Management is about hiring, staffing, coaching, and development. We leverage Tech Leads in scrum teams who don’t manage but drive strategy and execution. By keeping reporting structures the same and re-organizing pods, we can respond quickly to new opportunities without needing to constantly destroy relationships between managers and their teams. 

4. Embed platform teams as long as possible. Pure platform teams are often too far removed from the business context to make the right prioritization decisions and move with velocity. So we try to keep platform teams embedded in core product teams for as long as we can. Our payments platform was embedded within our Bill Pay product because most of the new use cases were B2B payments. Our data-science platform was embedded within our risk team since most of our data-science needs were on underwriting. We spin teams out after they’ve had a few wins to force them to work across teams.

5. Keep teams small so they move fast. We don’t like having more than 5 to 10 engineers on a given team. For example, we spun up a new team to build our Bill Pay product. That pod became four subpods as we grew, and we spun out one of those subpods fully to own workflows across Ramp.

6. Map the rest of the org to your tech teams. What’s important in org design is having single-threaded teams that have the resources they need to execute on big opportunities. We ensured early on that the entire company, not just the tech organization, was mapped to product goals, which were ultimately mapped to business goals. For example, each product “pod” has a dedicated Product Marketer, Product Operator, Product Partnerships Lead, and Product Counsel. They are responsible for quarterbacking the product strategy within their respective organizations.

6. How many PMs are there at this point?

We have 14 PMs at Ramp today (and we’re hiring!). 

We try to increase leverage as much as possible—defined by impact divided by headcount. We reward teams that were able to get more done with very little. For the first two years at Ramp, we had fewer than five PMs and fewer than 50 engineers as we scaled to $100 million in ARR. I try to restrict PM hiring until it’s patently obvious to everyone that product is the bottleneck to velocity. This does a few things:

1. It makes everyone at the company do some type of PM job—which helps build a culture of caring about business goals, customer pain points, and shipping. 

2. It makes every other PM have a larger scope—which eliminates the time-consuming fight for resources and politics. They simply have too much to do to ask for more. 

3. It makes the team welcome that PM when they actually join, and gives them clear value to deliver to give them a win.

7. What’s in your product-team tool stack?

In order to empower teams to move quickly, we focused less on which tool to use and more on what the tool should accomplish:...