The Two-Speed Founder: When to Ship Fast and When to Think First

Estimated reading time: 22 minutes

The Promise That Broke

For the last two years, the dominant advice for founders who overthink was simple: use AI tools and ship faster. Describe what you want to a model, accept the output, iterate through vibes. The friction that used to force you to pause, to question whether you should actually build this, was gone. A prototype that took three weeks now takes two days. The cognitive load of being a technical founder dropped by an order of magnitude.

Then came January 2026.

Moltbook, a note-taking startup that had vibe-coded its way to a working product in under a week, launched publicly. Within 72 hours, security researchers found 1.5 million API authentication tokens exposed in their codebase, along with 35,000 email addresses and fragments of user data. The founder had accepted what the AI generated for the auth layer and moved on. He could not explain how the authentication worked because he had never really understood it.

Moltbook is not an isolated case. A scan of 5,600 publicly deployed vibe-coded applications found 2,000 highly critical vulnerabilities and 400 exposed secrets including API keys and access tokens. Research from OX Security found that 62% of AI-generated code ships with vulnerabilities. Privilege escalation paths in vibe-coded apps rose 322% compared to human-authored code.

The promise was: AI will fix your overthinking problem. Build fast, learn fast, stop agonizing.

What actually happened: AI traded one failure mode for another. Founders who spent too long deliberating before AI became founders who build the wrong thing at high velocity after AI.

Both failure modes kill companies. The founders who survive both are the ones who figure out that the answer is not one speed. It is two.

This is the framework I use, built from watching both kinds of failure up close. It is not about slowing down across the board. It is about knowing exactly which decisions deserve speed and which decisions deserve depth, before you touch a keyboard or open a model.

The Two Failure Modes Every Founder Faces

Mode 1: The Overthinking Trap

This one has been well-documented. You know what it looks like because you have probably lived it.

Research from 2026 found that 62% of entrepreneurs who score high on perfectionism report hitting analysis paralysis on key decisions. Founders lose an average of 96 minutes every day to tasks they themselves identify as unproductive, which works out to more than three full work weeks per year spent on nothing that moves the company forward.

Harvard neuroscientists confirmed in 2024 what most founders already felt: overthinking activates the brain’s default mode network, the same network associated with rumination and self-doubt, and actively suppresses the prefrontal activity needed for creative problem-solving. You are not thinking better by thinking longer. Past a certain threshold, you are actively thinking worse.

The data from RescueTime puts a concrete number on this: people who struggle with overthinking spend 25% more time on routine tasks than their peers who default to action. That is a quarter of your working hours going to a tax you do not have to pay.

Mode 1 founders wait for the perfect pricing model before launching. They spend two months designing an onboarding flow for users they do not yet have. They write a 40-page strategy document before talking to a single customer. They research competitors so thoroughly that a competitor launches the thing they were researching first.

The cost is opportunity. Time. The compounding learning that only comes from real-world contact.

Mode 2: The Over-Shipping Trap

This one is newer, and the advice ecosystem has not caught up to it yet.

42% of startups fail because they build something nobody actually needs. That number has held roughly steady for a decade. What has changed is the mechanism. Pre-AI, a founder who built the wrong thing at least spent three months doing it, which created a natural forcing function to question whether the thing was worth building at all. Post-AI, you can build the wrong thing in a weekend and ship it before you have talked to a single user.

The common pattern in Mode 2 looks like this: AI makes building so fast that validation gets skipped. The founder ships a feature, gets no traction, and instead of talking to users, ships another feature because building feels like progress while user conversations feel like slowing down. The flywheel spins faster and faster, producing more code and less learning.

The BCG study that identified “AI brain fry” found that workers who continuously oversee AI tools experience 14% more mental effort per task, 12% greater mental fatigue, and 19% greater information overload compared to those who work without AI. The irony is that the founders most aggressively using AI to move fast are often the most cognitively depleted, and therefore the least equipped to make the good decisions that would actually accelerate them.

Mode 2 founders ship ten features before validating that the core loop works. They vibe-code an architecture that will require a full rewrite in six months. They launch to 1,000 users before fixing a retention problem that makes all 1,000 of those users churn in week two. They move fast in exactly the wrong direction and discover the mistake only when they have run through their runway.

Why Most Advice Makes This Worse

The productivity advice available to founders is almost entirely focused on Mode 1. Ship faster. Bias toward action. Done is better than perfect. Move fast and break things.

This advice was correct for a specific context: founders who were using slowness as a defense mechanism against the fear of judgment. That context still exists. But it is not the whole picture anymore.

