The 0 to 1 Project

Why 0→1 Is Different From Everything Else

There is a version of software engineering that is well understood. You have a system. It is too slow, or too unreliable, or it is missing a feature users keep asking for. You design a solution, break it into tasks, estimate the work, and execute. The uncertainty is mostly technical. The finish line is mostly clear.

The 0 to 1 project is not that.

In a 0 to 1 project, you are building something that does not exist yet. You are not filling a gap in an existing system. You are answering a question nobody has answered inside your organization before: should this thing exist? And then, if the answer is yes: what exactly should it be?

These two questions — "should it exist?" and "what should it be?" — are not technical questions. They are questions about belief, about organizational will, and about whether you can maintain both long enough to get to the other side. Most 0 to 1 projects die not because the engineers couldn't build the thing, but because they couldn't keep the organization believing in the thing long enough to find out.

The Blank Page Problem

When you have nothing to point to, everything is hypothetical. And humans — especially experienced engineers and pragmatic managers — are trained to be skeptical of hypotheticals. They have seen too many big ideas that sounded great in a presentation and turned out to be harder than expected, more expensive than planned, or just plain wrong about what users wanted.

Their skepticism is earned and healthy. But it creates a specific problem for you: you need to build enough to prove the idea has merit, but you need organizational support to build anything. This is the blank page problem. You cannot get permission without evidence, but you cannot get evidence without permission.

The way through is not to wait for the organizational approval process to move, and it is not to ask for forgiveness after you have already built something unauthorized. The way through is to deliberately shrink what you need permission for. You do not ask to build the thing. You ask to run a small experiment that will help you figure out whether the thing is worth building.

This is not a trick. It is the right way to think about the early phase of a 0 to 1 project. You genuinely do not know yet whether the thing is worth building. The experiment is real. The learning is valuable regardless of the outcome. And when you frame it that way honestly, most managers and executives will say yes — because what you are asking for is low risk and high information.

The Org Immune System

Large organizations have an immune system. It evolved for a good reason: to protect the company from distractions, from half-baked ideas that consume headcount and produce nothing, from engineers who want to rewrite everything just because the new thing is more interesting. The immune system is, on balance, good. Without it, nothing would ever ship.

But the immune system does not distinguish between genuinely bad ideas and genuinely good ideas that are just early. It responds to newness and uncertainty the same way regardless of merit. When you are building something new, you will run into the immune system whether you want to or not.

The immune system has several common forms:

• The "not invented here" reflex. Other teams see your new thing as a threat to the systems they own, the relevance of their work, or the headcount they might lose. They will raise concerns — sometimes valid, sometimes not — and the concerns will feel like principled technical objections even when they are primarily political ones.
• The "prove it first" loop. Leadership wants to see evidence of success before committing resources, but without resources you cannot generate the evidence. This loop can go on forever if you let it.
• The prioritization squeeze. Every six months, your project goes back into the planning process and competes against projects that have proven track records, existing users, and measurable metrics. New things never win on metrics because they do not have any yet. They can only win on narrative and sponsorship.
• The credibility tax. If you have spent your career maintaining existing systems, you will be asked to prove that you can build something new. If you have spent your career building new things, you will be asked to prove you can maintain and scale them. The organization will always find a way to frame your past as evidence that you are not quite right for whatever comes next.

Understanding these patterns in advance is not cynicism. It is preparation. You cannot fight the immune system with frustration. You fight it by making your project progressively less new-looking at each stage: first a small experiment, then a validated prototype, then a product with early users, then a product with metrics. Each stage, the immune system has less to grab onto.

Phase 1: Building Belief Before You Build Anything

Before you write a single line of production code — before you even write a detailed design doc — your job is to build belief. Belief in you. Belief in the idea. Belief that the problem is real enough and the opportunity large enough to justify the cost.

This sounds soft. Engineers often resist it because it feels like "politics" rather than "work." But building belief is as much a part of executing a 0 to 1 project as writing code. If you skip it and jump straight to building, you will almost certainly end up with a technically correct thing that nobody in the organization supports, and that eventually gets killed not because it failed but because nobody powerful enough ever believed in it.

The Pre-Project Project

The very first phase of a 0 to 1 project is what I call the pre-project project. It has no official name, no official headcount, no official timeline. Its goal is to produce one deliverable: a clear answer to the question "is this worth building?"

The pre-project project usually takes four to eight weeks and involves three activities:

• Problem interviews. Talk to the people who have the problem you are trying to solve. Not to validate your solution — too early for that — but to understand the problem at a level of depth that lets you describe it better than anyone else in the building. You want to be the world's foremost expert on this specific problem inside your company. That expertise is what gives you standing to propose a solution.
• Landscape mapping. Find out whether anyone else has tried to solve this problem before, inside the company or outside it. If someone tried and failed, find out why. If there is an external solution that already exists, understand why the company has not adopted it. There is almost always a reason — cost, compliance, integration complexity, not-invented-here — and you need to know what it is before someone raises it as an objection in a meeting.
• A written problem statement. Write a clear, crisp description of the problem that anyone in the company could read and understand. Not a technical design. Not a solution. Just the problem: who has it, how often, what it costs them, and what they do today instead. This document will become the foundation of every future conversation about the project.

When you have these three things, you are ready to talk to a potential sponsor. Not to pitch the solution — to share your findings and get their reaction to the problem. The distinction matters. You are not selling yet. You are informing, and watching whether the person you are talking to cares about what they are hearing.

Building Conviction Without Data

One of the most uncomfortable truths about 0 to 1 projects is that you will be asked to justify them before you have the data to justify them. The data only exists after you build the thing. But you need to convince people before you build the thing. This is not a solvable problem — it is a permanent condition of creating something new. The best you can do is build conviction out of the materials available to you.

Here is what conviction looks like when data is scarce:

• Analogy evidence. Has a similar thing been done at another company? What happened? Analogies are not proof, but they change the conversation from "will this work?" to "why would it work differently here than at Company X?" That is a much more tractable question.
• Qualitative signal. If you have talked to twenty engineers who all say the current situation is painful, that is real evidence even without a survey. Document it. Quote people directly (with permission). Specific, attributed complaints are more persuasive than anonymous surveys.
• Cost of inaction. What happens if nobody builds this? Can you quantify it? Even a rough estimate — "our current approach costs roughly two engineer-weeks per quarter across five teams, which is roughly 40 engineer-weeks per year" — makes the opportunity concrete.
• A falsifiable hypothesis. State clearly what you believe and what would change your mind. "I believe that if we build X, teams will adopt it within three months and reduce Y metric by Z percent. If they don't adopt it within six months, I think we should stop." This signals intellectual honesty and makes the decision about continuing or stopping easier to make later.

Finding the Right Sponsor

Every 0 to 1 project needs a sponsor. Not a manager who is politely supportive. Not a VP who once said "that sounds interesting." A real sponsor — someone who will use their political capital to defend your project when it comes under pressure, which it will.

The right sponsor has three qualities:

1. They care about the problem you are solving, not just your solution. If they care about the problem, they will stick with the project even when the solution changes. If they only care about your specific design, they will get disengaged the moment you pivot.
2. They have enough organizational standing to protect the project. A sponsor who cannot defend you against a hostile VP is not an effective sponsor. They need to be at or above the level where the project will be challenged.
3. They are willing to advocate out loud, not just internally. Some leaders are supportive in private but non-committal in public. You need someone who will say "I believe in this team and this project" in the meetings where it matters, not just send you an encouraging Slack message.

Finding this person is a deliberate process. You identify candidates — usually two or three leaders whose areas of ownership are most affected by the problem you are solving — and then you have a series of conversations that start with the problem, not the pitch. You share what you have learned. You ask questions. You listen for who responds to the problem the way you do: with recognition, with curiosity, with a kind of professional irritation that says "yes, this has been bothering me too."

That person is your sponsor candidate. The next step is to ask directly: "I'm planning to propose this project. Would you be willing to help me think through whether it's the right thing to do, and if so, sponsor it?" Most people respect the directness. It is much better than assuming someone is your sponsor because they seemed enthusiastic once.

Phase 2: The Prototype

Once you have a sponsor, a clear problem statement, and at least informal organizational support to explore, you are ready to build something. But what you build in this phase is not the product. It is the proof. The prototype's job is not to be good software. Its job is to make the idea legible to people who cannot reason from a design doc.

This distinction matters because the instincts that make someone a good software engineer — thoroughness, reliability, robustness, elegance — are actively counterproductive when building a prototype. A prototype built with engineering excellence takes too long, costs too much, and often answers the wrong question. You are not asking "can we build this well?" You already know you can. You are asking "is the idea itself worth pursuing?"

What Prototype Actually Means

