In the chaotic environment of a startup, it is easy to mistake motion for progress. You can spend twelve hours a day in meetings, answering emails, and researching competitors, yet end the week with nothing to show for it. This happens when you focus on tasks rather than results. The solution to this trap is a strict focus on the Deliverable.
A Deliverable is a tangible or intangible good or service produced as a result of a project. It is the distinct, verifiable “thing” that marks the completion of a phase of work.
For a founder, a deliverable is the receipt that proves work was actually done. It transforms the abstract concept of “working hard” into a concrete asset that can be reviewed, tested, or sold.
The Anatomy of Done
#A deliverable must be binary. It is either done or it is not done. There is no such thing as a “90 percent complete” deliverable in the eyes of a client or a user.
Examples of deliverables vary by department:
- Engineering: A compiled executable file or a merged pull request.
- Design: A Figma file containing the high fidelity UI mockups.
- Marketing: A published blog post or a launched ad campaign.
- Sales: A signed contract.
Notice that “researching the market” is not a deliverable. That is an activity. A “market research report” is a deliverable. The difference seems subtle, but it is critical. You cannot critique an activity. You can only critique a deliverable. By forcing your team to define the artifact they will produce, you force them to clarify their thinking.
Output vs. Outcome
#It is vital to distinguish between a deliverable (output) and a result (outcome).
The deliverable is within your control. You can control whether you ship the code by Friday. The outcome is often outside your control. You cannot fully control whether users like the code.
However, you cannot get the outcome without the output. Founders often get paralyzed worrying about the outcome, so they delay the deliverable. They tweak the slide deck forever because they are afraid investors will say no.
You must separate the two. Focus on shipping the deliverable to the highest standard possible within the deadline. Then, let the market decide the outcome. You cannot iterate on something that has not been delivered.
Killing Scope Creep
#The primary enemy of the deliverable is scope creep. This occurs when the requirements of a project slowly expand until the deadline becomes impossible to hit.
Defining the deliverable at the start of the project acts as a contract. It sets the boundaries. If you agree that the deliverable is a “five page website,” and halfway through the stakeholder asks for a mobile app, you can point to the original definition.
It allows you to say, “That is not in the scope of this deliverable. We can add it to the next one.” Without a clearly defined deliverable, you have no defense against the never ending request for “just one more thing.”
The Internal Currency
#Inside a startup, deliverables are the currency of trust.
When you promise a specific deliverable by a specific date and you hit it, you build political capital. When you promise vague progress and show up empty handed, you burn capital.
Founders need to audit their own weeks. Look at your calendar. How many of your meetings are about discussing work, and how many are about reviewing deliverables? If you are doing too much of the former and not enough of the latter, you are likely spinning your wheels.