When every piece of advice pushes you toward speed, and AI makes speed nearly free, the missing check is deliberation. The missing discipline is knowing when NOT to ship fast.

The two-speed founder is not someone who found a middle ground between fast and slow. A middle ground is just being mediocre at both. The two-speed founder has a system that determines, before any decision, which clock to run.

The Velocity Decision Matrix

Every decision you face as a founder has two properties that determine the right speed.

Property 1: Reversibility. If you get this decision wrong, how hard is it to undo? Can you fix it in 72 hours, a week, a month? Or is the cost of being wrong structural, the kind of mistake that corrupts every downstream decision for the next six months?

Property 2: Learning velocity. How fast does acting on this decision give you real signal? Does shipping it in two days produce meaningful user behavior data in four days? Or does this decision belong to a category where the feedback loop is inherently long, where you will not know if you were right for six to twelve months?

These two properties create a 2×2 matrix with four distinct decision zones, each with a right cadence.

The matrix is not complicated. What makes it powerful is that most founders operate as if they are in one quadrant for everything. Overthinkers treat all decisions like the top-left: Think Hard. Over-shippers treat all decisions like the bottom-right: Ship Today. Neither is right. The two-speed founder classifies first, then moves at the speed the decision actually warrants.

The Two Questions to Classify Any Decision

You only need two questions to place a decision on this matrix.

Question 1 (Reversibility): Can I fix this in 72 hours if I am wrong? If yes, it is reversible. If it takes weeks to undo, or if being wrong corrupts other decisions downstream, it is not reversible.

Question 2 (Learning velocity): Will shipping this in the next 48 hours give me real signal within a week? If yes, you have a fast feedback loop. If you will not know whether this was right for a month or more, the learning loop is slow.

Two questions. About 90 seconds. That is the classification step.

Speed 1: Decisions That Should Ship Today

The bottom-right quadrant is where most founders spend too little time. These are decisions that are both reversible and produce fast signal. In the AI era, this category has expanded dramatically, because AI tools have made it nearly free to build, test, and iterate on things that used to require weeks of engineering time.

The defining characteristic of a Ship Today decision is that you learn more from shipping it than from thinking about it. Every day you spend deliberating on a Ship Today decision is a day of learning you are deferring for no reason.

What Actually Lives Here

Pricing experiments belong here. This surprises many founders, who treat pricing as a heavy strategic decision requiring weeks of analysis. In reality, most pricing decisions are reversible (you can change a price), and they produce extremely fast signal (users either convert or they do not). Research from SaaS companies consistently shows that a pricing test run for two weeks produces more actionable data than a two-month internal pricing analysis.

Landing page copy belongs here. A headline change, a new value proposition framing, a different hero image. All reversible in minutes. All producing real click-through and conversion data within 48 hours of traffic.

Feature experiments belong here. Not the core architecture of a feature, but whether a feature should exist at all, and whether users engage with it. Shipping a minimal version of a feature and measuring engagement gives you data that no amount of internal debate can produce.

Channel tests belong here. Whether a given distribution channel works for your product is not a question you can answer by analyzing it. You run the test, measure the signal, and know within a week whether to invest more or move on.

Onboarding flow tweaks belong here. Changing a step order, rewording an explanation, removing a friction point. All reversible. All measurable within days.

The 72-Hour Test

For any decision you are unsure about, ask one question: if I get this wrong, can I fix it within 72 hours with less than two hours of work?

If yes, stop deliberating. The fastest version of this decision is probably right, because the cost of a wrong answer is low and the cost of delayed learning is real.

Jeff Bezos framed this as “two-way doors”: decisions where you can walk back through if you do not like what you see on the other side. His insight was that most organizations treat two-way doors like one-way doors, applying heavyweight deliberation to choices that are actually cheap to reverse. The result is an organization that moves too slowly on exactly the decisions where speed creates the most value.

How AI Multiplies This Quadrant

This is the part of the “move fast” advice that is genuinely correct. AI tools have moved a large number of decisions from the “Ship This Week” quadrant into the “Ship Today” quadrant, by reducing the cost of building to nearly zero.

A landing page that used to take a designer and developer a week now takes a founder three hours. That moves the decision to test a new value proposition from “Ship This Week” to “Ship Today.” A feature prototype that used to take two weeks of engineering time now takes a day of AI-assisted building. That moves the decision to test whether the feature concept resonates from “Ship This Week” to “Ship Today.”