Prototype is one of the most overloaded words in software. For the purposes of this chapter, a prototype is the smallest thing you can build that answers the question "does this idea have legs?"

What that looks like depends entirely on the project. Sometimes it is a click-through UI mockup with no real backend. Sometimes it is a working but fragile implementation of the core feature with hardcoded data. Sometimes it is a script that does in five minutes what would normally take an engineer two days. The right level of fidelity is the minimum that lets real people — not just you — experience the idea and give you meaningful feedback.

LOW FIDELITY                                    HIGH FIDELITY
──────────────────────────────────────────────────────────────

 Static        Clickable    Working      Working       Production
 Mockup   →    Prototype  → Core Only  → Full Flow  →  System
                                         (no scale)

 Hours to        Days to      Days to      Weeks to      Months+
 build           build        build        build

 Answers:        Answers:     Answers:     Answers:      Answers:
 Is the UX       Can users    Does the     Does the      Can it
 intuitive?     do the task? core logic   end-to-end    scale and
                             work?        experience    survive?
                                          feel right?
        

The mistake most engineers make is jumping to the right side of this spectrum too quickly. They build production-quality code when a mockup would have answered the question in one tenth the time. The reason is psychological: a rough mockup feels inadequate. It feels like it does not represent the real idea. It feels embarrassing to show.

But here is the truth: the people you are showing it to — your potential users, your sponsor, your leadership — are far less bothered by roughness than you are. They understand that it is early. What they are evaluating is not the polish. They are evaluating whether the problem recognition is accurate, whether the core idea is coherent, and whether they want to use it. A rough demo that answers those questions is infinitely more valuable than a polished design doc that does not.

The Demo Trap

The demo trap is when you spend more time making the prototype look good for presentations than making it useful for testing. It is easy to fall into. Demos are high-stakes moments. You want to impress. You want the prototype to reflect well on you and your team. So you polish the parts that are visible in the demo while leaving untested the assumptions that actually matter.

The result is a prototype that works perfectly in a controlled twenty-minute presentation and immediately fails when anyone tries to use it naturally. Worse, you may leave the presentation believing you have validated the idea when you have only validated that you can control a demo.

The antidote is to define your validation questions before you build the prototype, and to test those specific questions deliberately — not in a demo, but in actual use. Put the prototype in front of three or four real users and watch them use it without guidance. Don't explain it. Don't rescue them when they get confused. Just watch. The places where they get confused are the places where your assumptions about the user experience were wrong. That is the feedback that makes the prototype valuable.

When to Stop Prototyping and Start Productionizing

This is one of the hardest judgment calls in a 0 to 1 project, and most teams get it wrong in one of two directions: either they never stop prototyping (the endless-MVP death spiral) or they switch to production mode too early (before they have validated the core idea).

The signal to move on from prototyping is not a calendar date or a feature checklist. It is the answer to a specific question: have you learned what you needed to learn?

Specifically, you are ready to stop prototyping when:

• You have validated that real users, not just stakeholders, find the core experience useful enough to want to use it again.
• You have identified the two or three design decisions that are most likely to determine success, and you have made those decisions with real user feedback — not assumptions.
• You have identified at least one show-stopping technical risk, investigated it enough to know whether it is real, and either resolved it or built a plan to resolve it.
• Your sponsor and at least one other senior stakeholder have seen the prototype and are willing to commit resources to the next phase based on what they saw.

Notice that none of these criteria are about the prototype being "good enough to ship." They are all about learning. Once you have the learning, you do not need the prototype anymore. In fact, continuing to invest in the prototype after you have the learning is expensive — you are building on a foundation that you know will be replaced.

Phase 3: Productionizing — The Part That Takes Longer Than You Think

At some point, you have a validated idea, a sponsor who is committed, and approval to build the real thing. This is when most engineers think the hard part is over. It is not. The prototype proved the idea works. Productionizing is where you prove the idea works at scale, under real conditions, for real users, without you personally babysitting it.

These are very different challenges. And the move from prototype to production is where many promising 0 to 1 projects either stall or subtly become something worse than what they were as a prototype.

The Rewrite Instinct

The first instinct of almost every engineering team when they move from prototype to production is to throw away the prototype code and start clean. The reasoning sounds sensible: the prototype was hacked together quickly, it has no tests, the architecture was not designed with scale in mind, and it would be faster to start fresh with the right foundation.

