While most unicorns seem to be slowing down, there’s one that feels like it's just getting started: Ramp. 

From Techcrunch in July 2022:

Despite a cooling market, corporate spend management startup Ramp reports that it has more than doubled its revenue run rate since the start of the year.

The feat would be impressive in normal times, but is particularly so when tech companies — big and small — are laying off, freezing hiring and/or reporting slowing growth. 

How is Ramp continually able to grow, ship and improve the lives of its customers?

I spoke with Geoff Charles, Ramp’s VP of Product, to go deep into the decisions Ramp made to build a high-functioning product culture that scales.

Will:  How would you describe your product culture at Ramp? 

Geoff:  We have three vectors of our product culture. The first, which Ramp is mostly known for, is high product velocity. Over the last two years, we've shipped about five new product lines and a flurry of features for businesses of all sizes. And when we think about velocity, I think you essentially have to define or design your entire org and culture around speed, and be very open to the shortcomings of anchoring on speed. 

The second vector is around empowerment. A lot of times, especially in non-tech companies, product is the recipient of requirements from the business, so you have the business and the product teams, and they're separate organizational structures. And it's especially true in finance, tech, or FinTech, because finance tech is mostly finance companies that have a tech arm to it.

When tech companies really came out, they put that all on its heads, where business is actually led by the tech organization, they sell the products we build, we don’t build the products that they sell. That was a really intentional culture that we set forth at the beginning of Ramp to be product-driven. What that really means is building products for customers in service of the business, not for the business in service of customers.

The third vector is being okay with building what should be and not what is. That’s especially true in B2B, where it’s easy to take orders from customers, adding a button and a column, and you start building really poor B2B products that becomes nothing for everyone instead of something meaningful for a few people. So a third cultural aspect that we really anchored on was the ability to truly define what customers need instead of what customers ask for, and the ability to really deeply think about what things should be. 

Product Velocity 

Will: What are the trade-offs with anchoring around velocity? 

Geoff: There are a couple of dimensions here. The first is that the need for velocity falls mainly on our feature-facing teams whereas platform teams focus on precision, quality and uptime. We built very strong platform capabilities like authorization, payment systems and decision systems, that have compounded over time.

The feature-facing teams had less of a technical roadmap with regards to the long-term view of what they were building, and so the risk wasn’t “are we building it right?”, it was “is what we’re building what a customer wants?” So you essentially need velocity to ship it as quickly as possible and validate it with a customer.  Sure, you can use Figma prototypes–and we do use that a lot. But we also need to just build something fairly quickly and ship it. We definitely added tech debt in certain areas meaningfully, but deliberately, because we wanted to test it.  

The second is more on comprehensiveness, we shipped features that we’re not covering even close to 80% of the use cases. But we’re still meaningfully better than what was there today. It’s this concept of like, think through the 10x experience, walk back to the 1x or 2x experience and incrementally build and ship, which builds momentum. Nothing kills velocity more than a six month project that never sees the light of day. People get demotivated, and then the environment and the data changes. So ultimately, what you’ve actually set out to do is the wrong thing in the first place. So velocity helps mitigate that as well. 

So we end up sacrificing on two things. One is the tech debt in areas where we’re not certain, and two is the full-fledgedness of the feature. So the feature might have good user experience, but not solve every single problem for everyone. I think one way of reducing scope and increasing velocity is being much more opinionated around what you’re solving for. For example, permissions. Every single company will think about permissions in a different way. You could spend three years building the best permissioning system that has checkboxes for everything, which every single feature needs to be aware of and then your entire product development process slows down.

Or, you can say that we have four roles, and you take it or leave it. Sort of like a menu at a restaurant. You can train your entire staff to cook everything under the sun, or you can have six options. And you’re really good at those six options, and you’re much faster at actually creating that food. So we went down the opinionated route, and that helped us improve dramatically in terms of velocity because it reduces a lot of complexity with regard to our build and its maintenance. So there are certain things we decide that have an impact. Now the customer may really want fully customisable permissions, so we might lose that deal. That’s fine, we’re willing to lose these deals so that we can anchor back on velocity. 

