Core Primitive
Deliver the simplest version that provides value then iterate if needed.
The report nobody read
A consultant spent six weeks preparing a market entry strategy for a client. The deliverable was extraordinary: a 127-page document with competitive landscape maps, consumer segmentation matrices, pricing sensitivity analyses, regulatory risk assessments, channel strategy recommendations, and a phased implementation timeline with monthly milestones through year three. The executive summary alone was twelve pages. The appendix contained forty-three supplementary charts. The formatting was flawless.
The client's CEO flipped to the recommendation section — page 94 — read the three-paragraph conclusion, and said: "Great. Let's go with Option B. Can you send me a one-pager I can forward to the board?"
The consultant had spent six weeks building a cathedral when the client needed a doorway. The 127 pages were not wrong. They were not low quality. They were excessive — a massive investment of time and cognition producing an output whose value was concentrated in roughly two pages of actionable recommendation. The other 125 pages were insurance against a question nobody asked, armor against a critique nobody made, and evidence of rigor that nobody had time to evaluate.
You have done this. You have over-built a slide deck when three slides would have landed the point. You have over-researched a decision when the first two sources gave you the answer. You have rewritten an email four times when the first draft communicated everything the recipient needed. Every time, you spent hours on work that produced zero additional value — work driven not by the needs of the output's audience but by your own discomfort with shipping something that felt incomplete.
This lesson is about killing that instinct. Not by lowering your standards, but by redefining what "complete" means.
The concept: minimum viable output
The minimum viable output is the simplest version of a deliverable that provides genuine value to its intended recipient. Not the simplest possible version. Not the laziest version. The simplest version that actually works — that answers the question, informs the decision, advances the project, or communicates the insight it was designed to communicate.
The concept borrows directly from Eric Ries's minimum viable product, introduced in "The Lean Startup" (2011). Ries defined the MVP as "that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort." The MVP is not a half-baked product. It is a strategically scoped product designed to test whether the core value proposition works before investing in features that may be unnecessary.
Apply this lens to every output you produce. Before you build, ask: what is the core value this output needs to deliver? A competitive analysis needs to inform a decision. A project update needs to communicate status and surface blockers. A blog post needs to convey one actionable idea. A recommendation memo needs to present options and argue for one. Everything beyond that core value is optional — potentially useful, but optional.
The MVO is not about cutting corners. It is about cutting scope to the value boundary and stopping there until you have evidence that more is needed.
Why we over-build: the psychology of excess
If the MVO is so obviously efficient, why does virtually every knowledge worker default to over-building? The answer is psychological, not rational.
Perfectionism as self-protection. Steven Pressfield, in "The War of Art," identifies perfectionism as a form of resistance — the internal force that opposes creative output. Perfectionism disguises itself as high standards, but its actual function is delay. As long as you are polishing, you are not shipping. As long as you are not shipping, you are not exposing yourself to judgment. The 127-page report is not evidence of rigor. It is evidence of someone who is afraid that a 2-page report might invite the question: "Is that all?" Perfectionism answers that imaginary question preemptively by making the output so exhaustive that no one could possibly accuse the author of insufficient effort.
Effort justification. Psychologist Leon Festinger's cognitive dissonance research shows that people value outcomes more when they have invested more effort in producing them. This creates a perverse incentive: the more time you spend on an output, the more valuable it feels to you — regardless of whether the additional time produced additional value for the recipient. You spend three extra hours on a presentation and feel that it is three hours better. Your audience, who never saw the version from three hours ago, has no basis for comparison. The extra hours served your psychology, not their needs.
Scope creep as avoidance. Adding one more section, one more analysis, one more round of revision is a socially acceptable way to avoid the discomfort of declaring something finished. "Finished" is a commitment. It means: this is what I produced, and I am willing to be evaluated on it. Scope creep postpones that commitment indefinitely. There is always one more thing to add, one more edge case to address, one more stakeholder to consider. The output is never done because being done is uncomfortable.
Misaligned quality standards. Output quality standards established that different output types require different quality standards. But most people apply their highest quality standard to every output, regardless of context. The email to a colleague gets the same scrutiny as the board presentation. The internal draft gets the same polish as the client deliverable. This is not diligence. It is failure to calibrate effort to context — and it consumes enormous time on outputs where the additional quality produces zero additional value.
The 80/20 of output value
Vilfredo Pareto's principle — that roughly 80% of effects come from 20% of causes — applies to output with uncomfortable precision.
For most deliverables, a small fraction of the content delivers the vast majority of the value. The executive summary is more read than the full report. The recommendation matters more than the analysis that supports it. The three key data points in a presentation carry more weight than the twelve supplementary charts. The subject line of an email determines whether the body gets read at all.
This is not an argument against thoroughness. It is an observation about how value distributes across the components of an output. If 80% of the value lives in 20% of the content, then producing the high-value 20% first — and shipping it — captures most of the impact in a fraction of the time. The remaining 80% of content, which delivers the remaining 20% of value, can be added later if someone asks for it.
Reid Hoffman, the founder of LinkedIn, captured this with a line that should be tattooed on the forehead of every perfectionist: "If you are not embarrassed by the first version of your product, you launched too late." Hoffman was not advocating for low quality. He was advocating for speed to value. The first version does not need to be complete. It needs to be useful. Usefulness is the threshold. Everything beyond usefulness is iteration.
Satisficing: the decision science of "good enough"
Herbert Simon, the Nobel laureate in economics, introduced the concept of satisficing in the 1950s — a decision-making strategy that seeks a solution meeting an acceptability threshold rather than an optimal one. Simon contrasted satisficing with maximizing: the attempt to find the best possible option by exhaustively evaluating all alternatives. Maximizers spend more time, experience more decision fatigue, and — paradoxically — often end up less satisfied with their choices than satisficers, because the awareness of unchosen alternatives creates persistent regret.
Apply satisficing to output production. The maximizer rewrites the memo until it is the best possible memo. The satisficer writes a memo that clearly communicates the recommendation, supports it with sufficient evidence, and ships it. The maximizer's memo might be 5% better. The satisficer's memo shipped three days earlier, informed the decision while it was still timely, and freed three days of cognitive bandwidth for the next output.
Barry Schwartz extended Simon's work in "The Paradox of Choice" (2004), documenting how maximizing behavior leads to paralysis, anxiety, and reduced well-being. The findings apply directly to output production. The knowledge worker who insists on producing the optimal version of every deliverable is not producing optimal work. They are producing delayed work, stressed work, and fewer total outputs — because the time spent perfecting one output is time stolen from producing the next one.
The MVO is satisficing applied to production. Define the acceptability threshold — the minimum version that provides genuine value — and produce to that threshold. Then stop. Ship. Move on. If the output needs to be better, someone will tell you. If no one asks for more, you just saved yourself hours or days of work that would have produced no additional value.
YAGNI: you ain't gonna need it
Kent Beck's Extreme Programming community popularized the YAGNI principle — You Ain't Gonna Need It. In software development, YAGNI means: do not build features until you have evidence they are needed. Do not write code for hypothetical future requirements. Do not add complexity to handle edge cases that may never arise. Build what is needed now. Ship it. Add more when reality demands it.
YAGNI applies to every output type. Do not add the risk analysis section to the proposal until someone asks about risk. Do not build the ten-year financial projection when the decision requires a three-year view. Do not include the methodology section in the report when the audience trusts your methodology and only needs the findings. Every component you add "just in case" is a component that cost time to produce, adds length the reader must navigate, and delivers value only in the hypothetical scenario where someone happens to need exactly that information.
The YAGNI principle is not about laziness. It is about epistemic humility — acknowledging that you do not know in advance which parts of your output will be valuable. Instead of guessing and building everything, ship the core and let real feedback tell you what to add. The feedback loop is faster, more accurate, and less wasteful than your prediction.
How to identify the MVO for any output
Here is a practical framework for defining the minimum viable output for any deliverable.
Step 1: Name the recipient. Who is this output for? A specific person, a team, an audience? If you cannot name the recipient, you may not need to produce the output at all.
Step 2: Name the action. What should the recipient do after consuming this output? Make a decision, take an action, understand a concept, approve a request? The action defines the purpose. An output without a clear downstream action is an output without a clear purpose.
Step 3: Name the minimum content. What is the least amount of information the recipient needs to take that action? Not the most. The least. For a decision memo, it might be: the options, the recommendation, and the top two supporting reasons. For a project update, it might be: current status, blockers, and next steps. For a presentation, it might be: the problem, the proposed solution, and the ask.
Step 4: Define the viability threshold. Below what level of quality or completeness does this output fail to serve its purpose? A recommendation without supporting reasoning is below the threshold — the recipient cannot evaluate it. A recommendation with two strong reasons instead of five is above the threshold — the recipient can act. The viability threshold is the line between "this is useful" and "this wastes the recipient's time."
Step 5: Produce to the threshold and stop. Build the output that meets the viability threshold. Do not add anything beyond it. Ship. If the recipient needs more, they will ask — and then you will know exactly what to add, because the request will be based on their actual needs rather than your speculative ones.
This five-step process takes two minutes. It replaces the default approach — which is to start building without defining scope and let the output grow until you run out of time or energy — with a deliberate scoping exercise that focuses effort on value.
The MVO across output types
Different outputs have different viability thresholds. Here are examples.
Email. The MVO for most emails is shockingly short. Subject line that states the purpose. One paragraph of context. The request or information. That is it. The twelve-paragraph email with background, caveats, and multiple embedded questions is not thorough — it is a document masquerading as a message, and it will be skimmed at best.
Memo or report. The MVO for a decision memo is: the recommendation, the top two or three reasons, and the key risk. The MVO for a status report is: what is done, what is blocked, what is next. Everything else — the detailed methodology, the comprehensive data tables, the historical context — is available if someone asks. It does not need to be in the first version.
Presentation. The MVO for a presentation is the fewest slides that make the argument. Guy Kawasaki's 10/20/30 rule — ten slides, twenty minutes, thirty-point font — is itself an MVO prescription. Most presentations would be improved by cutting half their slides, because the deleted slides are diluting the message rather than strengthening it.
Code. Kent Beck's "make it work" phase is the MVO for software: code that produces the correct output, however inelegantly. Ship the working version. Refactor later. The refactored version is better, but the working version is valuable now, and "now" matters more than "better" when the alternative is "eventually, maybe, if I ever finish."
Creative work. The MVO for a blog post is a clear articulation of one idea with one supporting example. The MVO for a newsletter is a single insight worth the reader's time. The MVO for a course module is a concept explained clearly enough that the learner can apply it. Everything beyond that core is enhancement — welcome but not required for the output to fulfill its purpose.
The iteration principle: ship, then improve
The MVO is not a permanent state. It is a starting point.
The lean methodology that Ries codified works in cycles: build, measure, learn. You ship the minimum viable version. You observe how it performs — does it answer the question, inform the decision, land with the audience? You learn what is missing, what is confusing, what needs expansion. Then you iterate: a second version that addresses the real gaps revealed by real feedback, not the imaginary gaps you would have tried to preemptively fill.
This is fundamentally different from the traditional approach of building the comprehensive version first. The traditional approach relies on prediction — your guess about what the audience needs. The MVO approach relies on feedback — actual evidence about what the audience needs. Feedback is more accurate than prediction. It is also cheaper, because you only build the additional components that someone actually requested, rather than all the components you imagined might be needed.
Facebook's early motto — "Move fast and break things" — took this too far. Mark Zuckerberg eventually revised it to "Move fast with stable infrastructure," acknowledging that speed without a foundation of reliability produces chaos. The MVO occupies the sweet spot: fast enough to capture the value of timeliness, complete enough to be genuinely useful, and scoped tightly enough that iteration is easy when the feedback arrives.
Common objections and their rebuttals
"But my audience expects comprehensive work." Does it? Or do you expect your audience to expect comprehensive work? Test the assumption. Ship the MVO. See if anyone asks for more. You will be surprised how often the concise version is not just acceptable but preferred. Decision-makers are busy. They want the answer, not the journey to the answer.
"But I will look unprepared." Preparation and comprehensiveness are not the same thing. A surgeon who makes a single precise incision looks more prepared than one who opens the entire abdomen. An analyst who delivers a crisp two-page recommendation looks more prepared than one who buries the recommendation on page 94 of a 127-page document. Precision signals mastery. Volume signals uncertainty about what matters.
"But what if they ask a question I cannot answer?" Then you answer it. You say: "Great question. I focused the initial analysis on the three factors most relevant to the decision. I can dig into that dimension and have it to you by Thursday." This is not a failure. This is responsive, efficient work. And it ensures that the additional effort goes exactly where it is needed, rather than being spread across every hypothetical question that might have been asked but wasn't.
"But my standards are higher than that." Your standards should be calibrated to the output's purpose, not to your ego. Output quality standards established that quality standards vary by output type and context. Applying your highest standards to every output is not a sign of excellence — it is a sign of an uncalibrated quality system. The MVO respects high standards by applying them where they matter: at the viability threshold. Below the threshold, the output is not good enough. At or above the threshold, the output is good enough. Spending effort beyond that point is not raising the standard. It is misallocating resources.
The Third Brain: AI as MVO accelerator
AI transforms the MVO from a discipline into a default.
The traditional bottleneck with shipping minimum viable outputs was production time. Even the stripped-down version required you to sit down, organize your thoughts, and produce the artifact. When production is slow, the temptation to make each production session "count" by building something comprehensive is strong — because you do not want to go through the effort of producing again if someone asks for more.
AI collapses production time so dramatically that this calculus inverts. When producing an output takes minutes instead of hours, the cost of iterating is trivial. You ship the MVO knowing that if someone asks for more, you can produce the expanded version in a fraction of the time the original would have taken without AI.
Here is the specific workflow.
Define the MVO spec. Before touching AI, spend two minutes on the five-step framework above. Name the recipient, name the action, name the minimum content. Write this as a one-sentence brief.
Generate the MVO draft. Give your AI partner the brief, your key points, and any supporting material. Ask it to produce a draft that addresses exactly the scope you defined — no more. The AI will produce a first-pass MVO in minutes. You review, adjust the judgment calls, add your domain-specific nuance, and ship.
Iterate on demand. When feedback arrives — "Can you add a risk section?" or "What about the international market?" — you feed the feedback to AI along with the original output and produce the expanded version in minutes. The iteration is cheap, fast, and targeted to exactly what the recipient actually needs.
Use AI to scope-check. If you find yourself adding sections to an output, pause and ask your AI partner: "Given that this output is intended to [action] for [recipient], is [this section] necessary for the output to fulfill its purpose, or is it additional?" The AI acts as a scope guardian — a dispassionate voice that reminds you of the MVO boundary when your perfectionism tries to push past it.
The human role remains what it always was: judgment about what matters, domain expertise about what is true, and quality sense about what is good enough. The AI role is production speed — turning your judgment into an artifact so fast that the argument for over-building loses its economic rationale. When producing the next version takes five minutes, there is no reason to pre-build everything into the first version.
The bridge to output frequency
The MVO has a direct structural relationship with the next lesson's subject: output frequency.
Here is the connection. If every output must be comprehensive, polished, and perfect before it ships, then you cannot ship very often. The production cost per output is too high. You produce one excellent deliverable per week — or per month — and the gaps between outputs are dead zones where no value reaches the world.
But if your default is the MVO — the simplest version that provides genuine value — then production cost per output drops dramatically. You can ship daily. You can ship multiple times per day. Each output is smaller, faster, and more focused. The total value produced over a week is higher, because five MVOs that each capture 80% of the possible value deliver 400% of the value of one comprehensive output that captures 100%.
This is the arithmetic that makes output frequency possible. And output frequency, as Output frequency matters will demonstrate, is the single most powerful lever for compounding the value of your work over time. But frequency is impossible without scope discipline. And scope discipline is the MVO.
The minimum viable output is not a compromise. It is a strategy — the strategy that makes consistent, compounding output production sustainable over weeks, months, and years.
Sources:
- Ries, E. (2011). The Lean Startup: How Today's Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses. Crown Business.
- Simon, H. A. (1956). "Rational choice and the structure of the environment." Psychological Review, 63(2), 129-138.
- Schwartz, B. (2004). The Paradox of Choice: Why More Is Less. Ecco.
- Beck, K. (2000). Extreme Programming Explained: Embrace Change. Addison-Wesley.
- Pressfield, S. (2002). The War of Art: Break Through the Blocks and Win Your Inner Creative Battles. Black Irish Entertainment.
- Festinger, L. (1957). A Theory of Cognitive Dissonance. Stanford University Press.
- Kawasaki, G. (2004). The Art of the Start: The Time-Tested, Battle-Hardened Guide for Anyone Starting Anything. Portfolio.
- Pareto, V. (1896). Cours d'economie politique. University of Lausanne.
Frequently Asked Questions