This reasoning is sometimes right. But it is right far less often than teams think. And acting on it has a hidden cost that teams consistently underestimate: the prototype, for all its ugliness, carries a large amount of implicit knowledge about what actually works. The weird workaround in function X exists because four cleaner approaches all failed in ways that are not documented anywhere. The odd UI flow exists because three more obvious flows all confused users in testing. The prototype is not just code — it is accumulated knowledge encoded in decisions.

When you rewrite from scratch, you lose that knowledge. You will rediscover some of it through the same painful process that produced it the first time. You will miss some of it entirely and ship things that don't work, until users tell you, which takes months.

A better default is incremental replacement. Keep the prototype running. Identify the specific parts that are most likely to cause problems at scale — usually the data storage layer, the authentication mechanism, and the most performance-sensitive code paths. Replace those parts first, carefully. Leave the application logic and the UX alone until you have validated that the new foundation handles the load.

Incremental Hardening: What Production-Ready Actually Means

Production-ready is not a state you reach. It is a continuous process of reduction — reducing the probability and impact of failures until the system is reliable enough for its context. A tool used by twenty internal teams with a human on call can tolerate failures that a customer-facing API cannot. Be honest about what your context actually requires before you commit to production standards that were designed for a different scale.

There is a useful mental model here: think in tiers.

The mistake is jumping from Tier 0 to Tier 3 expectations before your user base justifies it. You will spend six months building reliability infrastructure for a product that has eight users and is not yet proven to be worth the investment. This is how 0 to 1 projects turn into expensive, slow, over-engineered failures.

Start at Tier 1. Move to Tier 2 when your user base and the criticality of the product actually demands it. Move to Tier 3 when it becomes a real dependency for real users. Rushing this progression is one of the most reliable ways to kill momentum on a new project.

The Founding Team Trap

In the early life of a new product, a small founding team carries enormous context. They know why every design decision was made. They know which parts of the code are fragile. They know which user complaints are real bugs and which are misunderstandings. They are effectively a walking, talking documentation system.

The founding team trap is when this team is never replaced with real documentation, real architecture, and real processes. The product grows. New engineers join. The founding engineers become bottlenecks — every significant decision passes through them because they are the only ones who understand the system well enough to make it. Over time, they burn out. Some leave. When they do, they take with them the institutional knowledge that the product runs on.

Avoiding this trap requires deliberate investment at a moment when the team feels most productive and least like they have time for it: the first major stabilization after the prototype phase. This is when you write the architecture doc, create the onboarding guide, document the non-obvious design decisions, and build the runbooks. It feels slow. The product is not yet popular enough to justify the investment, which is exactly why most teams skip it.

Do not skip it. The founding team trap is slow-moving and invisible until it is catastrophic. The engineers who survive it are the ones who treated documentation and process as load-bearing infrastructure — not as something you do after the product is successful, but as part of what makes it successful.

The Internal Launch

The internal launch is the moment when your new product stops being a project that some engineers are working on and starts being a product that teams are using. This transition is more fragile than it looks. Many promising 0 to 1 projects get stuck here — the product works, the team is proud of it, but adoption stays frustratingly low, and slowly the project loses organizational priority.

The reason this happens is almost always the same: the team built the product and then waited for users to show up. They announced it in a Slack channel. They wrote a launch post. They maybe gave a demo at an all-hands meeting. And then they went back to building features.

This approach works well for external products with a large potential user base and a marketing team. It works poorly for internal tools, where the "users" are your colleagues who have existing workflows, existing tools, and a strong status quo bias. Asking your colleagues to change their workflow is not like releasing a public product. It is a sales process, and it requires the same things a sales process requires: understanding their specific pain, showing them specifically how your product addresses it, and removing every possible friction from the path from "I'm curious" to "I'm using it."

Turning Colleagues Into Users

The most effective internal launches are not broadcast announcements. They are a series of small, personal conversations followed by high-touch onboarding followed by fast follow-up on early feedback.

Here is the sequence that works:

1. Identify your first target users specifically. Not "all engineers" or "all teams." Which three or four teams have the most acute version of the problem you are solving? These are your early adopters. Focus everything on them first.
2. Have a one-on-one conversation with their lead. Not a general pitch — a specific conversation about how their team experiences the problem. Show them exactly how your product addresses their specific situation. Ask what would make them try it this week.
3. Do the onboarding with them. Do not send documentation and ask them to figure it out. Sit with them — in person or on a call — for the first thirty minutes of real use. Watch where they hesitate. Fix the things that trip them up. This is valuable for them and invaluable for you.
4. Follow up within 48 hours. Ask what is working and what is not. Fix the friction fast. Users are most engaged and most honest in the first week of using a new tool. That window closes quickly.
5. Let them become your advocates. When an early adopter has a good experience, ask them explicitly: "Would you be willing to mention this to other teams?" A recommendation from a peer is worth ten announcements from the product team. Your early adopters are not just users — they are your first sales force.

