This is not an argument against shipping small. Releasing a large, finished form under uncertainty is usually more dangerous. What does not follow is the substitution that says a feature cut down and placed in production thereby becomes a test. This record examines the difference between those two kinds of small.
Why this record exists
If the situation is uncertain, ship small and learn. The statement itself is almost right.
In practice, however, a substitution like the following can take place.
- We will test because it is uncertain
- We can ship because it is small
- We ship because we can
- We will get feedback because we shipped
The last arrow is the most fragile.
The feature is small. At a glance it even looks useful. So ship it first, let people use it, and collect opinions—that is how the case is sometimes made. Placed inside a use case, though, the steps increase, the judgments increase, and the work stops halfway. Users receive no value. What comes back is “what is this screen?” and “this is hard to use,” not a verdict on the larger direction.
Shipping and testing are not the same act.
Two kinds of small
Making something small comes in at least two kinds.
| Small as a feature | Small as value | |
|---|---|---|
| What is cut | Screens, processing, fields, states | Target customers, target work, scope of responsibility |
| What remains | An operation that stops partway | The ability to complete a purpose |
| What can be confirmed | That it was built and can be operated | That the direction has value |
| How it fails | An unfinished piece is placed in production | The target is too narrow to generalize |
The first reduces the amount of building. The second reduces the amount of responsibility taken on.
Record 003 argued that one should not cut the flow of value halfway through, but reduce the responsibility the product takes on. What 004 asks is whether that reduced unit holds as a test.
A small feature is not even a precondition for small learning. An operation cut halfway through may not be a small experiment at all. It may only be unfinished work handed to the user.
The object of the test is replaced
When the word MVP is used, what we usually want to test is roughly this.
- Should the product take on this work?
- With this cut, can the user proceed?
- Will the next idea sit on top of this smallest form?
Once the logic becomes “ship it for now,” what gets confirmed is something else.
- Does the screen exist?
- Can it be operated?
- Does it behave according to spec?
These are checks of implementation. Implementation checks are necessary. They do not close a product hypothesis.
If feedback is what we want, it will not speak to the larger idea until the other person has completed something. Ask “how was it?” of someone who never finished, and what returns is an impression of an experience that stopped. The object of learning was already off to the side.
“Looks useful” breaks the test
An isolated feature looks useful in an explanation. Less typing. A list. A button. Seen on its own, having it seems better than not having it.
Inside a use case, the story changes.
It does not connect to the work before and after. A required judgment is missing. It appears done, yet cannot be handed to the next person. There is no way to escape an exception, and ordinary work slows down. Users are not then evaluating whether the feature is needed. They are sending a signal closer to “I do not want to do this job in this product.”
Usefulness in a part and value across a complete piece of work are different things. Ship the former and expect feedback on the latter, and the test breaks.
Unfinished version, smallest form
A common reading is this.
It will become a larger value eventually. For now we ship only a part. The rest, people can imagine.
That can work as a demo or an explanation. As an MVP it is weak. Users are under no obligation to fill in what is missing and then evaluate. A reaction padded by imagination is evidence neither that the idea is right nor that it is wrong.
The substitution is this.
An MVP is not an unfinished version of a larger value.
It is the smallest form of that larger value that already holds.
An unfinished version leaves holes that are supposed to connect later. A smallest form is already part of the next idea, in the experience as it stands.
Suppose, for example, the work should eventually include automated judgment. The smallest form is not “only the first half of the judgment screen.” It is that a particular person can complete a particular case, including a human review, from beginning to end. Automation is not yet in scope. Completion is. From that use, one can see whether automation can sit on top of this completed shape.
What has been made small is not the middle of a feature, but the target and the scope of responsibility.
What to make small, and what to keep
If we are going to ship small, the following should be placed first.
-
Whose work, and which work
Narrow what is being tested now; not every customer and every exception. -
What that person will be able to complete
Not that a screen exists, but that a purpose ends. -
How far the product will go, and where it returns the work to a person
Beyond the cut, is there a handoff that still holds? -
Which question this release is meant to close
Not an impression of the interaction, but whether the direction is right—and, if it is, what becomes possible next.
It is not “we ship because it is small.” It is “we ship this far in order to close this question.”
As Record 002 put it, what the business wants to try does not become a test until it is converted into a product choice. “Get to market quickly” can be a purpose. If the unit being shipped does not hold as value, the market cannot answer even after it has been reached.
An experiment and a production fragment are not the same
A production feature release is not the only way to test a hypothesis. An explanatory screen, a manual operation, sitting with a limited set of users. Those can produce learning if they are designed as experiments. Participants can share what is being tried.
The problem is shipping a production fragment and calling it an experiment. Users do not think they have joined a test. They have been given unfinished work. The signal that returns is less often a verdict on the hypothesis than frustration with a job that stopped halfway.
If it is an experiment, design it as an experiment. If it is shipped as a product, make it the smallest form that can be completed. Call both an “MVP” and only the reason for shipping remains. The design of the learning disappears.
Tests for whether we have actually tried it
Three questions help reveal whether making the feature small has been mistaken for running a test.
- The completion test — What can the user finish from beginning to end?
- The signal test — Do we want an impression of the interaction, or a verdict on value? If the latter, it will only come from someone who completed the work.
- The connection test — If it works, what part of the next idea can sit on top of it? If nothing can, it is a fragment, not a smallest form.
If the first cannot be answered, shipping is not testing. If the second cannot be answered, we have not decided how to take feedback. If the third cannot be answered, the only reason it is small is that nothing more would fit the schedule.
In short
- Shipping small is, in itself, a serious response to uncertainty
- Being small as a feature and being small as value are nevertheless different
- A feature cut halfway through cannot test whether the larger idea is right
- “Looks useful” is an impression of a part, not value inside a use case
- An MVP is not an unfinished version of a larger value; it is the smallest form that already holds
- A production fragment and learning designed as an experiment are not the same kind of “shipping”
Keep the phrase “ship it in order to try.” What must not be kept is the habit of letting the fact of shipping stand in for the fact of having tried.