But we never sacrifice user experience. We never, ever ship something that was a bad user experience. And the way we did that was to have a design report to the CTO just like product and engineering. Sometimes you have design reporting to product, and I think that’s a mistake because you essentially have conflicting priorities in terms of what is the right design and user experience. So having a very, very strong design team that is an equal partner in the product development process helps us make sure that we never sacrifice user experience. 

Empower your engineers

Will: Who is involved in the solution design once a problem has been defined?

Geoff:  One of the things I’ve realised within tech is that empowered engineers do not want to be given a requirements doc - they want to be co-founders of the solution. So the question really is when do you involve engineering? The moment that you have found a strong signal on the fact that you’ve found a very interesting problem and you’re converging on a potential solution, or forming an opinion on that solution. That’s when I’d bring in the engineering and design teams.

For each of these problem areas, we define a product leader, a design leader, and a tech lead. We don’t involve other cross-functional stakeholders but we do create visibility. We go into prototyping and come up with different solutions. We spend a lot of time thinking about user experience and using lightweight prototyping such as Figmas to go back to the initial customers that we did research on and say, “Hey, here’s a product that we built for you, interact with it, and let me know what you think? How do you feel? What do you value?” 

We spend a lot of time with engineering, designers and product in the room to build that empathy and energy from the customer. We spend a lot of time at the point and sometimes you’re like, why is an engineer in the room? They will code and build 10x faster after these types of calls, because they have empathy and they’re empowered. That upfront investment is so important. It has led to engineers being very different today than they were even three or five years ago, where they’re actually much more cross-functional. They’re more like product thinkers,not really interested in just the technical part, or that’s the DNA that Ramp looks for. I deeply believe that prototyping, involving cross-functional teams, being in the same room helps to find a good solution. Let’s go build something as quickly as possible and launch it. 

Respect for technology

Will: You mentioned that the business side is not telling you what to build, but you’re telling them what to sell. That’s a really fascinating dynamic. I’m curious how that was created, and what does it look like in practice? 

Geoff:  We started Ramp by building out the tech organization first. So the culture was set from the beginning around like a tech-forward culture. The way it’s maintained is continuing to hire people who deeply understand, empathize and respect technology. So in the interview process, it’s actually really important to harness that, as you can easily destroy a team if you hire a salesperson who just sees tech as IT that builds features that customers are asking for, without deeply understanding the fact that customers don’t actually know what they want.

To build long-term value at a company, you need to really invest in the technology you’re building and take bets that you’re probably three to five years away from customers actually wanting, and within the market it hasn’t even materialized. I think it really starts with the culture you set out at the founder level, because culture is set from the top. As a product leader, I was involved in hiring across marketing, sales, account management, talent and legal, and ensuring candidates each had a deep respect for technology.

Lastly, I think it’s about trust. If your tech team is building random stuff that customers don’t really use, it’s a sure way of reducing that trust, so with great power comes great responsibility where you need to prove every quarter, every sprint, every year the fact that customers love your product. And I think that’s really what I’m held accountable towards is the growth product through strong product market fit and word of mouth. And as long as that continues, then I’m trusted by the sales leaders to make those decisions. 

If you’ve made it this far, you may enjoy Product Life. Join thousands of product managers growing their careers by subscribing below:

Subscribe

PMs are bats and product comes first

Will: How does a product or feature at Ramp go from inception to market? 

Geoff:  I love transparency and data. So I anchor on an extreme amount of data points that are constantly moving around in the organisation. I sort of picture PMs as like bats, where we are blind and have sonar, and as long as we continue getting signals back we’re able to effectively navigate the crazy ambiguous world we live in. We have processes where we get a ton of feedback from customers at every single point. We have surveys, analytics, in-app product reviews, third-party reviews, sales calls, sales-driven requests, account managers, customer success gives support, feeding data–it’s just constant data and feedback back to the PMs. And then the question is, how the hell do you deal with all these different data points?

