> ## Documentation Index > Fetch the complete documentation index at: https://meta.niceshare.site/llms.txt > Use this file to discover all available pages before exploring further. # Confidence Determines Speed vs. Quality > Confidence Determines Speed vs. Quality is a rule for the speed-quality mix: low problem confidence favors speed; high confidence in both favors quality. **Category**: Principles
**Type**: Decision Principle
**Origin**: Brandon Chu, *Product Management Mental Models for Everyone*, 2018
**Also known as**: Speed vs. Quality Trade-off, Confidence–Speed–Quality Rule **Quick Answer** — Confidence Determines Speed vs. Quality is a decision rule for how much speed to trade for craftsmanship. Brandon Chu stated it in 2018: your confidence in the problem's importance, and in the solution's correctness, should set the mix. The practical insight is simple. If you are not sure the problem is real, learn fast. If you are sure both the problem and the solution will last, do not take shortcuts. ## What is Confidence Determines Speed vs. Quality? **Confidence Determines Speed vs. Quality** is a decision principle: how sure you are about the problem and the solution should set whether you optimize for speed or for quality. > The confidence you have in i) the importance of the problem you're solving, and ii) the correctness of the solution you're building, should determine how much you're willing to trade off speed and quality in a product build. — Brandon Chu, 2018 Think of it as cooking. If you have never made a dish, you buy modest ingredients and cook a small pan. If you have made it fifty times for a wedding, you do not improvise with the cake. [Product thinking](/thinking/product-thinking) asks whether the outcome is worth building. This principle asks a follow-on question: given what you now know, how polished should this attempt be? Chu's rule is a barometer, not a slogan to "move fast" or "never ship junk." The spectrum has three basic postures. Low confidence that the problem matters favors speed. High confidence in both the problem and the solution favors quality. High confidence in the problem but low confidence in the solution calls for a balance: iterate, and raise the bar as evidence arrives. ### Confidence Determines Speed vs. Quality in 3 Depths * **Beginner**: Before you invest, ask "how sure am I that this problem is real?" If the honest answer is "not very," keep the first version cheap and quick so you can learn. * **Practitioner**: Score two numbers from 1 to 5, with evidence attached: problem importance, and solution correctness. Low/low or low problem → ship a test. High/high → raise the quality bar. High problem, low solution → run short [iterate-and-improve](/principles/iterate-and-improve) cycles until one of the scores moves. * **Advanced**: The trade-off is about this bet's craftsmanship, not your delivery system. Teams with sloppy tests and slow recovery cannot "choose quality" on a feature and still be safe. Also watch second-order effects: high-quality work on an unvalidated problem creates an installed base that resists the real solution later. ## Origin Confidence Determines Speed vs. Quality was named by **Brandon Chu**, then a product leader at Shopify, in his August 2018 essay *Product Management Mental Models for Everyone*. The essay treats mental models as a latticework for builders, not only for people with "product manager" in the title. Model 6 is this rule. Chu had already sketched the same spectrum a year earlier. In *Ruthless Prioritization* (March 2017), he argued that the speed–quality mix should follow your product assumptions: the problem may be an assumption, the solution may be an assumption, or neither may be. The 2018 essay gave that barometer its lasting name and tied both axes to customer-validated confidence. The idea has older cousins. Extreme Programming's [YAGNI](/principles/yagni-principle) ("You Aren't Gonna Need It"), popularized by Kent Beck in the late 1990s, warns against building unused flexibility. Eric Ries's *The Lean Startup* (2011) made the minimum viable product a learning device: when a leap-of-faith assumption is untested, the job of the first version is evidence, not polish. Chu's contribution was to split confidence into two questions—problem and solution—and to say explicitly which mix each pair implies. In the same 2018 piece, Chu also distinguished experiments, features, and platforms: experiments can be hacky because their job is learning; platforms need to be stable because other work will sit on them. ## Key Points The principle has four moving parts: two confidence questions, three default postures, an evidence rule, and a warning not to confuse this bet with the system that ships it. Do not ask a vague "are we confident?" Ask two separate questions. First, how sure are you that this problem is important to the people you serve? Second, how sure are you that this solution is the right one? A team can be right about the pain and wrong about the fix. A student can be sure a skill matters and still be guessing which course will teach it. Write the two scores down so they cannot silently merge. Low confidence that the problem matters: optimize for speed. Chu's example is a landing page for a feature that does not exist yet, used only to measure interest. High confidence in both problem and solution: do not take shortcuts, because customers will live with this work. High problem confidence and low solution confidence: balance speed and quality, run short cycles, and let evidence raise the bar. Confidence is a scale, not a switch, so the output is a mix, not a slogan. Mood is not confidence. Chu's high-quality pole requires confidence "validated through customers," so the scores have to rest on evidence rather than a hunch. A founder who "just knows" the market wants a feature is stating a hope. Five paid pre-orders, a waitlist spike, or a failed fake-door test is evidence. After each test, change the scores. The [fail-fast](/principles/fail-fast) move is useful here: kill a weak problem quickly so you can spend quality on a strong one. Choosing speed on an unvalidated bet is not a license to skip tests, backups, or rollback. Nicole Forsgren, Jez Humble, and Gene Kim argued in *Accelerate* (2018) that high-performing technology groups tend to have both faster delivery and more stable systems. In DORA's 2019 *Accelerate State of DevOps Report*, elite performers deployed 208 times as often as low performers and reported change-failure rates seven times lower. Use this principle to set craftsmanship on a particular bet. Use engineering quality so that a fast bet remains reversible. ## Applications Use Confidence Determines Speed vs. Quality whenever you catch a team, a household, or a public body arguing "faster" versus "better" as if those were identities rather than scores. In the kickoff, score problem importance and solution correctness from 1 to 5, and name the evidence. A 2 on the problem gets a fake door, a concierge test, or a one-week prototype—not a platform rewrite. A 5/5 on a payments flow gets design polish, load testing, and no "we will fix it in v2." Unsure whether a career shift is real for you? Do not pay for a two-year degree first. Take a night class, a short project, or a volunteer stint—the speed posture. Once the work still matters after three months of contact with it, raise the quality of the next investment. A new after-school activity, a meal plan, or a care routine is often a low-confidence problem: you do not yet know if it fits this household. Run a two-week trial with a cheap version. Save the expensive, hard-to-reverse version—a school change, a renovation, a medical device—for cases where both the need and the fit are already clear, which is also what the [reversibility principle](/principles/reversibility-principle) would advise. A city unsure whether a bus lane will help should paint a temporary lane and measure ridership, not rebuild the curb on a hunch. Once the problem is shown to matter, quality belongs in the permanent design: drainage, signage, and access. The same sequence applies to a community program: a six-week pilot, then a staffed service. ## Case Study ### Dropbox's Demo Video (reported 2011) In the late 2000s, Drew Houston was building Dropbox, a file-sync product that is easy to want and expensive to finish. Cross-device sync, conflict handling, and a seamless folder are years of engineering if you insist on quality first. The open question was not only "can we build this?" It was "do enough people care about this problem to justify building it well?" Houston's team did not wait for a polished public product to answer that. As Eric Ries later reported in *The Lean Startup* and in a 19 October 2011 TechCrunch excerpt, Houston made a simple three-minute video that showed the product as it was meant to work. He aimed it at early adopters on Digg, and packed the demo with in-jokes that crowd would notice. > It drove hundreds of thousands of people to the website. Our beta waiting list went from 5,000 people to 75,000 people literally overnight. It totally blew us away. — Drew Houston, quoted by Eric Ries, 2011 Houston also said that within 24 hours the video had more than 10,000 Diggs. Those two numbers—75,000 on the waitlist, 10,000 Diggs in a day—were evidence that the problem mattered at a scale a focus group cannot show. After that, investing in a high-quality sync engine was no longer a guess about demand. It was craftsmanship on a problem that had already pulled a crowd. The lesson maps cleanly onto Confidence Determines Speed vs. Quality. Confidence in the problem's importance was still being earned, so the first public artifact optimized for speed of learning, not for production finish. One boundary note: Houston already had a working prototype, and a video can test a value hypothesis you can see. It cannot test problems that only appear in real use, such as marketplace trust or logistics at scale. ## Boundaries and Failure Modes Confidence Determines Speed vs. Quality is a craftsmanship rule for a particular bet. It is not a universal excuse to be sloppy, and it is not a promise that speed and quality always pull in opposite directions. 1. **High blast radius overrides a "speed" score.** If an experiment can harm a patient, a child's safety, a payroll, or a city's water, you do not get to ship junk because the problem is unvalidated. Run the test in a sandbox, on volunteers, or on a tiny slice. The [hard choice model](/models/hard-choice-model) is useful here: impact can be high even when your confidence is low, and high impact still demands care. 2. **Delivery-system quality is not the same trade-off.** *Accelerate* and the DORA program found that elite teams often ship both faster and more stably. If your pipeline is fragile, "choose speed" on a feature will leak into outages. Fix the system so that a fast bet can be rolled back. Then apply Chu's barometer to the bet itself. A common misuse is **frozen posture**. Teams that once had to learn fast keep shipping rough work after the problem and the solution are both proven—checkout, identity, privacy. Other teams do the reverse: they polish a pitch deck for months because "quality" is their identity, while the problem remains a guess. Re-score the two questions on a calendar, not only at the start of a project. ## Common Misconceptions These three errors account for most of what goes wrong when people first hear "speed versus quality." They often trade off on a single bet: more polish usually costs time. They do not always trade off at the system level. DORA's research is the caution here. Practices such as small batches, automated tests, and fast rollback can raise both deployment speed and stability. Chu's rule is about how much craft to put into this problem and this solution, given your evidence—not about whether engineering discipline is optional. High confidence justifies raising the quality bar. It does not freeze the map. Markets move, and yesterday's validated problem can fade. Keep a cheap probe even on a 5/5 bet—usage data, support tickets, a small experiment on the next adjacent job. Confidence is a current score, not a trophy. Speed here means reducing the cost of being wrong, not insulting the user. A landing page, a concierge service, or a narrow prototype can be clear, honest, and safe. What you skip is unused architecture, speculative polish, and scale you have not earned. If the first version is deceptive or harmful, you did not apply the principle. You abandoned it. ## Related Concepts These ideas sit next to Confidence Determines Speed vs. Quality: some tell you what to build, others tell you how reversible or how simple the first version should be. Starts from a user outcome worth creating. This principle then sets how polished the next attempt to create it should be. Do not build what you are not going to need—the quality you skip when problem or solution confidence is still low. Surface a wrong problem or a wrong fix immediately, which is the point of the speed posture. The default move when the problem is real but the solution is not yet earned. Prefer two-way doors so a fast bet can be undone; raise the bar when the door is one-way. Classifies the decision before you pick a process—useful when impact is high even though confidence is not. ## One-Line Takeaway **Score how sure you are that the problem matters and that the solution is right, then let those two scores set the mix: learn fast when you are guessing, and refuse shortcuts when you already know.** This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.