The question is whether the decision is fundamentally reversible and signal-producing. If both answers are yes, AI has almost certainly moved it to the fastest possible cadence.

Speed 2: Decisions That Need Real Deliberation

The top half of the matrix is where founders operating in Mode 2 cause the most damage. These are decisions where being wrong is expensive, and where the feedback loop is slow enough that you will not discover the mistake until it has already cascaded into dozens of other wrong decisions.

The defining characteristic of a Think Hard or Think Then Ship decision is that acting on it at high speed means acting without adequate signal, and the cost of being wrong is not recoverable in 72 hours.

Architecture Is a One-Way Door

This is the one that breaks vibe-coded startups.

Core architecture decisions, how data is structured, how authentication is implemented, how services are separated, how state is managed, are nearly irreversible in the short term. Rewriting an authentication system takes weeks. Migrating a data schema at scale takes months. These are not the decisions to accept an AI output on and move on.

The Moltbook failure was not a failure of AI tools. The AI generated exactly what it was asked to generate. The failure was the founder treating an architecture decision like a Ship Today decision. He applied the speed of a two-way-door process to a one-way-door problem.

Research from the Cloud Security Alliance found that privilege escalation paths in vibe-coded applications rose 322% compared to human-authored code, and architectural design flaws rose 153%. These are not bugs in features you can patch overnight. They are structural problems that require structural rethinking.

Co-founder and Key Hire Decisions

Reversibility is nearly zero. If you misread a co-founder’s risk tolerance, work style, or alignment on what success looks like, you are months into the mistake before you know it. There is no 72-hour fix. The feedback loop runs on quarters, not days.

Colin Powell’s 40-70 rule applies here: gather enough information to be more than 40% confident but do not wait for 100% certainty. The right threshold for a key hire decision is closer to 70-80% confident after thorough deliberation, not the 40% confidence that is fine for a Ship Today experiment.

Market and Positioning Decisions

Choosing which problem to solve, which customer to serve, which category to own. These sit in the Think Hard quadrant because they are both hard to reverse and slow to validate. You will not know if you picked the right market for six to twelve months. That makes rapid experimentation on the core bet an expensive way to learn.

This does not mean paralysis. It means investing in research: direct customer conversations, spending time inside the problem space, looking at who has tried this before and what happened. The work before a Think Hard decision is different from the work before a Ship Today decision. It is research and deliberation, not build and measure.

Brand and Positioning Once You Have Users

After you have a user base, brand and positioning decisions become more costly to reverse, not because they cannot technically be changed, but because changing them confuses existing users who have already formed a mental model of what you are. That switching cost makes them Think Then Ship decisions: act within a week or two, but do not just vet them against internal opinion, get real user data before committing.

The Misclassification Problem

The reason the matrix matters is that most founders misclassify decisions, and they tend to misclassify in consistent, predictable patterns.

Overthinkers systematically move decisions up the matrix. They treat pricing (Ship Today or Think Then Ship) like a Think Hard problem. They spend three weeks deciding on a project management tool when the right answer is to pick one in an afternoon and switch if it does not work. They apply the deliberation appropriate for co-founder decisions to feature decisions that should be shipped and tested in a day.

Over-shippers systematically move decisions down the matrix. They treat architecture (Think Then Ship or Think Hard) like a Ship Today problem. They vibe-code a core security layer because building feels like progress. They hire a key VP of Sales after a single conversation because their calendar is full and the hire feels urgent.

The Five Most Commonly Misclassified Decisions

1. Pricing. Almost always treated as Think Hard. Almost always better treated as Ship Today. Your price is a hypothesis about value. Test it like one.

2. Architecture. Almost always treated as Ship Today in the vibe-coding era. Almost always better treated as Think Then Ship. One afternoon of design saves three months of refactoring.

3. The first content channel. Treated as Think Hard by overthinkers who spend months on a content strategy. Should be Think Then Ship: pick one channel with deliberate reasoning, ship consistently for 90 days, then decide.

4. Early key hires. Treated as Ship Today by founders who want to fill the seat fast. Should be Think Hard. A wrong early hire costs you six to twelve months and sometimes the company.

5. Feature scope. Treated as Think Hard by perfectionists. Should be Ship Today on the smallest testable version, then expand only if users want the expansion. The “minimal” in minimum viable product means exactly this.

The Blast Radius Test

When you are unsure whether a decision is truly reversible, run the Blast Radius test: if this decision is wrong, how many other decisions does it corrupt?

