Skip to content
/ALMANAC
Menu

Ship an Imperfect Product

Utpal Vaishnav2 min read

Hand-drawn sketchnote showing a product leaving an endless perfection spiral and crossing an enough threshold guarded by value, quality, risk, and reversibility before moving toward learning.

The 2012 note

It is not perfect. It can still be improved.

That is the wrong question. The better question is: when can I ship it?

It can be shipped when it is adequate.

The effort spent making it perfect beyond what is adequate may be waste. You can change the definition of adequate, but that definition should become the goal.

If your goal is to ship only after the product is perfect, you may eventually reach the goal and discover that nobody needs the product anymore.

What I would add now

Adequate is doing more work in this argument than the original note admitted.

Adequate cannot mean convenient for the team. It cannot mean the deadline arrived. It cannot mean the visible features work while the hidden risks move to the customer.

A responsible definition of enough needs boundaries.

It should name the value the product can already deliver. It should name the quality that cannot be traded away. It should identify who carries the risk if the product fails. It should distinguish a reversible release from a decision that cannot be easily undone.

The threshold will change with the consequence.

A private prototype can tolerate roughness that a payment system cannot. An internal experiment can carry uncertainty that a medical decision cannot. A reversible feature can be released with narrower evidence than a migration that puts years of customer data at risk.

This is not an argument for lowering standards.

It is an argument for making the standard explicit.

Perfection offers no operational threshold. Enough can, if we define it honestly.

Before shipping, I would now ask:

  1. What useful outcome is available now?
  2. Which quality conditions are nonnegotiable?
  3. Who carries the downside if we are wrong?
  4. How quickly can we detect failure?
  5. How safely can we reverse or correct the release?
  6. What evidence would justify waiting?

The product does not need to be beyond improvement.

It needs to be good enough for the promise we are making, the risk we are transferring, and the learning we expect to gain.

Source note

This is a present-day adaptation of Ship an imperfect product, first published on PMCraft on December 16, 2012.

Use this workExplore with AI

Explore this journal

Take this work into your preferred AI system. Choose a ready-made prompt or add your own context. Nothing you enter here is sent or saved by utpalmv.com.

Use the work as a thinking lens without adding personal context.