So I’ll give the example of travel. There were a lot of data points, pointing to the fact that companies had a problem with regards to controlling spending on Ramp that was associated with travel. So Ramp came out of the pandemic, there was no travel. So our entire product was really focusing on the accounts payable use case, you buying software and you paying your ads on Ramp. As travel picked back up, we basically woke up to the fact that many people were requesting to travel in different areas, spending tons of money on airfare and hotels, and a lot of companies were requesting Ramp to build a booking platform that helps me control what my employees are booking on.

So again, customers were like, let me be prescriptive with this solution. They pattern match with what already exists today, the TripActions or the Concurs of the world basically forces the employee to use a clunky, expensive and terrible platform to book their business travel. So Ramp was like, there’s an opportunity here. We are not going to take that solution and are going to explore this opportunity the right way. We prioritised it because we saw an increase of 10x the number of spend that was happening on our platform, we had data on how much money was being spent outside of Ramp on travel. And we saw that there was a big business opportunity for us to focus on getting more travel spend on the Ramp corporate cards. 

We did a bunch of interviews, took a look at the market, our competitors, win-loss rates, and segmented customer interviews based on industry and size of company. And we found that what the vast majority of businesses truly wanted at the end of the day was visibility and accountability. So Ramp decided that the problem wasn’t that you couldn’t book on the platform, but what you truly want is the ability to know who is spending in and out of policy and correct that behaviour. What if the moment that you actually swiped our card we gave visibility to the finance team on what you actually bought, all the way from the class of ticket, itinerary, price and per diem? And we could automatically flag anything that was out of policy and enable the finance team to call that back. That is a better experience than having to force everyone to book through a certain portal and charge $30 per trip to do so.

So that’s the Ramp travel experience, which was mostly an expense policy and travel integration with account information that automated all the visibility of business travel within a single platform, and that was with your corporate card. So you can book from anywhere but still have centralised control. This led us to have a different type of product and take an anti-Concur, anti-managed travel solution for the vast majority of businesses that don’t have a ton of travel needs, but all businesses need that control and visibility. 

Product Management at Ramp

Will: What do you look for when hiring product managers?

Geoff: One is, I look at people who deeply care about the customer.  Do you care deeply about the customer? If someone is having a pain point with your product, are you going to say you don’t know because you don’t use it, or are you going to take ownership and try to solve it? These are very different thinking structures. I look for people who you can ask them a question and they’re not just going to answer the question, they’re going to explain their thought process, framework and principles.

I find those types of people to be so much better at cross-functional work because they’re able to explain how they got to the conclusion. I do have a strong bias towards experiences, especially for early on start ups, you can’t take a bet on people with no experience. I anchor toward people who have shipped products in the past.

That said, I also love internal transfers–we’ve had two on the team. People who have come in through different areas that are more generalist, like Biz Ops or even a UX designer, and giving them the opportunity to take on small parts of the product, are always great ways of hiring people.

I also like ex-founders, people who have started a company are excellent PMs because they have grit.

And lastly, communication. People who are very concise in the way they communicate and are able to effectively tell a story are incredible. Those are the must-haves. 

If Ramp’s culture speaks to you, they’re hiring for tons of roles across product management, design, engineering and more. Check out their open roles here.

Thanks again to Geoff Charles for taking the time to share his experience on building product cultures, org design and product management. Give him a follow on Twitter and follow Ramp to keep up with their product velocity in real time.

If you want to see more deep dives like this, drop a like, comment or reach out to me on Twitter.

If you’re new to Product Life, subscribe below for concise, actionable and often surprising lessons for product managers.

Until next time,

Will