A wrong pricing page is a blast radius of one: you change the page. A wrong architecture choice has a blast radius of ten or twenty: your caching strategy, your security model, your scaling plan, your ability to add features, your future hire requirements. All of them are downstream of that one decision.

High blast radius decisions belong in the top half of the matrix, regardless of how simple they feel to implement.

The Overthinking Audit

If you have been in Mode 1, the signs are visible in your decision log.

Signs You Are Stuck in Overthinking

You have been sitting on the same decision for longer than the decision’s blast radius warrants. A low-blast-radius, fast-signal decision should take less than a day. If you have been thinking about whether to change your homepage headline for two weeks, you are in Mode 1.

You are researching a decision instead of running an experiment. For Ship Today decisions, research is often a way to defer action. The decision will teach you more in 48 hours of live user contact than in two weeks of analysis.

You are adding options instead of narrowing them. The more options you have, the harder it is to decide. The Paradox of Choice research, Sheena Iyengar’s 2000 jam study, showed that 24 options produced dramatically fewer purchases than 6. Founders in Mode 1 keep finding new options to consider instead of committing to one and learning from it.

You feel productive without anything shipping. Reading competitor analysis, attending webinars about your industry, writing strategy documents that are not tied to a specific decision. These activities feel like work. They are not learning.

The Cost of Delayed Learning

Research on startup learning cycles found that weekly iteration goals generate 12 times more learning than quarterly evaluation cycles. That ratio is not intuitive until you think about compounding: a team that runs one experiment per week completes 52 experiments in a year. A team that runs one experiment per month completes 12. The first team has not just learned more in absolute terms. They have learned from earlier experiments in time to apply that learning to later experiments.

The overthinking tax is not just the time you spend deliberating. It is the compounding learning you forfeit while you deliberate.

The Overthinking Diagnostic

Take any decision you have been sitting on for more than three days. Answer both classification questions:

Can I fix this in 72 hours if I am wrong? Will shipping this in the next 48 hours give me real signal within a week?

If both answers are yes, you have been in Mode 1 on a Ship Today decision. Pick the best available option right now. Stop researching. Stop optimizing. Ship it and watch what happens.

The Over-Shipping Audit

If you have been in Mode 2, the signs show up in your codebase, your team dynamics, and your user retention data.

Signs You Are Stuck in Over-Shipping

You have shipped ten features and none of them significantly changed retention or engagement. Each time a feature underperforms, you build the next one instead of talking to the users who did not engage with the last one. Building feels like progress. It is not.

You cannot fully explain how something in your product works, because an AI generated it and you moved on. This is the Moltbook pattern. If you cannot explain your authentication system to a competent engineer in five minutes, you have a one-way-door problem that you do not know the full shape of yet.

Your onboarding conversion rate has been stagnant for six weeks despite shipping improvements every week. This is a sign that you are in the Ship Today quadrant on a decision that belongs in Think Then Ship: the core onboarding concept needs deliberate rethinking, not incremental feature shipping.

You hired someone for a key role in the first available conversation because the open role felt urgent. Urgency is not the same as reversibility. Most key hire decisions feel urgent and are not. The cost of a wrong early hire runs from six months to “it killed the company.”

The Cascade Problem

The reason over-shipping is dangerous at the level of one-way-door decisions is that wrong decisions in the top quadrants cascade. A wrong architecture decision does not just mean you need to rewrite the architecture. It means your security assumptions are wrong. Your scaling plan is built on the wrong foundation. Your future engineering hires are being asked to learn a system that will not exist in six months. The blast radius compounds over time.

I have watched two well-funded startups spend eight months building on an architecture chosen in a weekend of vibe coding. By the time they discovered the problem, the cost of fixing it was not “rewrite the auth layer.” It was “rewrite most of the product, retrain the team, and explain to investors why the engineering foundation we built is being thrown away.”

The Over-Shipping Diagnostic

Take anything you have shipped in the last 30 days that has not produced the results you expected. Answer both classification questions on the original decision to build it.

If it was actually a Think Hard or Think Then Ship decision that you treated as Ship Today, the diagnostic is clear: you moved too fast on the wrong clock. The fix for next time is not to slow down across the board. It is to classify before you build.

Building a Two-Speed Operating Rhythm

The matrix is a classification tool. The operating rhythm is how you actually run both speeds as a daily and weekly practice.

Daily Default: Speed 1

Most of your day as a founder should default to Speed 1. Ship Today decisions are the ones that produce learning, and learning is the only durable input to compounding. If you have not shipped anything testable today, you probably need to ask whether you are deliberating on something that should already be in front of users.

