Lenny's Newsletter · Product & Work
TIER 5 2023-05-23
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](https://www.lennysnewsletter.com/p/how-figma-builds-product), [Coda](https://www.lennysnewsletter.com/p/how-coda-builds-product), [Duolingo](https://www.lennysnewsletter.com/p/how-duolingo-builds-product), and [Miro](https://www.lennysnewsletter.com/p/how-miro-builds-product)—and Notion, Linear, and Snowflake coming soon), I sat down with [Geoff Charles](https://www.linkedin.com/in/geoffrey-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](https://docs.google.com/document/d/1vQiTmIghKhCjlFU0HtdTmRNsyKmwv9gs/edit#heading=h.gjdgxs). 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](https://www.linkedin.com/in/geoffrey-charles/) and [Twitter](https://twitter.com/geoffintech).* # 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](https://docs.google.com/document/d/1vQiTmIghKhCjlFU0HtdTmRNsyKmwv9gs/edit#heading=h.gjdgxs) 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](https://ramp.com/careers)!). 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: 1. **Let teams decide for themselves what tools to use that maximize productivity.** Some people use a notepad (I do!). Some people use GitHub tasks. Some use Linear. It doesn’t really matter. We don’t track tasks—we track whether you shipped what you said you were going to ship. No burndown, velocity, story points—a lot of this process actually slows you down because it takes time and sucks the oxygen out of the room. Talk about value, not story points. 2. **Enforce a high bar for communication standards.** Everything at Ramp is publicly available. Teams are required to publish openly, with high clarity and high succinctness, their goals, progress, and targets. 3. **Invite anyone to give opinions on UX improvements or product enhancements.** For example, we created a #UX-input Slack channel where anyone can post improvements to our UX. We triage these posts using emoji, and this automatically creates Linear tickets to the right teams. We even have GPT summarize the issue for us. Individual teams are accountable for burning down a fixed percentage of improvements every sprint. 4. **Get the important things done today.** We don’t really maintain a backlog. If there’s a bug, we fix it (we have on-call engineers who are solely tasked with this). If we don’t fix it, it will escalate again if it’s important. Backlog grooming is low-leverage in a high-velocity environment because things change so quickly that the context of the task has changed. If it’s important, get it done. As long as your coordination tools hit #1-4, that’s all we care about. ### 8. You build one of the most beloved and successful products out there. What would you say is unique or central to your approach to product that leads to such a great and successful product? There is so much to say here. I’ll leave it at a few principles: 1. **Speed is a competitive advantage.** I wrote more about this [here](https://geoffcharles.medium.com/how-to-increase-product-velocity-8d0979a67c22). Everything we do is around velocity. This means high-velocity decision-making, keeping things simple, reducing team sizes and dependencies, maintaining extreme focus and work ethic, and letting the process work for us instead of against us. If your speed of shipping is extremely high, the cost of being wrong is much lower. 2. **Empower the folks closest to the problem to own the decision.** We give teams the resources they need to hit the goal, and we hold them accountable to hitting the goal. Simple as that. When folks at the lowest level of the organization can make the call, it creates better decisions, higher velocity, and a culture of high ownership and accountability. It also makes work more fun. You can see this joy show up in the details of our product—for example, check out what happens when you mouse over our card image. 3. **Sell your first customer.** Oftentimes, PMs throw products over to sales to sell without actually having gone through the motions of positioning, pitching, listening, and iterating. I task my PMs to find, pitch, and close the first 5 to 10 customers for their products. This forces them to work with customers from the start and iterate until they get it right. If you can’t find 10 customers, you haven’t built something people want, and we are not going to waste the time of the go-to-market teams. We also believe PMs need to learn to sell, period, whether it’s the company vision, the product, or new candidates. 4. **Think from first principles.** Thinking from first principles forces rigor and a complete understanding of a problem space. But you can’t think deeply about everything—you don’t have enough time. What’s most important is understanding *when* you should take the time to dive deep: 1. A critical user **experience** is dependent on it. Our payments PM understands what each line of an ACH payment file [represents](https://achdevguide.nacha.org/ach-file-overview#:~:text=An%20ACH%20file%20is%20a,must%20follow%20a%20specific%20order.); our head of design visited factory floors to choose the right premium metal card for our customers. 2. A high-cost business **decision** is dependent on it. For example, instead of taking legal counsel’s advice at face value, we read the statutes. How does the state of Texas define money transmission, and what does that mean for how we build the user experience of our compliance features? 3. An important business **process** needs to be defined for scale. Hiring is the best example of this. Our hiring guides are long and exhaustive. We list out the highly specific behaviors and attitudes you need to see demonstrated in order to evaluate a candidate. 5. **Take the bets with asymmetric upside.** If an outcome has a 98% chance of failure and a 2% chance of massive benefits for the business, take the [bet](https://ramp.com/blog/making-big-bets-in-business). That’s ultimately why startups are able to thrive. This applies to so many domains: hiring, selecting investors, building products, and even vendor selection. 6. **Simplify, simplify, simplify!** It is significantly harder to build a complex product that is simple at the surface for our users. We sweat every pixel and cut complexity until all our customers, from small mom-and-pop shops to multinational companies, can intuitively understand how to successfully use Ramp. Why have two clicks when you need one? Better yet, no clicks. The less time you spend on Ramp, the better. 7. **Taking risks demands humor, kindness, and gratitude.** If you’re taking asymmetric bets, you’re making decisions under high uncertainty and high risk. There are sometimes unknown consequences for other teams. Rather than spend time in analysis paralysis, we publish our assumptions and take accountability. In return, PMs can’t take themselves too seriously. We need to stay kind, express gratitude to all the teams we support, and be ready to apologize and own our mistakes. Life’s too short. ### 9. Building on the above, I assume much of your success has been thanks to hiring well and keeping a very high bar. In your product hires, what do you most look for (that maybe others don’t)? The story of Ramp is the story of getting hiring right. First we had to understand, from first principles, the attributes needed for high velocity: 1. **High slope, not intercept.** Because Ramp is growing fast, we need to hire people who are going to succeed six months from now when the scope is much bigger, not just today. This requires incredible learning ability and a growth mindset: our strategy relies on us winning many markets. We greatly discount domain expertise in favor of intrinsic curiosity. To understand abstractions at the lowest level, PMs need to love problem-solving. 2. **High agency.** We hire a lot of former (and future!) founders. The three PMs who’ve left Ramp all started companies. Note that high agency doesn’t come from ruthlessness. It comes from self-awareness: understanding and reshaping the limiting stories we tell ourselves of why something can’t be done. 3. **High humility.** Because taking risks demands humor, kindness, and gratitude. Because we focus on asking the right questions, not having all the answers. Because PMs are our first sales and support hires and have to be willing to roll up their sleeves and pick up the shovel. Because we empower the people closest to the problem to own the decision. Next, we needed to find non-obvious ways of recruiting that talent. Early engineering hiring has driven all the success of our product team. The first year at Ramp, our co-founder and CTO Karim [Atiyeh] was focused on only one thing: hiring the best engineers. That’s it. He didn’t spend much time with me on product strategy. He did this with strategies that big tech couldn’t use because they don’t scale. 1. **Find early talent before anyone else.** We focused on finding the young talent that demonstrated early signs of being a founder—winning programming competitions in high school, building businesses in college, dropping out to work at startups. He even found engineers from playing Fortnite. Then, by keeping the bar extremely high and focusing on our college internship program, we built a powerful brand on campuses. This started our talent flywheel. 2. **Allow only the best to interview.** To avoid implicit bias, you get extremely explicit about what you’re looking for. We standardize our interview process and the attributes we’re looking for—and teach new hiring managers what to look for. We do this with a long interviewing apprenticeship process, and debriefs after each step. The goal is to build the broad base of signals that hiring managers are able to perceive while actively warding off implicit bias. 3. **Don’t hire managers, hire stellar individual contributors.** You can learn to be a good manager over time, but if you are not a good PM, designer, engineer—you won’t be able to set the bar. The best PMs/designers/engineers will manage. This ensures that managers deeply understand the jobs to be done and can better assess whether they need a new headcount and who to hire. All our managers first earn the respect of their team by showcasing mastery of their craft as an IC. And all our managers, including me, own some workstreams as an IC to this day. 4. **Always place new PMs on a team with top performers.** This maximally sets them up for success and allows you to understand their performance as objectively as possible. If you’ve only changed one variable on a team with all-stars, you immediately know there’s a problem to help coach your new hire through. Finally, we ruthlessly capped headcount to keep talent density high. Every headcount that you add inherently slows down the rest of the organization because it increases the cost of communication and alignment within the organization. We see hiring as a last resort. To avoid bloat, we use a 4-step process: 1. **Will focusing on this opportunity accelerate progress toward our OKRs (value)?** 2. **If yes, can we accomplish this with automation or do we really need a person (deflection)?** Our Product teams don’t simply build products for the end customer—they build for internal teams as well. We deploy operational teams to tackle a problem, and apply technology to scale it once we understand the process. An example of this is our outbound sales teams—by understanding what their processes are, we were able to deploy a technology team to scale our outbound email motion to give each SDR “superpowers.” We call it OATs (Outbound Automation Team). With this, outbound has become Ramp’s largest growth channel. 3. **If not, is there someone in the organization who can do this job today (leverage)?** We value, hire, and promote individuals who think from first principles, not those who pattern-match from previous experiences. As such, we believe that high performers can flex into other responsibilities. For example, our Customer Success team is led by a founding engineer on the team who deeply understands our product and is able to create systems that automate a lot of the tasks that typical CSMs take on. Our Head of People started in risk operations and applied structured thinking and process to help us scale our talent operations. We focus on slope, not intercept. 4. **If not, hire the best, and we hold the manager accountable for the impact defined.** ## 10. What’s a fun or unique ritual you have at Ramp, either within the product team or more broadly? In order to maintain a culture of high velocity, you need to define and encourage values around risk-taking, humility, ownership, and teamwork. We reward people who take risks, who are humble, and who go out of their way to help one another move forward. To amplify these values, we have a Slack channel, #gratitude, where anyone can tag someone else at the company and give them “couscous.” Why couscous? Because in the early days we had a team in Morocco help bootstrap some of our platform, and they picked it. It’s easily the most popular Slack channel at Ramp. Every day, tons of people express gratitude for the help of others. And we make a point to express gratitude at the beginning of every sprint. We move with velocity especially to tell others how much we appreciate them.  *Thanks, Geoff!* *For more, follow Geoff on [LinkedIn](https://www.linkedin.com/in/geoffrey-charles/) and [Twitter](https://twitter.com/geoffintech). And [Ramp is hiring](https://ramp.com/careers)!* *Have a fulfilling and productive week 🙏* ## 📣 Join Lenny’s Talent Collective 📣 If you’re hiring, [join Lenny’s Talent Collective](https://www.lennysjobs.com/talent/welcome) to start getting weekly drops of world-class product and growth people who are passively open to new opportunities. I hand-review every application, and accept less than 10% of candidates who apply.  If you’re looking for a new gig, apply to join! You’ll get personalized opportunities from hand-selected companies. You can join anonymously, hide yourself from companies, and leave anytime. [Apply to join](https://www.lennysjobs.com/talent) ### 🔥 Featured job opportunities 1. **Wingspan:** [Product Design Lead](https://www.lennysjobs.com/jobs/6122b947-a5e1-44c9-a45e-30e305394589) (NYC) 2. **Mindbloom:** [Creative Producer](https://www.lennysjobs.com/jobs/389f9fcf-65bb-4852-836e-f3a732203212) (Canada, remote U.S.) 3. **Mindbloom:** [Acquisition Growth PM](https://www.lennysjobs.com/jobs/c74c7805-4b6c-42fa-a989-070e49a48898) (Canada, remote U.S.) **If you’re finding this newsletter valuable, share it with a friend, and consider subscribing if you haven’t already. Check out [group discounts](https://www.lennysnewsletter.com/subscribe?group=true) and [gift options](https://www.lennysnewsletter.com/subscribe?gift=true).** Sincerely, Lenny 👋