Loading summary
Transcript40 lines
- [00:01]
Diego Zaks
Creating focus and choosing the right things to work on is the most important job that you can do at a startup or at a tech company, no matter the size. When that work is outsourced to a different team, to a leader, to someone else, you're just taking orders. So not your problem if it fails, not your fault. You don't feel that urgency to fix it. You don't feel that commitment and that, like, ownership of. I made this decision. I said, we're building this, not this, therefore this has to succeed.
- [00:28]
Rid
Welcome to Dive Club. My name is Rid and this is where design never stop learning. This week's episode is with Diego Zaks, who joined as the second designer at Ramp, which quickly became the single fastest growing startup ever. Now today, he's operating as the VP of Design. So this episode is going to be a deep dive into what makes the design culture at Ramp so special. And one of my favorite parts is just hearing how Diego thinks about feedback and the different ways that he's evolved how designers collaborate. At Ramp, we get into the relationship between velocity and speed and so much more. But first, let's go all the way back to the beginning to learn what it's like being one of the earliest designers at a hyper growth startup.
- [01:13]
Diego Zaks
So I'd met Karim and Eric many years earlier when they were doing their first company, Paribus. I was a design founder at a other fintech, like an if this and that for finance. And we came to them with the most naive question in the world was, hey, you guys have a million users, we don't. What do we do to get that million users? They were super nice about it. Many years later, I reconnected with Karim up in upstate New York, just casually as just friend of a friend. We were in the same place and he started telling me that, hey, I'm doing this corporate card, like credit card thing and design is going to be really important. No one's designed this stuff before. I truly designed it. Sure, there's products, but no one's cared. And I think the way we win here is that we actually care. We built something that's going to be that much better, that sort of planted a seed. And then it sparked the memories of all of the times that I'd done expense reports for work and how as a designer, I was particularly vulnerable to those bad experiences and wanted it to go away. Maybe a little bit of spite of, I really want to disrupt this thing. I hate this so much. If you'd asked me, I don't know, 10 years ago, what Am I going to be interested in expense reports? Was not a thing. It's very uncommon. But I think once you start digging into it in the world of corporate finance, you realize it's such a complex and interesting problem. It goes way beyond expense reports. That's just an expense report is a symptom of a culture that's not built on trust. Once you dig into this spite, you actually find that there's a lot of substance and there's a lot of complexity that only really good design thinking can bring simplicity to. So there was an opportunity to build a product and brand that people loved in a space that people hated. And it gave us the freedom to just be very different, position ourselves very differently. And that's fun because we gave ourselves permission to just be savages on our marketing and our positioning and just say, this is awful, it shouldn't be. And we were not afraid to offend anyone because we were so small. We could take chances and we could do a lot of experimentation in tone and brand and our own culture until something really clicked.
- [03:43]
Rid
It reminds me of this very specific memory that I have. It was the first time I used Ramp and I had joined Maven. We flew into Montreal for this off site, and I had to walk really quickly from my flight, like, the gate to my Uber, and I realized, oh, my gosh, I didn't put the company card into my Apple wallet yet, and I have to get it into Uber quickly. And I'm running late and I'm, like, doing this whole process on the mobile site as I'm walking through the airport, like, in a crowd of people. And it was so seamless, so seamless that, frankly, it, like, blew me away, where I was like, oh, my gosh, this is a really good product that was 10x better. I expected that I was going to hate that experience, and it ended up being really good. And I've been a big fan of Ramp ever since. So it's clear to me that, like today, you have, for the most part, accomplished that goal, at least to some degree, of building a brand that people love in a space that people hate. But can you talk to us a little bit about what that early momentum looked like when you joined? As the first designer, you are responsible for thinking through how design can be a differentiator in this space. So what did that first year or so look like as the person setting the tone for what Ramp can be?
- [04:57]
Diego Zaks
Thank you. That's very kind. What you say, I'm glad you love the product and have good experiences with it. That's really the whole point of this. It means a lot coming from you and it warms my heart. There's a couple months before launch where I'm helping the company. There was one design intern who was like, really holding up the fort. And the founder said, hey, we're going to need to give him some support. He's going to need someone to learn from and someone to help him grow his career and actually get us to that level. I came in as technically the second designer. We basically redid everything over a course of three months to really simplify. The thing that I came in to do was simplify everything. Just make it seamless. One click, one card, one click, one receipt. That was it. As much as I could reduce. Because I didn't know how it needed to work. I basically just decided to think about what would I want it to look like and what would I want it to feel like, and didn't do any competitive research to start. I just said, let me just clean slate. What should this experience of walking through the airport look like? If I were in that, in those shoes, what's the minimum amount of interaction that I can possibly get away with? Short of, your card's already there automatically. Right. That's the magic that we're trying to work towards, really trying to simplify and make things one click as much as possible. And I think not knowing how things should be was a real advantage at the beginning. One thing that also helped us was the things that really mattered to businesses shifted dramatically with the pandemic. Before the pandemic, there was this focus on points and rewards and like, extra kind of race to the bottom of just how much money can you give me based on these gamified points? When the pandemic hit, the only thing that mattered was, am I going to have a business in six months? Will I be able to make a dollar over the next year? Can I keep my employees? Can I just keep a business afloat? So two things together. The, hey, we're not trying to build feature complete competitor. And actually what matters completely shifted, gave us, I think, an advantage because we were able to just do things differently without any baggage and without any legacy issues in code and whatever. And we would just focus on stuff that made a difference for these businesses when they needed it most. And this was both in branding and messaging. So at the beginning, I was doing all of the branding, all of the marketing, all of the advertising, just everything. And the product as well, and the design systems, everything. It was really fun time. The fact that the world Just shifted meant that we could do things differently and it didn't matter that we weren't speaking the same language. It was actually an advantage that we weren't saying the same things, speaking the same language as everyone else. So we're able to end up with something that's radically different that now I think a lot of the stuff that we did then has been adopted by most of the players in the space. They all maybe change their tune a little bit. Hey, this doesn't matter. Design doesn't matter, brand doesn't matter. All that matters is points and cash back. And we've shown the world that no design and experience actually matter a lot. A third of our growth comes from word of mouth of people, hey, this design is great. It's so much easier to use. Like people like you that were walking down the airport and had a great experience when they expected it to be horrible. That's what finance teams want for the entire company. They don't want to be the bad guy, they want to be the enabler for everyone. Going back to your original question around thinking about what makes a good founding designer or what gave me the advantage to be able to execute, it's really being a jack of all trades of having actually done graphic design and books and advertising and branding and like I have pretty like winding career so that when, hey, this week we actually need to do ads. I've done that before. I can write copy, I, I can do Photoshop, I can then jump in and do an animation. Don't have to use after effects. But not just knowing the tools, knowing how to animate something, how to get timing, like when you do like the expectation of the movement and then you jump onto it. So there's all these things that really just come through. Having done all kinds of things in the past, I really do think that if someone wants to be a founding designer or they're they want to start a company just taking the windiest path that they can in design, trying to make as many things as possible, I think was the thing that allowed me to even have a shot at it.
- [09:50]
Rid
Real quick message and then we can jump back into it. So I've been using this new product to do research called genway. It uses AI powered interviewers to help you gather qualitative data at basically an infinite scale. So I've actually been interviewing listeners of this show all over the world. I tell the AI what I'm hoping to learn and then it has a dynamic conversation with each person. Genway then organizes all of the key Insights for me automatically. So I learned more in a two week study than I had in a year and a half prior. Needless to say, I am totally hooked. And if you want to take your research to the next level, head to Dive Club Slash Genway to get two months free. That's G E N W a Y. I've been anticipating today for quite some time because Raycast Notes are finally here. Their old Floating Notes product was my go to for quick captures, but they've truly taken it to the next level. There's markdown for formatting, keyboard shortcuts, multiple notes. You can even create a quick link to a specific note and assign a hotkey to it. So that way you can quickly open it up from anywhere in a single keystroke. It's just another way that Raycast helps me stay in flow while I work. So if you're not using it already, seriously, I can't recommend this product enough. Head to Dive Club Slash Raycast to get started. That's R A Y C A S T. Okay, now onto the episode. I love the idea of taking the windiest path that you can. Totally resonates. And I think that's maybe the reason why that particular role is my favorite in all of tech, is because there's endless opportunities to make an impact. No one's even going to really tell you exactly how to do it. You can just spot things and nobody's going to put you in a box. If you see a way to move the needle in marketing, or if you see the way to move the needle in how an automated email is written, you can do anything. And it's really cool to hear how you've had quite a spectrum of impact at Ramp.
- [11:51]
Diego Zaks
Yeah, I mean, I was, I was. For a while I was very confused and I didn't know where my career needed to go. There was a time where I was questioning, should I stay in design? When I first moved to the States, I'd come from a branding studio and at the time it wasn't very thrilled with design. I didn't want to do branding because I found it very pigeonholed into, hey, you've done this work for this restaurant. A different restaurant comes along and says, I want that work. Here's five new options. Like, nope, nope, nope, Give me that one. So after, I don't know, a couple dozen clients, just like that, I said a question like, do I want to do this? And is there a place in design where you can really flex all these different muscles and different ideas? And I hadn't found anything because everything that I'd done before was very specialized and you can become the best in the world at that thing. And that's completely valid. I respect that. From there's people who are truly masters of their craft. For me, there's a certain point where I start getting bored and start looking around. What else can I learn? And when I first encountered tech and startups, that was the place where I saw exactly what you said. No one's going to tell you what to do or where to focus. So you can find the overlap between what you want to do, what you're getting good at doing and what actually matters for a business. So you put in the work to find it and then you're rewarded by the ability to do something that matters, that you enjoy and that you're actually getting good at.
- [13:20]
Rid
So I want to zoom ahead in the story a little bit and get into like how you as a design org operate and some of those lessons that you internalize along the way. So maybe before we get into it, can you just give us a quick state of the world like how many designers are at Ramp and how do you think about the high level structure just so we can understand the ballpark that we're playing in?
- [13:41]
Diego Zaks
Yeah. So Ramp today has around 20ish product designers. Yeah, we have about 20 product designers, we have two design systems designers, we have two researchers and we've just spun up the product creative and growth creative functions within the design team. We also have the brand team which has been a part of. It used to be a part of a single design team, but now is part of the marketing organization. And I believe there's about seven full time people with varying numbers of freelancers, like true specialists that are just like experts at that thing that they do that we need that one skill. It sounds like a large team, but the company just crossed a thousand employees. So it's very actually quite a small design team. For the impact that we have and for the level of investment that we've done in the brand and on on product. And I say that it's small, not in a bad way. It's small. It's very intentionally small. If you remember what I was saying before about how we want to enable empowerment and trust within companies, it's the same deal internally. We want to enable that for ourselves. Every designer, no matter the level, they own a portion of the product that's pretty substantial. So it's really giving them total ownership and trust over considerable part of our product and a part of our revenue. As well. We've intentionally kept the design team really small comparatively to companies our size specifically, so that each person has the ability to always choose where to focus. They have to force the decision of prioritization on the cross functional partners to say, hey, product, this is how much design we can do. We cannot do all 15 things. We have to choose because if you're doing everything, you prioritize nothing. And creating focus and choosing the right things to work on is the most important job that you can do at a startup or at a tech company, no matter the size, when that work is outsourced to a different team, to a leader, to someone else, you're just taking orders, not your problem if it fails, not your fault. You don't feel that urgency to fix it. You don't feel that commitment and that like ownership of I made this decision, I said we're building this, not this. Therefore this has to succeed.
- [16:12]
Rid
What are some of the ways that you as a leader then effectively empower the individual ICs to make those right calls and prioritize what matters?
- [16:21]
Diego Zaks
My contribution to those decisions is generally how things will be connecting over the next year. It's very difficult to keep 20 roadmaps in your head. My job is to give people as much context as possible and I curate obviously what they need in order to be effective so that they can make the decision of we should do this now versus later. And the second thing is creating an environment where there's a lot of serendipity and just cross pollination of work. So as a design team, we spend an inordinate amount of time together. But we don't have five designers working on one button. Every designer is working on different surfaces. The overlap is pretty minimal. So you look around and you're looking at the travel product. The designer that like is building the Expedia for business, just one person and then there's the designer who's doing the AP or bill payments surface, which is another multi billion dollar business. And all this, there's all these people. So when you look around, you're seeing the future of the company being built like all around you. We do this in crits, we do this in open sessions where people just come up and share what, whatever it is that they're working on, ideas or things that they like. So my job is to consume as much of that as I can. Give people clear sometimes direction or just showcase, hey, this is overlapping, these are some dependencies. And then create the environment that allows for a organic cross pollination of projects and the best thing for me, the thing that like makes me the happiest is when I see one designer pull aside three other people and say, hey, I'm working on this thing. I saw that you're working on this. I saw that you worked on that. I saw that you worked on that. Let's grab an hour together and jam on my project, help me design this thing. So now you have the travel designer, the build pay designer and the like expense designer working on some AI thing altogether self organized and then that one person runs off and goes back to their team like guys, we solved it. Here's how it connects to all these other roadmaps and here's what the scope needs to be and here's how we need to change the scope, which I think is a very unique ask of the designers at Ramp specifically is to once we point out dependencies, organize, get the right people in the room, design together, make decisions of scope, and then go back to your product and engineering partners and change the spec based on cross functional work for the next six months. Hey, this team is building something in three months that we're going to need to support. Nobody knew this until we jammed on it. And that usually doesn't come from design. It's always a surprise later on that some engineer figured out and then it's.
- [19:14]
Rid
Super late or even top down. Like I feel like there's a theme that's coming around now where a lot of companies are switching to more of a top down model and spinning off their own derivative of what founder mode looks like for their organization. And so to see that level of autonomy and strategic decision making happening for each of the designers, owning those surface areas is definitely more unique than I think it even has been.
- [19:38]
Diego Zaks
I made this mistake in the past where I made myself the breaking point for where ideas come from and how people make decisions. That's something that I learned many years ago and I don't want to do that again. Where you can build a culture where designers look up to make a decision, or you can make a culture where designers come with a decision and they have an opinion and they just explain that opinion and you just either agree or disagree. It's their decision. Their job is to take context and make the best decision that they can at the moment versus the alternative, which is I'm at a fork in the road, which one should I take? Hey boss, you tell me in. That second one is very disempowering and I've built. That's probably one of my biggest mistakes and professional regrets. Is having built a team with that culture in the past where I was the decider on almost everything and it wasn't fun for them or for me.
- [20:42]
Rid
How does that change in direction impact the way that you give feedback to designers and think about how and where to influence the direction of an individual project?
- [20:53]
Diego Zaks
This is where I probably struggle the most. Because I'm a maker, I'm a builder at heart. I think by making so I have a very hard time thinking in the abstract. I generally have to just grab a design and just pull rectangles apart and then I can form an opinion on something that's based on some actual understanding of the experience. So for me to give feedback and I share this with every designer when they start, it's like, hey, if you see me in Figma moving stuff around, it doesn't mean anything's wrong. We had a designer that joined us from Facebook and his first take was, hey, if a VP at Facebook is in your Figma file, you've royally messed up. You're probably getting fired. I think positioning the work and the feedback as being extremely collaborative and extremely hands on has been probably the most important thing for just the way that I work. Just that I need to work. So generally I've had to change from designing the solution and showing people like, hey, here's what I wanted you to have done to making my version, Trying to deconstruct the decisions that were made to arrive at a different version and then share that framework for how I made my decisions, and then sharing that with people and saying, now go make your third version that's better. Like all the good stuff of what you did, some of the good stuff that I did, and here's a third version that's way better than anything that I would have done by myself. And I think that was one of the most humbling things that I've learned over the last few years, is working with other designers will always yield better results. It's always worth the extra time and the extra effort to bring another designer into your file and literally move rectangles around until something's better, which then makes my role a lot simpler. My role is to just point out, that could be simpler, that could be easier to do. There could be a lot less clicks here. Or this can fit within this broader spectrum of the work that we're doing. Here's how it should connect to other things. Now go figure out how it connects.
- [23:13]
Rid
I love the emphasis on visuals to support the framework rather than just delivering the end output. I do still Want to go a little bit deeper in how designers at Ramp collaborate, especially as everyone's owning their own unique surface area. Can you just talk about the rituals that are in place for collaboration and specifically how have you had to evolve those as the team has scaled?
- [23:38]
Diego Zaks
Yeah, so they've changed quite a bit and they're changing consistently. One of the first things that happened was that the level of formality for sharing work and crit went up over time. The more people you add to the group, the more formal it feels to share work, to share ideas. Ideas are very delicate at first and you want to truly protect them and nurture them. So the way we were doing create, the way we were doing share, which was just very ad hoc, very free, it wasn't very structured thing, it just became super formal on its own. People were spending a lot of time preparing for it and making these like big presentations and hey, I want it to look good and I'm making all these transitions and figma and all this stuff. And actually like, the work became 20% of it. So we had two choices. One was hit people over the head and tell them like, no, don't be formal, or lean into that and say, great, if you want to be formal, here's a place where you're really formal. What are the things that make it formal? And then let's create all these other avenues for you to get feedback that go from the most formal, which is a design crit, with myself, the design leadership. And we've essentially said these are the times when you want to go to crit, you want to bring something to Alpha, you want to go to Beta, you want to go to a GA or you want to go to our like super GA customers, you want to launch something to them. Those are the only times you need crit. The rest you have all these other avenues that are much lower touch practically. What does that look like? The least formal one, the safest environment that you have is we've created these truth seeking pods, which is three or four designers that are across the entire platform. So they're not working on the same things. They get together two or three times a week and every time that they get together, a different person presents their work through the lens of a decision that they've made. So the goal is to have a very small group of high trust people that are going to help you deconstruct a decision, a framework that got you somewhere and you set the expectation that you want real feedback, you want people to be kind, not nice. That's the Expectation for those groups. You've signed a contract together, you have these groups, they all have names, they're making their own swag. I'm hoping that they're working on their secret handshakes. I want them to really feel the tightest group. Then you have one level above that, which is your manager or your mentor. And I don't really believe in management. It's mentorship. So you have one on ones with your mentor, which happens ad hoc. Hey, I did this. How do I improve it? It's mostly junior designers that get support from the more senior folk. You then have more public, broader group things. You have an async version, which is our Slack channel, where you just record a loom every other day or so of what you're working on. Here's my whole flow. Here's decisions I made. Here are the things I'm not sure of. Here are questions that I have for engineering. Here's questions that I have for designers. Hey, X designer. I wanted to do something like what you did. What do you think? So you can actually request feedback from specific people, get questions on front of your team and then you get async feedback. And then the live version, the synchronous version of that is our open sessions where all of the designers go into an hour long call. Most of us are in the room and then we just ask, who wants to show something today? How long do you need? Five, ten minutes? What kind of feedback, if any, do you want? It always starts a little bit slow, but once the second third person has gone through, we like, we always have too many people signed up for it. So those are also super fun. And that kind of builds up to the crit itself, which is, hey, I've shared it with my pod, I've shared it with my manager, I've shared it with the entire design team. Crit's not a big deal.
- [27:35]
Rid
I love the emphasis on feedback. You talked about leading with kind of the framework and how you do that, but I would imagine that's something that ICs can start with and orient their presentations or asks around anything else that comes to mind for a designer listening who just wants to get a little bit better or identify different tactics they can use to get better feedback from other designers.
- [27:58]
Diego Zaks
I think the most important thing when getting feedback is to very clearly define what is it that you're optimizing for. Why does this thing that you are working on need to exist? And notice I say need to exist because I think one of the assumptions that most people make is that, hey, I'm working on something. You don't ask, should I be working on this thing? Should this flow exist? How do I justify it? So one is really articulating what the goal is, what the outcome is that you're trying to achieve, why this thing is important and why this solution is this approach is the right one. There is many times where we come out of a crit saying, we shouldn't do this at all. We need to make this whole process go away. Specifically on ramp or any business. Like any work thing, it's different for consumer. But generally for B2B software, the end goal of the user is not to do the thing that they're asking you that they want to do. It's to go home earlier to their kids who nobody actually wants to do that thing. So they came to you for a button to do a flow, to do a process. Maybe that process doesn't need to exist. The first thing that you need to do is super clearly articulate why does that thing need to exist? What is the outcome that it enables? And then it sets people in the mindset of, let me give you actual feedback that's not nitpicking the UI or the words in it, that's foundational and actually helpful to the approach. You might discover a new approach, completely different, that goes from 16 steps to two, because most of it was completely unnecessary and just there because it was legacy. And then the second thing is, if you have a new idea and if you're building a new product, if you're going to go to customers and you want to launch something, I think you need to define what is the unreasonable ask that you're going to make of them. I'll give you an example of a reporting product. Our customers are using their ERPs, their system of record, like NetSuite or QuickBooks, whatever. They use that as a source of truth. I think an unreasonable ask is to say, hey, I don't want you to look at that anymore. I want you to just look at it on ramp. That's the unreasonable ask of the reporting product. The reasonable ask is like, hey, would you use these graphs? Yeah, sure. But that's my actual source of truth. They're not going to tell you that, but you'll get the sense of, I'm building the right thing. People love my product. The graphs are super cool. And then you get in the craft of, you get the gradients and the graphs are perfect, beautiful and all that stuff. Like, you still have to do that. The first question was, will you get me to change my behavior, and it has to be something that's really difficult for me to want to do.
- [30:51]
Rid
I love how both of those questions force designers to zoom out and see the bigger picture.
- [30:55]
Diego Zaks
Yeah, that's the main role. That's what you have to do all the time, is just, how do I justify this thing that I want to work on that I think should exist? There needs to be really good reasons for it to exist, and if there aren't, you gotta be ruthless.
- [31:09]
Rid
All right, let's talk about how designers communicate those reasons to exist for a second. Because something that Lenny Richiski asked your VP of Product, he asked about a small tweak in your product development process that had a huge impact. And his answer actually pointed to you and talking about your decision to have designers spend more time working on more visionary prototypes and then sharing those out as loom videos. So can you talk about one, where that more visionary work fits into your process? But then two, are there common traits about those videos that get people excited enough to actually act on them and believe that this needs to exist?
- [31:50]
Diego Zaks
Great question. There isn't, like, specific format. There isn't. It's really just mostly free flow of, hey, I've mapped out some idea. Here's why I think this is a good idea. Here's where things come together. It's something that's really core to the way that we operate. And it can be painful at times, but the ask always is. If you're questioning the reason for something to exist, you need to understand how it fits within the broader picture of everything that user is trying to accomplish. So you need to truly understand what that person's job is, what their function, what their goals are, what motivates them, but also what they're afraid of. What are the things that are going to cost them their job, or they think they're going to cost them their job? What are the risks that they're taking by hiring your product? I don't think you can do that if you're operating at, like, the PRD level of let me design this flow. And what I meant by a little painful is sometimes you just want to get to the design, make the thing, move on to the next thing. We have a lot of stuff to do. There's a lot of work. People work super hard, and you want to feel like you're making that progress. Okay, I just. I shipped this feature, I moved on to the next one. It makes it really difficult to do that when you actually have to think about every feature in, like, the context of how everything else fits in. So I've had many instances where I'm completely paralyzed by the magnitude of how everything is supposed to come together. And then I just don't know where to start because I was just trying to make an update to an email. But that email requires me to change this other flow that requires me to change this other thing, which is foundational data model of this thing. And then comes back, where do I start? How do I get to this? And that's where I think really good product manager helps. This is how we've modeled the designing the product team to think. Jeff, our head of product and myself are very complementary in those ways where I can project really far and create like a compelling, large, complex vision and he can figure out what that next first step needs to be in order to get to that vision. This is a thing that I disagree with a lot of people on Twitter, but I see a lot of designers or design founders, they're throwing product under the bus. They're like, hey, we don't have product managers. Really super proud about that. I just don't think they've worked with really great product managers.
- [34:18]
Rid
Totally agree.
- [34:19]
Diego Zaks
I cannot imagine doing my job without just the incredible raw talent and just focus of the product team. At Rail is the kind of thing where it just, it makes no sense to me when I see people online just dunking on product. There's a lot of really bad product managers out there. But when you add a company, if you find a good one, they're worth their weight in gold. It's unbelievable just what an accelerant a good PM is for a design team.
- [34:47]
Rid
Hey, it's rid. I'm constantly asked about my favorite products, so I'm gonna take just one minute and give you a quick rundown of my stack. Dessen is how I ship design changes without having to code. Framer is how I build my websites. Genway is how I do research. Jitter is how I animate my designs and Play is how I design and prototype mobile apps. Visual Electric is how I generate all of my imagery and Raycast is my shortcut every step of the way. Now I've hand selected these companies to partner with me so that I can do these episodes full time. So the best way by far to support the show is to check them out. You can find the full list at Dive Club slash Partners. Okay, now onto the rest of the episode. I want to take a little bit of a left turn because you've shared some interesting thoughts on Velocity that I want to drill into, and maybe even just at a high level. Like, why do you think that people so often consider velocity and quality as opposites? And can you talk a little bit about that relationship at Ramp?
- [35:49]
Diego Zaks
I used to subscribe to this way of thinking that spending more time on something makes it better. If you're in Figma pushing Pixels around for longer, it doesn't necessarily make it better. Really, the thing that makes something better is actual user feedback. People trying it, failing, being confused, and then addressing that confusion. Because as much as I like to think that I know our customers, I've talked to literally thousands of Ramp customers. I am not them. I have not spent 40 years being a corporate controller finance company. So actually talking to real people and putting things in front of real people that are going to tell you just all of the tiny nuanced ways that you are wrong, that your assumptions are wrong, is the actual quality and the actual simplicity that matters. You cannot get a concrete answer to that. In theory, you can spend a lot more time thinking about something, trying to be right, when just putting it in front of an actual user and having them try to use it will immediately show you all the ways that you're wrong so that you can actually fix those things and be actually right faster.
- [36:56]
Rid
I want to push on this just a little bit because I do think it's possible to solve the problem in a way that's not confusing and achieves all of the end outcomes for a user. And yet you can still have a trail of paper cuts along the way that in isolation are like really small. And yet in my experience using Ramp, you don't have any of those. So if there is this speed to ship so that you learn, how do you ensure that you're not just taking those paper cuts and just filing them away in some backlog and forgetting about them and waiting sure to bundle them up into some big release. Like, how do you get to the point where, yeah, you're achieving the outcomes, but like, the product is good too? What does that take?
- [37:43]
Diego Zaks
I think the thing that really differentiates a successful designer at Ramp from a not successful one is their ability to just make notes of the areas where they have low confidence on a decision, but still make that decision and move forward with it. Put it in front of a customer. Just generally start by mapping out an entire flow in one app. Like just sit in one sitting, Just map out the whole solution that you have in your head, understand which parts you have high and low confidence, and then figure out ways to build confidence in those decision Points that you are low confidence on. One of those ways is you talk to your team, you talk to other designers, you ask customers. There's a definite limit of how much you can learn in theory. So at a certain point you just have to go to your engineers and say, we need to build this thing, we need to have actual customers using it. And then you'll see them fail in different areas. The reason why speed is the way to quality and is not the opposite of quality is that you just as quickly as you built the wrong thing, go and fix it. And you fix it in code and you fix it right away. So you maybe you spent, you know, you didn't spend four months thinking about something, but in those four months you've built it four or five times and you've gotten to a thing that actually works at the end. Rather than spending four months in theory debating ideas and debating approaches with people in their minds versus the ground truth of people failing at doing the thing you want them to do, people failing to do that unreasonable ask that you've asked of them or refusing to do it because of all the ways that you're wrong. And what happens in companies as they grow is people try to be wrong less often and they only want to take winning bets, which slows them down a lot. They put all this thought into the bets where the real way to win is actually like making more smaller bets and then being right 52% of the time. That's how casinos suck. Casinos operating. So I think try not to be one of those high rollers that just comes in with one gigantic bet, like all in with everything, and actually try to place a lot of really the smallest bets that you possibly can. And over a longer period of time, you're going to end up mostly right. So the way that we try to build product is as quickly as possible, figure out where you're mostly wrong, start changing those points to being mostly right, and then you get to a point where it actually works, it actually solves the problem. It actually deserves to exist and deserves to be a product. And your customers start coming to you saying, I want more of this. Can I please put more of my money here? There's two pathways to enabling that kind of risk taking embedding. One is making it really cheap to be wrong. We have really good engineers. Pragmatically, our cost per line of code is way lower than any of our competitors. So we can code circles around them. We're not afraid to waste code on them. We have created different tiers of releases so we have alpha releases where you essentially just handhold customers on a zoom call. You get in with them, you say, hey, I'm showing you something that's half baked. Will you help me make it better? And usually they'll say yes, because they love you're making their life better. They're like, yes, very invested in helping you. But you don't have to blow up the entire user base with a half baked idea. So you can just ship to a handful of customers that are very friendly, that you're literally on a call with them. And you get on a call with them every week and week to week, you show them how their feedback is being implemented and how their words have impact and affect the product. And that kind of creates a loop and a cycle where they actually want to help you more because they feel like they have the impact, so they're there for you. So you build this bench of super fans and then you roll it out to, let's say, beta when you want to try to see, does this work at scale without me on a zoom call? And then you go to GA is okay, does it work at super scale, reducing the blast radius of your mistakes and making it cheaper to take risks. The second lever that you have on this is helping designers build context and taste. So their intuition about the product over time goes from 30% right to 40 to 51%. And then you start getting like hyper effective people that are mostly right from the beginning every time. So they take two weeks on a project that should take four months and they're mostly right. So that's how you get to it. And then building taste, it's consuming things. We can't look at our industry because it's comically bad out there just how terrible these products are. So consume the best, most beautiful design out there. Go to museums, go look at art. Like a bimonthly event where we invite designers and people in the industry to speak and show their work. And we just listen, we just look at stuff. We have channels where we just share beautiful design all the time, Building taste, building context, to really get that intuition. And then when you pair that with, you can take a hundred bets in the time that it takes someone else to make one, you know, unstoppable.
- [43:12]
Rid
The more that I listen to you talk, the more it sounds nice working as a designer at Ramp and you have a bunch of open roles. So before I let you go, maybe we can touch on the hiring piece a little bit, because something that I think I saw you tweet, you talked about the importance of hiring for slope over skillset. So talk to me a little bit about what you are looking for when interviewing a design candidate to try to get that signal.
- [43:38]
Diego Zaks
If you find someone who has the skillset you need now, that's great. But if you find someone who's going to learn the skillset you need quickly, they're going, they're the ones that are going to be able to evolve as the company evolves. They're going to learn whatever skillset they need as the company changes. And we expect the company to change drastically every couple times a year. We tend to look for people who are self starters, who have taught themselves things, who have a true obsession for getting good at something, whatever that is. One of my favorite questions is do you play video games or are you good at video games? What are you really good at? What are you one of the best in the world and how did you get that? The answers are fantastic. People are really taken aback by what does this have to do with anything. So I like mountain biking. Great. Tell me about the gear. Like what do you, how do you get good at mountain biking? You just start talking about the brakes and the suspension, whatever. Doesn't really matter what it is. If you like to go deep on a topic, get really good at it, become or aspire to be one of the best in the world at it. You can do that for anything. You can replicate that. So that's what I look for. Especially in the more junior talent, they don't have the experience. It's very difficult to say, hey, have you worked on a fintech product before? I really couldn't care less of the background. It's do you know how to learn? Do you like to learn? Do you like to be better at things over time? And that's. It feels like a no brainer that everyone would say, yes, I like to be better at stuff. But I think it's actually quite rare to find people who obsess over becoming great at something, not just interested in things.
- [45:26]
Rid
You talked a little bit about just the traits of the designers that really succeed at Ramp. Is there anything else there that could give us a sense of what you're really looking for in designers?
- [45:38]
Diego Zaks
There's a level of confidence necessary in not being afraid to make these mistakes and to appear foolish in front of others. I think it's one of the biggest fears is to appear foolish in front of a group of other humans. It's a very human thing. Showing up to a group of financial experts and telling them I have no idea what you guys are talking about, but I'm here to learn. Will you show me how? I think that kind of attitude is extremely important. And finally, because it's such a collaborative team, really just being a good person, just coming at things with curiosity, with no ego, trying not to be wrong for a second longer than you need to be, is really one of the key things that we try to inspire in everyone. Which is another way of saying don't be married to a specific solution. You're trying to find out where you got it wrong. And if you start from that question, it's a lot more humbling, it's a lot less problematic to just change your mind. So then you're a lot more open to feedback. Feedback that you might not like, feedback that completely disagrees with, you've been working on for the last six months. You gotta turn it around.
- [46:50]
Rid
I love how that even just ties back to going into any given project. Identifying proactively where you have low confidence, that's a mindset shift. You're not looking for where you nailed it from the very get go. You're trying to figure out where might I have misstepped here?
- [47:05]
Diego Zaks
Yeah, I think there's an assumption that going back to empowerment and trust, if you're here, you're the some of the best in the world. You have my complete trust and admiration from day one. Completely up to you to figure out what it is that you want to do, where you think your time should go and how a project should evolve. I'm here to help. Just whenever somebody gets stuck or they can't see past a certain point, I'm trying to help them like look around a corner or figure out how things connect if they're missing some context. But again, I don't have the ability to go as deep on every project as the designers are going. So to me, they're the experts in the thing that they're talking about. So I have to take their word for it and I have to trust them. And that's why it's really important to know who you're hiring and who you're bringing to the team and how they're contributing and just keeping an eye on. Are they a good like design citizen and are they here to actually help everyone? Are they here to lift everyone up? Can they give feedback, learn how to give feedback if they don't know how? But are they trying to give feedback that is with the best intentions in mind? I've heard of really just horrible toxic cultures where people are trying to advance at the expense of everyone else. Kind of like trying to make themselves look better by tearing someone down. And sometimes you have to tear the work down. Never the person, obviously, but the work down sometimes means you tear down. But when that comes from a place of, let's make the work better, let's then deconstruct the decisions and the frameworks that someone used to get to a suboptimal solution, and let's help that person learn how to apply different frameworks or better frameworks, then it's really useful, and it becomes an experience of learning and lifting everyone else up.
- [49:00]
Rid
Quick note, if you're listening to this and you want to work with Diego, Ramp actually has six open design roles right now, so you can head to Ramp to check them out. Okay, let's finish this episode.
- [49:11]
Diego Zaks
That's the kind of place that I want to be at, where people are teaching each other. They're there for the work. They're there to help each other do the best work that they possibly can and to make sure that everyone around them feels safe and they can be vulnerable. Because from that, vulnerability is where actual innovation and good ideas come from. They don't come from me knowing everything and deciding what the roadmap is. That's not how it actually works. You have to collect the best people in the world, put them into a space that's really safe and where they can share and be vulnerable with each other, and then just sit back and let it happen.
- [49:51]
Rid
It definitely seems like it's working so far. Thank you so much, Diego, for coming on and pulling back the curtain on Ramp and just giving us a little insight into, like, how you think and how you work. And again, big fan of everything that you're doing.
- [50:04]
Diego Zaks
I'm a big fan of the podcast. I've learned already so much from everyone you've had on. Yeah, you're really delivering on your vision.
- [50:14]
Rid
Appreciate that. Hey, it's Rid. Don't forget if you want to go even deeper. Each week I send an email out to over 10,000 designers with bonus resources and key takeaways from these conversations. So head to Dive Club email to sign up. Okay, I'll see you next week.