The practical rule: every morning, list your open decisions. For each one, run the two classification questions. Any decision that scores as Ship Today goes on the execution list for today, not the thinking list.

Weekly Checkpoint: Speed 2 Review

Once a week, take 30 minutes to audit any decision you have been deliberating on for more than 7 days.

First question: did it get misclassified upward? Did you put a Ship Today decision into the Think Hard pile because it felt scary rather than because it was actually irreversible? If yes, make the call now.

Second question: are you now deliberating long enough on genuine Think Hard decisions? The failure mode here runs both ways. Some founders run through Think Hard decisions in a day because they are impatient, then discover six months later that they were one-way doors they walked through without looking.

The 40-70 Rule for Threshold

Colin Powell’s 40-70 rule offers a useful threshold for when to stop deliberating and act. For any decision, gather enough information to be at least 40% confident you have the right answer. Do not wait until you are 100% confident. The 40% floor prevents reckless action. The 100% ceiling prevents paralysis.

For Think Hard decisions, push toward the 70% end. For Ship Today decisions, 40-50% is often enough, because the cost of being wrong is low and you will learn from the mistake.

Monthly Debt Check

At the end of each month, audit the decisions you made at Speed 1 to check whether any of them accumulated into a pattern that now looks like a Speed 2 problem.

Ten small feature experiments can individually be Ship Today decisions. But if all ten are building in the same direction and none of them have moved your core retention metric, the accumulated pattern might be telling you something about a positioning decision that belongs in Think Then Ship or Think Hard.

This is the trap that most productivity frameworks miss. Individual decision speed is right. But the portfolio of Speed 1 decisions still needs a Speed 2 frame around it periodically.

The Contrarian Take

“Move fast and break things” is not wrong. It became a religion, and religions do not have conditions.

The advice made sense in a specific historical context: organizations that were too slow because they were applying heavyweight process to every decision, including the ones that should have been made in an afternoon. The corrective was to push toward speed, to bias toward action, to stop treating reversible decisions as if their outcomes were permanent.

The problem is that this corrective became a founding principle instead of a heuristic. It got applied not just to feature decisions but to architecture decisions, to hiring decisions, to market choices. The nuance, that “break things” was only ever appropriate for decisions you could unbreak, got lost in the gospel version.

AI made this worse by making speed free. When building is cheap, the cost of the speed bias fell to near zero for reversible decisions. That is genuinely good. But it also means the founders who absorbed the “move fast” lesson most completely are now moving fast on everything, including the one-way doors.

The real skill is not “ship faster.” Any founder can ship faster after a week with AI tools. The real skill is classification: looking at a decision and knowing within 90 seconds which clock it runs on.

The same founder who overthinks a landing page headline is often under-thinking their data model. Not because they are confused about the importance of data models in the abstract. But because they are applying the “move fast” heuristic consistently across all decisions, and consistency is exactly wrong here. You need inconsistency: aggressive speed on reversible decisions, deliberate slowness on irreversible ones.

I have run two companies. In the first one, I was primarily a Mode 1 founder. I overthought pricing for two months while a competitor launched on a price I would have arrived at in a week if I had just run the test. In the second company, I corrected too far. I used AI to ship everything fast, trusted the output, and built an architecture in a weekend that required a six-week rewrite four months later, right when we were trying to scale. Both failures cost real time and real money.

The two-speed system is what I built to stop failing in the same direction twice.

What to Do Monday Morning

The framework only helps if you use it. Here is what to actually do this week.

Monday morning: Run the Decision Audit. Write down every decision you have been deliberating on for more than three days. For each one, answer the two classification questions. Find the ones you have been treating as Think Hard that are actually Ship Today decisions. Make those decisions before noon on Monday. Do not put them back on the list.

Tuesday: Pick one Ship Today experiment you have been avoiding. There is a change to your landing page, your onboarding, your pricing, or your activation flow that you have thought about but not shipped because it felt risky. Run both questions. If it is reversible and produces fast signal, ship the minimal version of it today. Measure for 72 hours.

Wednesday: Run the Blast Radius check on your last major technical decision. Write down the core decision (the architecture choice, the data model, the service boundary you drew). List every downstream decision that depends on it being right. If the blast radius is more than five decisions, and you made that decision in less than a day, go read the thing you built in detail. Not to panic. To know what you actually own.

Thursday: Audit your current deliberations for genuine Think Hard decisions. Is there anything in your open decision queue where you are actually moving too fast? Key hire, market choice, pricing model structure? Flag those explicitly. Give them 3-7 more days of deliberate research, which means user conversations and data gathering, not just more internal analysis.

