1. Velocity, velocity, velocity.
2. Anchoring their product strategy to their financial model.
3. Their evolution from two-week sprints to bi-yearly planning with detailed quarterly roadmaps.
4. Focus on efficiency—they had fewer than five PMs and 50 engineers when they hit $100 million in ARR.
5. Teams are organized around business outcomes (e.g. increase attach rate for bill payments).
6. Product, design, and engineering all report to the CTO.
7. Emphasis on thinking from first principles.
8. Their approach to hiring, e.g. hiring ICs vs. managers

How Ramp builds product

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

• 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?

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.

1. 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.
2. 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:

1. 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:

2. 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?

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.

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.

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

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?

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

1. 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.
2. 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.
3. 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.
4. 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?

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?

This post is for paid subscribers