↓

There's a continuously resurfacing debate over when to ship new features or iterations of your product. In one corner, the "if you aren't embarrassed, you waited too long" crowd; in the other, the "we need to ship quality software" bunch. Unfortunately, neither camp bothers to explain why they're shipping.

Before P/M-fit, you ship to learn, or to fix something that's so bad it's actively harming your ability to learn. Shipping better versions of things because "better is better!" is death, not because better is worse, but because while you're busy lifting a 5 to a 7, you're ignoring a host of things that are stuck at zero. Moreover, you don't have enough validation to know which things are going to make the final cut. If you spend a bunch of time and energy getting something to an 8 or a 9, only to find out it's unnecessary ... not only is that a waste, but it's going to be much harder for you to even learn that it's unnecessary after a host of biases take root.

Before fit, your product is an interface to learn what people really want. Therefore, its quality is entirely a function of how quickly and effectively it allows you to learn. The traditional sense of "oh, this works really well" matters only insofar as a reasonable person can argue that a lack of this quality will taint your takeaways. "We won't learn what we need to." In other words, the test is flawed.

But you can run a high quality test using a low quality feature. And that means how you feel as a maker standing next to that feature is secondary in the same way Babe Ruth had a runner-up in his era: it is inconsequential.

After fit, you ship to tease out what people want, or to give people more of what they want. This is the land of optimizing: better really is better. Getting a metric from 1.5% to 2% is a 33% lift! Even better: improvements compound.

What if you don't know where you are? If you're confused, because the downside of wasting time before fit is so grave, you should take a learning-is-the-priority posture:

If the feature is entirely new, ship it when the value of what you'll learn by releasing it exceeds the known upside of making it better. "Yes, just one more day of tweaks and it will be twice as fast!" is not a good reason to invest that time if you're unsure that they will follow through on their promises to use it and you can count the days you have remaining as a company.

If it's an improvement, you should ship it as soon as the updated version is better than what we have now; and you should allow a small tinge of guilt to wash over you while promising that "this is now good enough, we have to get back to the zeroes unless we want to die."

Also, be willing to consider my personal favorite: your nearest exit is behind you. In this scenario you drop everything because this work shouldn't have been prioritized in the first place. There's either a better (cheaper or faster) way to learn this thing, or you haven't yet taken the time to describe what you'll be learning.

To know when, first answer why.