Friday: Build the habit for next week. Set a recurring 15-minute calendar block for Monday morning labeled “Decision Audit.” Keep the two questions written somewhere visible. The goal is not to run the full framework every time you make a decision. It is to internalize the two questions until classification takes 90 seconds instead of 15 minutes.

One more thing: the founders who struggle most with this framework are the ones who want to know which quadrant every decision lives in before they start classifying. That is itself a Mode 1 pattern. The classification is not perfect. Some decisions will turn out to be more or less reversible than you estimated. That is fine. The value of the framework is not that it is right 100% of the time. It is that it breaks the habit of applying one speed to everything.

Frequently Asked Questions

What is the difference between analysis paralysis and appropriate deliberation?

The difference is reversibility. Analysis paralysis happens when you apply heavyweight deliberation to reversible decisions: decisions where being wrong costs less than the time you are spending on the decision itself. Appropriate deliberation is the work you do before one-way-door decisions: gathering real data, running user conversations, mapping the blast radius, and building confidence from 40% toward 70% before committing. If you have been sitting on a decision for more than two days, ask whether it is actually reversible. If yes, you are in paralysis territory. If no, you may be in appropriate deliberation.

Does the vibe coding critique mean founders should not use AI to build?

No. The critique is specific: do not use AI to move fast on irreversible decisions. AI is genuinely excellent for accelerating Ship Today and Ship This Week decisions, where the cost of building wrong is low and learning from a shipped version is fast. The failure mode is when founders apply the same speed to architecture, data models, and security layers, which are irreversible and high blast-radius decisions that need deliberation before any code is written.

How do I know if a decision’s blast radius is actually high?

List every decision you will have to make in the next 60 days that depends on this one being right. If you can list more than five, the blast radius is high. The most reliable indicators of high blast radius are: the decision lives in the technical infrastructure, the decision determines who you hire next, or the decision shapes the pricing and positioning before you have significant user data. These categories consistently produce downstream dependencies.

What if I genuinely cannot tell whether a decision is reversible?

Default to Think Then Ship. The cost of treating a reversible decision like a slightly irreversible one is that you spend a few extra days deliberating. The cost of treating an irreversible decision like a reversible one is a blast radius that runs months and tens of decisions deep. When uncertain, bias toward the higher-care quadrant, not the lower-care one.

The research says weekly iteration produces 12x more learning than quarterly cycles. Does that mean I should always ship weekly?

The 12x figure applies to reversible decisions where shipping produces real signal. It does not apply to decisions where you cannot meaningfully evaluate the result within a week. Shipping a pricing experiment weekly is meaningful because you get conversion data. Shipping a new co-founder agreement weekly does not make sense because the learning loop for that decision runs on months. The velocity advice is accurate within its domain. That domain is Ship Today and Ship This Week decisions.

How do I apply this framework when I have an external deadline, like a product launch?

External deadlines compress the deliberation window for all quadrants, but they do not change which quadrant a decision belongs in. They do change the triage logic. If a launch deadline means you cannot run a 30-day Think Hard process on a co-founder decision, the right call is usually to delay the launch rather than rush the co-founder decision. The blast radius of a wrong co-founder choice will exceed the blast radius of a delayed launch in almost every case. Deadlines are a reason to prioritize your deliberation time, not a reason to misclassify decisions.

Is this framework different from the Bezos Type 1 / Type 2 decision model?

It shares the reversibility axis. The addition here is the learning velocity dimension, which Bezos’s original framing does not emphasize. A Type 2 (reversible) decision that has a slow feedback loop, say, a test of a brand positioning angle where you will not see meaningful data for three months, is a different animal from a Type 2 decision with a fast feedback loop, like a pricing test. The two-speed matrix produces four categories instead of two, and the learning velocity dimension is particularly relevant in the AI era, when building is cheap and the feedback loop is the real bottleneck.

How do I prevent Mode 2 over-shipping without slowing down my overall velocity?

The goal is not to ship less. It is to classify before you ship. The classification takes 90 seconds. For Ship Today decisions, this adds no meaningful friction and prevents the occasional mistake of treating a two-way door as a one-way door. For Think Hard decisions, this adds deliberate friction that almost always saves more time than it costs. The founders who run this system well are often faster on net, not slower, because they stop spending months deliberating on Ship Today decisions and stop spending weeks cleaning up over-shipped one-way-door mistakes.