The Great False Choice: Why Speed vs Quality Is Dead Wrong - Option 2

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. The secret isn't choosing between speed and quality—it's building systems that make both inevitable. Tara Feener explains their approach: 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: Innovation vs Stability The actual challenge isn't speed versus quality—it's balancing two complementary forces that both serve user needs. Adena Nadler from The Browser Company reveals the truth: 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 like, super-bogged down on While Nadler focuses on managing user expectations, Dick Costolo (19:15) reveals how to challenge organizational assumptions: XYZ and doing that one thing doesn't change the product dramatically. But again, look at an Instagram or a Facebook Instagram specifically once Kevin cam is pulled out of Instagram, it's oh, it wouldn't hurt to just add a you know direct message button here lots more people use it When you can direct message people, it's just one thing. And then next thing you know there are buttons all you know, hamburger menu at the top left buttons along the bottom. How tactically do you advise founders actually achieve that offloading everything but that is you know when you get yeah like you you know you shouldn't run, you shouldn't run product and engineering anymore. Get like get a get a director of engineering to manage and organize engineering but trying to keep product as lean as possible for as long as possible. Um, you know, and hey, you don't have to, you know, I mean, as you might imagine, and again, probably because of people like Steve Jobs, Steve loved to have his hands in marketing, you know, and was sort of famously involved in it. Um, you know, those are things that I would encourage, you know, the product founder to like, hey, it's going to there's going to come a point where you can't do all the marketing anymore either and they're like, but you know when so and so does it. It's hideous and ugly and feels like a crappy ad campaign like, well, better better that than you not being in charge, you know, being responsible for thinking about the product all the time. The great product founders want to always be involved in the marketing because that's like the way we talk about the product is the product I get it like, and I totally agree with that. I'm just saying like, there comes a point in the life of the company almost certainly where you have to have some people who are doing most of that and you're reviewing it or something, but you know, not like that's obviously stupid. And I'm going to go home tonight and spend all my time redrawing the print ad for the back of the Wall Street Journal. Just, you should be spending your time on the actual thing the customer is going to use and feel I'm just saying as you sacrifice things, sacrifice anything, but I'm responsible for what the product looks and feels like as you grow a company in the absence of you doing you as the founder CEO or whoever's running the company, you know, at Twitter, I wasn't the founder, I was a CEO at Twitter. As we grew, had to constantly work against the organic nature of the organization to slow down as it grew. Why does that happened? Communication architecture is like telephone play again, a game of telephone at a dinner table. you're like, okay, now there's a thousand people in the company. How do I make sure that everyone understands what I understand as quickly as possible? You know, I articulate some decision to a director of engineering. The director of engineering turns around and articulates that beautifully to the manager. The manager turns around and says Dick says, do this and then you've got someone in the New York office running around thinking like Dick's luna, dick's crazy, and he makes these arbitrary and capricious decisions and God only knows why. So So one in order the organization to move as quickly as possible, you really have to work hard against the natural tendency of the organization to slow down. So one of the ways we used to do that is launching an experiment at Twitter. I don't remember the exact time frame right now, but launching an experiment at TW in in the Twitter product to 1% of users to test some hypothesis took at one point, like 14 weeks. So, you know, we would like inste of just letting, of course, didn't originally take that long. It just grew and grew and grew organically. So we would start to Building Systems for Both product ideas post that I I kind of just put out in an egoless way to just like, hey, is this vibe with anybody? um, and usually, unless your like, ideas really out there and even those ideas, I think are some of the best like people start talking about it. And that's where I sort of mentioned, like, it's not uncommon for actually somebody just prototype or design something and share it in a thread. And like, the idea really, like takes shape like very quickly, then we have, uh, product updates where if there was a prototype, it's posted there and actually, it's already turned on and everybody in the entire company can just use 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 my fridge looked like a total disaster. And I like, was about to go take it all down when this like idea hit me of like, actually, fridge magnets are this really beautiful, like physical analogy for collaboration? So I read this big, lengthy product ideas post about like, like fridge magnets is like the future of like a collaborative internet, where you could imagine people sort of like leaving things as you go. That one we never prototyped, but it's one that we talk about still all the time. Um, a new hire started a couple months ago, The most successful teams don't rely on perfect execution—they build guardrails that make bad outcomes harder to achieve. When architecture enables rapid iteration, teams can test assumptions faster, gather feedback quicker, and improve continuously rather than episodically. Henry Modisett (16:04): The Continuous Improvement Model 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 Implementation Blueprint Start with Architecture: Build systems that support rapid iteration from day one. Make prototyping a core capability, not a specialized skill. Create Tight Feedback Loops: Tara Feener (05:38) describes their advantage: "We can pretty quickly given we're all using a web browser for work, close that dog fooding loop exceptionally fast." Question Every Process: Use Costolo's framework—what would have to be true for this to take two weeks instead of two months? Most barriers dissolve under scrutiny. Invest in Quality Systems: Build guardrails that prevent bad outcomes rather than processes that slow good outcomes. Focus on systematic prevention over manual perfection. Embrace the 80/20 Rhythm: Launch features at 80% completion, then polish weekly. The mathematics are compelling: five features improving simultaneously outpace one feature crafted in isolation. 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. Ready to escape the false choice? Start by questioning every process that slows iteration without serving users. Build systems that make quality inevitable, not optional. Remember that users care about solutions to their problems—not your development methodology. 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. Adena Nadler (The Browser Company) – Conversations on Quality (Episode 05) Chapter 1: The Membership Team at a Browser Company - This chapter details the role and responsibilities of the membership team within a browser company. It highlights their unique position in bridging the gap between user experience and product development. {\Insight#1} Section 1.1: The Scope of the Membership Team - The membership team is described as one of the more unusual teams within the company. Their role encompasses the entire user experience after product download. Their focus areas include: User understanding and product perception: How well users understand and like the product (both positive and negative aspects). Product quality: Ensuring the product is high-quality and free from bugs. Activities: This involves building the Help Center, managing customer support, conducting user research, quality engineering, and issue tracking. Their work fluctuates between performance monitoring and bug-fixing (especially before major launches like Windows releases) and exploratory user research on potential new features. {/Insight#1} Section 1.2: Incorporating Member Feedback - The team heavily emphasizes incorporating member (user) feedback into the development process. They use various methods: Direct feature testing: Launching features to a test group ("early birds") to assess quality and gather reactions before full release. A/B testing: Comparing different versions of a feature to see which performs better. Prototype testing: Showing prototypes to members for feedback. Surveys: Regularly conducting surveys to gather user opinions. Sparkle builds: Distributing test builds of new features to members for testing (both moderated and unmoderated). The approach is highly adaptable, depending on the specific feature or question being addressed. The team is currently exploring ways to gather feedback from non-members to expand their understanding of a broader user base. They creatively leverage their existing member base to connect with non-users. Section 1.3: Reaching Beyond the Existing User Base - The team acknowledges the limitations of relying solely on existing users (who are often early adopters) for feedback. They've implemented strategies to gather input from people who don't use their product: Member referrals: Asking current members to introduce them to friends who don't use the browser. Compensated participation: Offering payment to non-users to participate in research and provide feedback. This is a crucial incentive to attract individuals who wouldn't otherwise participate. Chapter 2: The Browser Company's Unique Approach and User-Centric Design - This chapter focuses on the browser company's unique approach to market positioning and its commitment to user-centric design. Section 2.1: Defining the Problem and Offering Solutions - The company is credited with recognizing and addressing common user frustrations with browsers that were previously considered individual problems: Addressing common frustrations: The company identified common issues like tab hoarding and managing numerous open windows as shared user experiences, rather than individual shortcomings. Emphasizing user understanding: The company's approach is to acknowledge and help users manage these "messes," making them feel understood and supported. Section 2.2: User Involvement in the Creation Process - The chapter highlights the company's deep involvement of users in the design process, from initial ideation to final testing: Onboarding redesign: The team used user observation as the first step in redesigning the onboarding process, watching users navigate the product without any onboarding to identify pain points. Extreme testing: They tested the extremes (no onboarding at all) to learn what features were essential. Gathering user sentiments: They explored users' emotional responses to certain actions, such as closing all browser windows, to inform design decisions. Advisory board for new features: They created an advisory board of non-users to help design and test a new, experimental feature, ensuring a broader perspective. Chapter 3: Balancing Design, User Feedback, and Retention - This chapter explores the challenges and strategies of balancing design aesthetics, user feedback, and user retention. Section 3.1: The Tension Between Design and Membership - The chapter highlights the inherent tension between design aesthetics and user retention, two key metrics for product success. The membership team prioritizes retention, while the design team might prioritize aesthetic appeal. Retention is measured by user engagement and churn rate. Retention as a key metric: The membership team uses retention (users staying with the product) as the primary measure of quality. Design considerations: The design team may prioritize aesthetic appeal or user experience, even if it doesn't directly impact retention. Prioritizing usability and performance: The membership team focuses on usability and performance (stability, speed, bug-free operation) as major factors influencing retention. Section 3.2: The Case of Onboarding and the Sidebar - This section provides specific examples illustrating the challenges of balancing design and user feedback: Onboarding redesign: A redesigned onboarding process, while appearing better qualitatively, didn't significantly impact retention, leading to a debate about its implementation. Sidebar usability: The sidebar, while offering a better user experience in the long run, has a steeper learning curve, potentially deterring users from adopting the browser. This highlights the trade-off between immediate usability and long-term user experience. Section 3.3: The Importance of Speed and Decision-Making - The chapter emphasizes the importance of efficient decision-making and rapid iteration in product development. Quick decision-making: Teams that make decisions quickly, whether based on clear data or strong internal conviction, tend to be more successful. Defining success: Success isn't solely defined by adding features; it can also involve removing features or deciding not to ship something. Chapter 4: Quality in Stages and Prioritization - This chapter discusses the different stages of quality assessment in product development and how the team prioritizes these stages. Section 4.1: Three Stages of Quality Assessment - The chapter outlines three stages of quality assessment: Design and need fulfillment: Does the design meet a user need? Polish and usability: Is the product fully polished, with clear usability and accessibility? Technical quality: Is the product technically sound, free from bugs, and without performance regressions? Section 4.2: Prioritization and Trade-offs - The team prioritizes the first two stages (design and polish) over the third (technical quality) due to the desire for rapid iteration and user feedback. They are working on improving their process for tracking performance regressions and bugs introduced by new features. Balancing speed and quality: The team prioritizes getting features to users quickly to gather feedback, sometimes at the expense of exhaustive technical testing. Flexibility and project prioritization: The team aims to maintain flexibility to take on new projects by avoiding getting bogged down in any one area. Chapter 5: Organizational Structure and Trust - This chapter discusses the browser company's organizational structure and its emphasis on trust and autonomy. Section 5.1: The Impact of a Flat Organizational Structure - The company's flat organizational structure, lacking strict hierarchies and mandates, offers both advantages and disadvantages: Accelerated development: The lack of bureaucracy allows for rapid experimentation and iteration. Potential for misdirection: The freedom can lead to projects that don't align with overall team goals. Section 5.2: Empowering Teams and Trust in Leadership - The company's approach emphasizes trust in team leads to determine the best working style for their teams. This flexibility allows teams to adapt their processes to their specific needs and projects. Team autonomy: Teams are empowered to choose their working style and processes. Adaptability: Teams can adapt their processes to suit their specific needs and projects. Final Summary This video provides a detailed look into the user-centric design process of a browser company. It highlights the critical role of the membership team in bridging the gap between user experience and product development. The company’s approach emphasizes incorporating user feedback at every stage, from initial ideation to final testing. It also reveals the inherent tension between design aesthetics and user retention, and the strategies employed to balance these competing priorities. The company's flat organizational structure, while offering advantages in terms of speed and flexibility, also presents challenges in ensuring alignment with overall goals. The company's commitment to user feedback and iterative development is central to its approach to building high-quality products. Idea 3: Idea 4: