How the world's fastest-shipping teams discovered that velocity and craft aren't enemies—they're accelerants. The most persistent myth in product development is that you must choose between shipping fast and shipping right. This binary thinking has paralyzed countless teams, created artificial roadblocks, and spawned endless debates that miss the fundamental point entirely. But what if the entire premise is backwards? What if the teams building today's most beloved products have discovered something the rest of us are still missing? The Binary Trap For decades, product teams have been trapped in false choice thinking. Ship fast and accumulate technical debt, or craft carefully and miss market opportunities. This supposed trade-off has become so accepted that it's rarely questioned, despite mounting evidence that it's fundamentally flawed. right for our company. Is there a trade-off between speed and quality or is that like a false premise? I feel like, um, my goal is to like that seems to be the kind of a common perspective that people have and I feel like my goal is to kind of prove that wrong, um, to an extent. I think like depends on kind of where you want to draw the bar right. You know, the you know, you have companies like Apple who launch something once a year, but the stuff they launch happens to be like, you know, like often very innovative and just like hyper polished. I think for us it's like everything we can kind of 80 to 8020 everything but we do that every week and then everything. The last the thing that we 8020 last week, we then kind of circle back on And so it's like if you average it out over like a month, the polish happens faster and across more features. If you invest in velocity, you can actually make more things good, more all the time. If that makes sense. you're not just like obsessing over one thing and then launching one thing infrequently. Um, you're launching everything with your first good idea and then constantly trying to make it better from there. So it's this like, and and to do that requires like a, you know, like the whole company needs to operate that way. Um, and there's like, there's a lot of techniques I think in terms of process in terms of, uh, I think designer coding helps a lot because, you know, I can find a bug on on a Saturday and just go fix it and make that makes me feel better. But you also can kind of make investments into certain things that like off there, there's, um, lack of polish or lack of quality that kind of comes from. there's, there's some common symptoms, I guess. and so you can kind of invest in systems that make it hard to make things bad if that makes sense. And so that's like investing in design systems, right? If you make it so hard to make a a bad button, um, then you're going to have less bad buttons buttons and that's just like by investing in code, I think it's important for designers and product managers to be able to kind of think very holistically in terms of like where to find opportunity um practically when you know what you're going to work on there's just things that someone needs to make decisions about how is it going to work what's it look like uh who's running the project you know like who's going to make the kind of major technical decisions so i do think you know it's important for everyone to be able to think holistically but have very concrete ownership within a project because otherwise it gets very messy so we can all talk about these things but who's going to make the decisions because one of the most important facets of a fast moving company is decisiveness um and clarity of ownership and these things right so it's like we may like reassemble every time um you know so some projects maybe i'm the the the person leading it or driving it or sometimes maybe it's a product manager um but you know is a product manager going to do engineering no that isn't that's not their strength right so there is a bit of kind of like moving things around because a lot of stuff is ambiguous and so someone just needs The Real Tension: Stability vs Innovation that decision. I think quality is in stages based on where, where it is in the process. So for example, you can make an assessment on the quality of a product of like, how it's designed. Does it meet? Does it meet a member need? Like that's a part of quality. And then there's a stage of, like, is it fully polished? Like have you thought of every edge case? is the usability clear? Are the click targets big enough? Like is the text accessible? Like there's that. And then I would say that the final stage is making sure that the technical quality is really high and that it's not going to introduce more bugs, that it doesn't regress performance like things like that. And so I would say the thing we give up most on might be the last one because we do want, we do do a pretty thorough job of like design polish of like making sure it addresses a need. Um, I can give examples of cases where we haven't but like we've gone through those revs enough. I think the next step for us is making sure that like we're constantly tracking performance regressions and like introducing bugs by introducing a new feature. And that's because usually the minute we have design conviction, we want to like get it out to members immediately, cuz we love to see m reactions and we also just care about building the next great thing. Um, so I would say that's the place where we could grow most. that's that feels like the trade--off we're giving up on right now in a way the lack of hierarchy and the lack of like mandate of exactly what you need to build at any given time is both an accelerator and a decelerator. It's an accelerator in that like no red tape go try anything you know, if you if you want to go 100 miles an hour, you can. nothing's going to stop you. You could ship it tomorrow if you really wanted to. But it, in a way, it's also slows us down in that if you go 100 miles an hour, but like it wasn't quite at, you know, directed at the goal that the team needed from you, what is it all for? We think people work the best when they're working in their style, and we would never mandate or force a certain way of working because that feels counterproductive to the best work being produced. And so what we do is we place a lot of trust in the pod, lead to know how they work the best, but also to understand the members of their team. and say you create an environment that works for your team, maybe the environment of like an ios team needs to feel different than an environment of like the DevOps team that's like working, you know, on keeping things really stable, Maybe that like, functionality and how they work together is different than a team that's like constantly prototyping. So rather than like assume one of our, one of our values that the browser companies assume, we don't know, like, I, rather than assume that the leadership knows what the best way to work, we pass that on to as as close to the work as possible on, like process. And so, in a way, like we kind of can't choose between interesting features and stability and we need both. One is why people will switch, and the other is why people will stay, or maybe a little bit of both is why people would stay. Um, so I would say when we make trade-offs about the two, it's kind of like we set a bar for what we're able to get away with a little bit. Um, and we do everything that's, you know, meets that, that requires us to meet that bar. We try not to do more, because then we can't be as flexible, like to take on new interesting projects. If we're The Architecture of Velocity The secret isn't choosing between speed and quality—it's building systems that make both inevitable. Tara Feener from The Browser Company explains their approach: "We really architected our product with the goal of you should be able to prototype really quickly here. Our product architecture was made to facilitate velocity of product engineers." This is profound: instead of retrofitting speed into existing systems, they built velocity into the foundation. The result transforms how quickly ideas become reality. it the time from product idea to product update is so small most of the time. I mean, it varies depending on how big the idea is, but, um, most weeks, it's like, product idea gets traction ends up in product updates of like, hey everybody go try this And then we have a dog fooding channel where everybody in the company jumps on and gives feedback. We can pretty quickly given we're all using a web browser for work, we're able to like close that dog fooding loop exceptionally fast, Probably faster than a lot of other, um, companies who maybe their like employee base is not their end user. But for us, we are because we all live in a web browser day-to-day. So there's something magical that kind of happens there. And then we very rapidly will make a call. I'm like, hey, that this feels wrong. Unship It a designer I worked with years ago, he had this saying, it's what you leave out. Um, and I really think that this process, like sometimes we find something great and then we ship it to members and it solves the problem and it feels right. But when it doesn't, I think we're really good at leaving it out when I started about a year and a half ago. um, we were exploring a whole bunch of collaboration features at at that time. Um, and we shared a bunch of this public publicly. This was like a thing we were, we've always been thinking about and probably will think about in the future. Um, and I remember having this moment where I was in my kitchen in the morning and we had all these fridge magnets on the fridge and The Experimentation Mindset This question forces teams to challenge fundamental assumptions about what's "necessary." Most process exists for process's sake, not user value. The Memory Advantage make a decision What have you noticed is like the friction to building and if there's any like common thread what gets in your way the simple answer is you know you you want the least amount of people because then you don't have conversation you don't have debate you don't have um you know different ideas you so you know but you can't really scale that by definition so then become it needs to be around values and the companies that i've worked at that that feel slow there's a lot of people there's a lot of decision makers um and to be honest like a lot of that's for good reason i mean it it's not like any company can go fast um there's a lot of reasons why you can't you can't just like let anyone just kind of go build something in your company and ship it so i think you know for for many great reasons a lot of companies go slow but i think if if you really care about it you kind of have to make these trade--offs you have to accept like a little bit of risk somehow in whether it's like quality or redundancy um or you kind of just have to say that you know you have to be very clear like hey you don't get to make these decisions you're not you can't be in charge of this thing with a small company it's very easy there's typically more things to do than you have people to do it so it's kind of the it's easy to be like okay we're going to go fast um and so for us we can be you know we can just kind of divide and conquer okay for my design team there's like one designer that does all of mobile one designer that does all of web it's very easy to kind of divide that up uh and so anytime a mobile question comes up whether it's engineering or strategy or it's just one person to talk to and then he makes a decision so that stuff it's just naturally faster um the things that i do to make us even faster it's just like making it clear that that matters more than anything more than quality more than than uh debate more than feedback is just being decisive and keep going, Um, because we can always change it next week the thing is software is completely mutable. Um, and if you find something, let's say you ship something and then a week later, you realize it could be better somehow users won't remember the thing that was worse. So who cares? just make it better. Uh, and keep going, especially if it's like a bug or a detail or whatever, like nobody, they'll, you know, especially as a growing company, right there, you may have 100 users today, but you'll have 300 users tomorrow. So the the the new 200 users, they only know the new good thing. So you're better off just being Beyond the False Choice The teams winning today aren't choosing between speed and quality—they're choosing between different models of how quality emerges. The old model demands perfection before shipping. The new model achieves perfection through shipping. This requires three fundamental shifts: architectural systems that enable rapid iteration, cultural acceptance that improvement matters more than initial perfection, and measurement systems that track learning velocity over feature velocity. The future belongs to teams that ship fast AND ship right. The question isn't whether you can afford to prioritize both speed and quality. It's whether you can afford not to.