The poster version of Sheryl Sandberg's "done is better than perfect" has been on office walls, in motivational decks, and in productivity blogs for over a decade. It has been used to justify shipping broken software, submitting half-finished analysis, and exiting meetings before decisions are made. In the process, something important about what Sandberg actually said — and what she meant — got stripped away.
The quote is real. The context around it is almost always missing.
Sandberg first shared it as a principle she observed on the walls at Facebook's early offices — a response to a specific problem that was actively harming the company's ability to move. The problem was not that people were occasionally sloppy. The problem was that a culture of excessive deliberation, endless revision cycles, and perfectionism as a form of risk avoidance was causing Facebook to miss the window on product decisions that needed to be made quickly, tested, and iterated.
"Done is better than perfect" was not an endorsement of low quality. It was a counter to a specific pathology — and that distinction matters enormously for anyone trying to apply the principle in their professional life.
This article unpacks what Sandberg was actually describing, where the principle applies and where it actively causes damage, and how the best practitioners in fast-moving fields navigate the tension between quality and velocity in ways that neither ideology — radical perfectionism or radical iteration — captures correctly.
The Specific Pathology "Done Is Better Than Perfect" Was Addressing
To understand what Sandberg meant, you have to understand the environment she was describing. Facebook in its scaling phase was making decisions about features, interfaces, algorithms, and infrastructure at a pace that most organisations never encounter. The product was changing faster than any single team could fully analyse. The data needed to make good decisions could only be generated by shipping something and observing what happened.
In that context, the specific dysfunctions that perfectionism was producing were:
Paralysis by pre-launch analysis.
Teams would spend weeks modelling what would happen if they made a particular change, when the fastest and most accurate way to know what would happen was to make the change and measure the result. The analysis consumed time without generating the information it was meant to produce — because the information only existed in user behaviour, and user behaviour could only be observed by shipping.
Revision cycles as anxiety management.
A product team would build something to an acceptable standard and then continue revising it — not because the revisions were improving the product's chance of success, but because revision felt more controllable than the uncertainty of launching. The tenth revision of a feature rarely performed significantly better than the sixth revision would have. The six weeks it took to get from revision six to revision ten could have been spent generating real user feedback and making decisions based on data.
Perfectionism as blame diffusion.
If a feature launched and failed, the team that shipped it was responsible. If a team spent months revising and never launched, responsibility for the absence of a result was diffuse and difficult to attribute. In a culture where failure was stigmatised, perfectionism became a rational defensive strategy — not a pursuit of quality, but a method for avoiding accountability.
These three dysfunctions — paralysis, anxiety management, and blame diffusion — are what "done is better than perfect" was designed to address. The principle is a counterweight to these specific problems, not a general philosophy that quality doesn't matter.
What Sandberg Was Not Saying
Before examining how to apply the principle correctly, it is worth being precise about what it does not mean — because the misapplication is both common and costly.
It does not mean ship broken things.
The Facebook context involved products where the cost of an imperfect launch was a suboptimal user experience that could be iterated quickly. It did not involve products where a flaw could cause irreversible harm — financial loss, regulatory breach, safety failure, reputation damage that could not be recovered. "Done is better than perfect" does not apply to systems where the cost of failure is asymmetric and non-recoverable.
A security team that ships a half-tested authentication system because "done is better than perfect" has misapplied the principle. A financial analyst who submits a model with known errors because "done is better than perfect" has misapplied the principle. A developer who pushes to production without basic testing because "done is better than perfect" has misapplied the principle.
The principle applies to contexts where you can learn from failure, iterate, and improve. It does not apply to contexts where the failure itself forecloses the opportunity to iterate.
It does not mean that all speed is good.
The Facebook context required speed because the cost of delay was real — competitors were moving, user behaviour was evolving, and the information needed to make good decisions was only available through deployment. Speed had genuine strategic value. In many other contexts, speed has no particular strategic value, and the cost of getting something right the first time is well justified.
A pitch deck that is presented to a room of investors who will make a funding decision in that meeting should not be submitted as "good enough." There is no iteration cycle after a funding meeting goes badly. Speed in that context serves no purpose — thoroughness does.
It does not mean avoid reflection.
The launch-measure-iterate cycle that "done is better than perfect" enables only produces value if the measurement and iteration parts actually happen. A team that ships quickly and then fails to measure what happened, draws no conclusions, and makes no changes to the next version has simply shipped something imperfect and stopped there. That is not the principle in action. That is an abdication of accountability dressed in the language of iteration.
The Quality-Velocity Matrix: Where This Principle Actually Lives
The most useful frame for understanding "done is better than perfect" is not as a universal principle but as a quadrant-specific one. Different work environments have different cost structures for quality failures and different value structures for speed — and the right position on the quality-velocity spectrum depends on which quadrant you are operating in.
Quadrant 1: High velocity value + Low failure cost.
This is the Facebook context. The information you need exists in user behaviour. Failure is recoverable. Speed has genuine strategic value — either because competitors can capture the market position or because user behaviour is evolving and slow decisions are made on stale information. In this quadrant, "done is better than perfect" is genuinely correct strategy.
Examples: Consumer product features, A/B test variations, content experiments, early-stage startup MVPs, internal tools where the cost of downtime is low.
Quadrant 2: High velocity value + High failure cost.
This quadrant is the most dangerous one to navigate. Speed matters but the failure cost is significant. The right approach is not "done is better than perfect" — it is "fast enough with sufficient safeguards." This means doing the minimum testing necessary to prevent the catastrophic failure, not the maximum testing that produces perfect confidence, and shipping with monitoring in place to catch problems early.
Examples: Payment systems where speed matters but financial errors are catastrophic, security features where time to deployment matters but vulnerabilities create irreversible damage.
Quadrant 3: Low velocity value + Low failure cost.
In this quadrant, neither speed nor quality particularly matters. Ship when it is convenient, at whatever quality level makes sense for the audience. This is where most people actually operate most of the time, and neither "done is better than perfect" nor perfectionism is especially useful as guidance.
Examples: Internal documentation, low-stakes presentations, routine reports to small audiences.
Quadrant 4: Low velocity value + High failure cost.
This is where perfectionism — or at least thoroughness — is genuinely the right strategy. Speed creates no strategic value, and failure creates significant, potentially irreversible cost. This quadrant is where the "done is better than perfect" principle actively causes damage if misapplied.
Examples: Medical device documentation, regulatory submissions, investment prospectuses, critical infrastructure code.
How Facebook Actually Practised This: The Hacker Way
The operational mechanism that made "done is better than perfect" functional at Facebook — rather than a licence for mediocrity — was a specific development and decision-making practice that Zuckerberg described as the Hacker Way. Understanding this practice clarifies why the principle worked in that context and what conditions need to be present for it to work elsewhere.
The Hacker Way had four essential components:
Component 1: Build, test, learn cycles with short loops.
The Facebook product process was designed around extremely short feedback cycles. A change would be built, deployed to a small percentage of users, measured against specific metrics, and the team would have data within 24-48 hours about whether the change was producing the intended effect. The cycle then repeated.
This meant that "imperfect" in the Facebook context did not mean broken and abandoned — it meant incomplete and evolving, with the incompleteness being addressed through continuous measurement. A feature that launched at 80% of the intended quality would be at 95% within two weeks if the measurement and iteration loop was functioning.
Component 2: Metrics-first design.
Before anything was shipped, the question was: what metric does this change affect, and how will we measure whether it moved in the expected direction? This requirement meant that "done" was not defined as "feature is built" but as "feature is built and we have a way to evaluate whether it is working."
This is the element most often missing when the principle is applied outside its original context. "Done" without a measurement framework is simply "shipped and forgotten." The Facebook version of "done" included the measurement infrastructure as a requirement of the definition.
Component 3: Rollout controls and kill switches.
Nothing shipped to all users immediately. Everything launched to a percentage of users, with the ability to roll back instantly if a problem appeared. The "done" in "done is better than perfect" was not a permanent deployment — it was a controlled experiment with a manual abort option.
This risk management structure is what made imperfect launches tolerable. If something went badly wrong, the blast radius was small, the problem was caught quickly, and the rollback was immediate. The combination of limited deployment and rapid feedback made the cost of failure low enough that the speed benefit justified accepting it.
Component 4: Post-mortems without blame.
When something launched and failed, the standard response was a structured post-mortem: what happened, what the impact was, what the root cause was, and what changes would prevent recurrence. Failure was treated as information, not as a judgement on the team that shipped.
Without this component, the other three cannot function. If failure is punishing, teams will not ship imperfect things even when the conditions make it the right strategy. The psychological safety that made the Hacker Way work was not just cultural rhetoric — it was enforced through the post-mortem format and leadership behaviour.
What "Done" Actually Means in High-Quality Professional Work
The most nuanced element of the "done is better than perfect" framework is the definition of "done" — and it is where most practitioners get into trouble when trying to apply the principle to their own work.
"Done" in the Sandberg/Hacker Way context is not the same as "drafted" or "built" or "shipped." It is closer to "fit for purpose at this stage of information." This distinction is critical.
Consider a data analyst working on a market sizing model for a product decision that needs to be made in the next 48 hours. A perfectionist interpretation might spend those 48 hours trying to get the model to 95% confidence across every variable. A "done is better than perfect" misapplication might submit a rough estimate with errors that cause the decision-maker to make a structurally wrong decision.
The correct interpretation is: what confidence level and which variables does this decision actually require, and is my current model sufficient to support those requirements? If the decision depends primarily on order-of-magnitude estimates rather than precision figures, a 60% confidence model on the key variables might be genuinely "done" — not because precision doesn't matter but because this specific decision doesn't require it. If the decision requires precise figures to produce a correct choice, 60% confidence is not "done" — it is "insufficient and dangerous."
"Done" is not an absolute standard. It is contextual. It means: does this output provide what is needed to make the next decision or take the next action? If yes, it is done. If no, it is not.
This contextual definition of done is what practitioners in agile software development encode in the concept of "definition of done" — a specific, pre-agreed set of criteria that a piece of work must meet before it is considered complete. The work does not need to be perfect, but it does need to meet the definition.
The power of a pre-agreed definition of done is that it removes the subjective judgment that both perfectionism and carelessness exploit. Perfectionism exploits the absence of a clear completion criteria by adding requirements indefinitely. Carelessness exploits the same absence by stopping prematurely. A clear definition of done closes both exploits.
The "Good Enough" Trap: When the Principle Gets Used as a Rationalisation
There is a version of "done is better than perfect" that operates as a rationalisation rather than a strategy — and it is important to distinguish it from the legitimate application, because the rationalisation is both common and genuinely harmful.
The rationalisation version sounds like this: "I know this isn't quite right, but we're going with done is better than perfect here." The tell is the phrase "I know this isn't quite right." This is not a practitioner choosing velocity over quality in a context where the trade-off is justified. It is a practitioner using a recognised principle to deflect accountability for work they know to be inadequate.
The distinction matters professionally because:
Legitimate application: The practitioner has evaluated the context (quadrant), established or agreed a definition of done, shipped when that definition is met, and has a mechanism for measuring and iterating. The work might be imperfect, but it is fit for its current purpose and will improve through structured learning.
Rationalisation: The practitioner has not evaluated the context, has no definition of done, ships before the work meets the minimum requirement for its purpose, and has no measurement or iteration plan. The imperfection is not a strategic choice — it is an unexamined abdication of quality standards.
The professional consequences of the rationalisation version compound over time. A practitioner who consistently ships work that is below the standard required — regardless of the language used to describe the decision — develops a reputation for low-quality output. That reputation is difficult to reverse because it accumulates through many individual small incidents, none of which seems significant on its own.
The practical test for distinguishing legitimate application from rationalisation: would you be comfortable explaining the specific quality trade-off you made to the person whose decision depends on this work? If the answer is yes — if you can articulate specifically what you chose not to perfect and why, and the decision-maker would understand and agree — the principle is being applied legitimately. If the answer is no — if explaining your reasoning would reveal that you simply stopped before the work was sufficient — it is rationalisation.
The Perfectionism Trap on the Other Side
Sandberg's principle addresses one failure mode — the paralysis and defensiveness of excessive perfectionism. It is worth spending equal time on the conditions under which perfectionism is not a pathology but a discipline.
The professional domains where thoroughness is not just acceptable but essential include, unsurprisingly, those where the failure cost is irreversible, the audience is sophisticated and unforgiving, and the product of the work creates dependencies that make error correction expensive.
Investment banking analysis: A financial model that will inform a decision about a major acquisition is not a context for iteration. The model needs to be right — not because perfection is philosophically preferable but because the decision downstream of the model is consequential and the stakeholders making that decision are sophisticated enough to identify errors. An analyst who ships a model with known errors and plans to "iterate based on feedback" does not understand what "feedback" means in a deal context.
Clinical and regulatory documentation: A regulatory submission that is imperfect is not simply imperfect — it may be returned, which delays product approval, which has significant financial and patient consequences. The iteration cycle in regulatory environments has a cost structure that makes "ship and learn" genuinely wrong.
Security architecture: A system architecture that has known vulnerabilities is not a candidate for "ship and iterate" if the iteration cycle creates the window for exploitation. The vulnerability exists before you learn from the failure, which is the precise definition of a context where iterative learning does not apply.
In each of these domains, the relevant discipline is not "done is better than perfect" — it is the ability to be thorough, structured, and precise under time pressure. These are different skills, and confusing them by applying the wrong framework in the wrong context produces predictable damage.
The practitioner who understands "done is better than perfect" at depth is not someone who always ships fast. It is someone who can accurately identify the context they are in and apply the quality strategy appropriate to that context — which is sometimes thoroughness, sometimes iteration, and often something more nuanced than either.
Sandberg's Own Career as the Case Study
One of the most informative aspects of how Sandberg has discussed "done is better than perfect" is the context in which she applies it to her own professional choices — and the places where she clearly does not.
Her work at Google and Facebook on advertising products, business development, and operational scaling was genuinely iterative. She has described launching imperfect programmes, learning from their performance, and improving them rapidly. This is the principle in legitimate action — in a domain where velocity had competitive value and the feedback mechanism (advertising performance data) was direct and immediate.
Contrast this with how Sandberg approached her book "Lean In." The book was not shipped as a minimum viable product. It was the product of years of research, extensive review, feedback from dozens of people including researchers and practitioners, and multiple significant revisions. The reason is obvious: a book is not iterable the way a software feature is. Once published, it cannot be silently updated. The audience — professional women navigating workplace dynamics — would be making real decisions based on its contents. The failure cost was high enough, and the iteration opportunity limited enough, that thoroughness was the appropriate strategy.
This is not a contradiction of the principle. It is a demonstration of sophisticated context recognition. The same person who coined "done is better than perfect" as a operational norm for product development applied a different standard — without ever being inconsistent — to work where the context demanded it.
The lesson is not that Sandberg is a hypocrite for being thorough where thoroughness matters. The lesson is that the principle is a tool in a toolkit, not an identity. The practitioner who understands it applies it where it serves the work and sets it aside where it does not.
The Application in Data Science, Finance, and Technical Roles
For practitioners in technical and analytical fields, the quality-velocity tension is a daily reality. Abstract frameworks are useful; specific application guidance is more useful. The following examines how the principle applies — and where it does not — in domains relevant to Meritshot's programmes.
Data Science and Analytics:
In exploratory analysis, "done is better than perfect" is often genuinely correct. When a data scientist is asked to investigate whether a pattern exists in data, the most useful first deliverable is a rough analysis that answers yes or no. A comprehensive, fully validated, edge-case-checked analysis of a question that turns out to be uninteresting is wasted work. Ship the exploration, get the yes/no, then invest in precision if the answer warrants it.
In production model deployment, the calculus changes. A recommendation model that ships at 70% accuracy might be acceptable if the consequence of a bad recommendation is a slightly suboptimal user experience. A fraud detection model that ships at 70% accuracy has a very different failure cost. The 30% it misses are financial losses. The appropriate threshold for "done" is not determined by the model — it is determined by what the 30% failure rate costs in the specific deployment context.
Investment Banking and Financial Analysis:
Most analytical deliverables in finance have a clear "done" threshold: does this analysis support the decision that needs to be made? An industry analysis that gets the order-of-magnitude economics right is often genuinely done for an early-stage deal assessment. The same analysis when it becomes the basis for a fairness opinion in a completed transaction needs a very different standard.
The practical guidance: identify the decision that this work supports, identify the precision requirement for that decision, and set the "done" threshold accordingly. The error most junior analysts make is applying a constant precision standard regardless of the decision context — spending the same time on a first-pass feasibility assessment as on a final due diligence model.
Full Stack Development and Cyber Security:
In full stack development, the iterative deployment model that made "done is better than perfect" famous is the standard operating mode. Feature flags, canary deployments, A/B testing, and continuous deployment pipelines are all implementations of the same principle — ship something, measure it, improve it. The principle is operational infrastructure in this context.
In cyber security, the calculus is explicitly context-dependent. A new internal tool that handles low-sensitivity data can be shipped imperfectly and improved. A new authentication system that handles credentials for all users cannot. The error pattern in security contexts is typically applying iterative logic to high-failure-cost deployments — shipping "minimum viable security" as if security is a feature that can be iterated like a UI element.
Velocity Without Learning Is Just Moving Fast in the Wrong Direction
Perhaps the least examined element of the "done is better than perfect" principle is what makes it more than just a speed endorsement: the requirement for learning. Shipping quickly is neutral until you measure what happened and act on the measurement. Without the learning loop, speed is simply a way of producing wrong outcomes faster.
This learning requirement has three practical components that practitioners consistently underinvest in:
Measurement specificity before shipping:
The question is not "did this work?" It is "did this specific metric change in the direction and magnitude we expected?" Vague measurement ("users seemed to like it") does not generate the information needed to make good decisions about the next iteration. Specific measurement ("7-day retention rate for users who encountered this feature in the first session improved from 34% to 41%") generates actionable information.
Before shipping anything under the "done is better than perfect" framework, the practitioner should be able to answer: what is the specific metric I am trying to move, what direction do I expect it to move, and by roughly what magnitude? If these questions cannot be answered, the shipping is premature — not because the work is not done but because the measurement framework is not done.
Rapid learning loops with actual decisions:
Learning is only valuable if it drives decisions. Many organisations run sophisticated measurement programmes that generate data which is then not acted on — because the insights are inconclusive, because priorities shifted, because the data arrived too late, or because there is no established process for converting insight into iteration.
A practitioner who ships imperfect work, generates measurement data, and then sees the data disappear into a dashboard nobody reviews has not applied the principle — they have applied the first quarter of it. The principle only produces value if the measurement data drives a specific decision: ship the next iteration, pivot, or stop.
Structured retrospectives:
The post-mortem or retrospective is the organisational mechanism for converting individual learning experiences into systemic improvement. When something ships imperfectly and fails, the structured question is: what do we now know that we did not know before, and how should that change what we do next? Without this structure, each failure produces learning for the individuals involved but nothing that improves the system.
The combination of these three components — specific measurement before shipping, learning loops with actual decisions, and structured retrospectives — is what distinguishes the application of "done is better than perfect" in high-performing organisations from the way the phrase is used in organisations that have adopted the language without the practice.
Closing: This Principle Is One Gear in a Larger Machine
"Done is better than perfect" is a genuinely powerful operational principle — when applied in the right context, with the right supporting infrastructure, by a practitioner who can distinguish between the situations where it applies and the situations where it causes damage.
Understanding it deeply raises the adjacent questions that practitioners encounter as they develop more sophisticated frameworks for decision-making and execution. How do you build the measurement infrastructure that makes the learning loop function — specifically, what does a good metrics framework look like in a product organisation, a data science team, or a financial analysis function? How do you develop the context recognition skill that allows you to correctly identify which quadrant you are operating in before you commit to a quality strategy? And how do you communicate quality trade-offs to stakeholders — the investors, clients, managers, and colleagues whose decisions depend on your work — in a way that is honest about the imperfections while credible about the reasoning?
These are exactly the kinds of questions that Meritshot's programmes are built to develop in practitioners. The curriculum in Data Science, Investment Banking, Full Stack Development, and Business Analytics is structured around real-world decisions — not ideals or frameworks in isolation, but the messy, context-dependent, stakeholder-constrained decisions that practitioners actually face. Mentors who have shipped data products and then had to explain the quality trade-offs to a CTO, analysts who have presented first-pass models to investment committees and know exactly where the precision stops, developers who have navigated the difference between moving fast and moving carelessly — these are the practitioners who teach at Meritshot. If this article gave you a more nuanced framework for thinking about when speed serves quality and when it undermines it, Meritshot is where that nuance becomes operational skill.
Meritshot EdTech — training professionals across Data Science, Investment Banking, Full Stack Development, Cyber Security, and Business Analytics.