Closing the Feedback Loop Fast

The relationship between a new internal product and its first users is unlike any other. Early users are taking a risk — they are changing their workflow based on your word that your product will make their lives better. They are owed fast, responsive treatment of the problems they find.

The feedback loop speed sets the relationship tone. If you fix something within 24 hours of hearing about it, your early users start to feel like partners. They report more issues. They suggest more improvements. They become invested in the product's success because they can see their own input reflected in it.

If you treat early feedback like a feature backlog — triaged, prioritized, and addressed in the next sprint — your early users disengage. They stop filing issues. They start working around the problems. The number of reported bugs goes down, but that is not because there are fewer bugs. It is because users no longer believe reporting is worth their time.

In the first month after an internal launch, treat feedback from early users as interrupting work. Your job in that window is not to build new features — it is to make the product reliable enough and smooth enough that the users you have stay and tell others. Nothing you build in month two will matter if you lose your month-one users because you were too slow to fix their problems.

The Politics of Building New

By this point in the book, you know that organizational politics are not a distraction from the real work. They are part of the real work. In a 0 to 1 project, the political dimension is unusually prominent because you are not just asking the organization to approve a project — you are asking it to believe in a future that does not yet exist. That is a harder sell than almost anything else in the execution playbook.

Defending Your Budget

Every organization goes through resource allocation cycles — usually quarterly or annually — where all projects compete for continued investment. Established projects defend themselves with metrics: "we processed X transactions, we reduced latency by Y, we onboarded Z teams." New projects cannot do that. They defend themselves with narrative and momentum.

To survive budget cycles, you need three things:

• A visible milestone at the moment of review. If your project just shipped something notable — a new pilot team adopted the platform, a key feature shipped, a performance target was hit — it creates positive context for the budget conversation. Time your milestones deliberately. Do not have the budget review happen during a quiet period.
• A credible roadmap to metrics. You cannot offer metrics yet, but you can offer a specific, dated commitment to when you will. "By Q3 we will have three pilot teams fully onboarded and can report adoption metrics, time-savings estimates, and satisfaction scores." This is more convincing than "metrics will come eventually."
• Your sponsor visibly in your corner. Budget conversations happen at levels above you. Your sponsor is the one in the room making the case. Make sure they are armed — with the latest milestone, the best user quote, the clearest version of the opportunity. Do not assume they know the current state of the project. Brief them before the review.

The Momentum Window

New projects have a momentum window — a period of time, usually six to eighteen months, during which the organization extends them unusual patience. The idea is new enough to be exciting. The team has not yet had time to make big mistakes. The sponsor is still engaged. Leadership is curious.

This window closes. It closes when the project takes too long without showing real results. It closes when a higher-priority initiative absorbs the sponsor's attention. It closes when the team turns over. It closes when the budget tightens and established teams with established metrics become the path of least resistance.

The most important thing to know about the momentum window is that you must use it to produce something real — not just something impressive in a demo, but something that real users actually depend on — before it closes. Once you have real dependencies, the project has a different kind of protection. Real users push back when a project gets cut. They escalate to their own managers. The project acquires defenders beyond the original team and sponsor.

Before that, it is only as safe as the organization's current mood about new things, and that mood can change quickly.

  Organizational
  Support
      │
  HIGH│  ● Launch excitement
      │   ╲
      │    ╲   Momentum window
      │     ╲  (extend unusual patience)
      │      ╲
  MED │       ────────────●─────────────────────────
      │                   ╲  Real users acquired
      │                    ╲ Project now has defenders
      │                     ╲  beyond original team
  LOW │                      ─────────────────────────
      │
      └───────────────────────────────────────────── Time
             0       3       6       9       12 months

  ━━ Organizational patience (without real users)
  ━━ Organizational support (with real users)
        

The practical implication is this: your first priority after the internal launch is not to build more features. It is to make the users you have so dependent on what you have built that they would notice and complain if it went away. Depth of adoption beats breadth of adoption every time during the momentum window. A product that ten teams casually try is far more vulnerable than a product that three teams genuinely rely on.