completeness

Suppose you're announcing two brand new roads:

1. A functional gravel road
2. A smooth paved road ... with a stretch of road with massive potholes

The paved road is problematic. The road crews are out there fixing the potholes as we speak. If you spread the word and people start driving down the road and they hit the potholes and have to turn around, they might not try it again - not worth the hassle. They might tell their friends to avoid the road so as to not waste their time. They could get stuck in the potholes and cause delays for the crew trying to fix the potholes.

The gravel road is not an ideal solution, but people have heard of gravel roads and know what to do and how to drive on it. Some people don't want to drive on gravel roads, and so they won't try it out, but that's okay. The people who do drive on gravel roads will try it and unsuprisingly be pleased when they arrive at their destination. They'll mention it at a gathering and someone else might try it out. With more usage, you can justify paving the road and thus making it faster, smoother, and cleaner, which becomes a moment to wow the drivers. Even in the unideal case where it turns out nobody wants to go to the place you built the road to - you've wasted less time.

in product terms

A lot of building and releasing products, especially at startups, is about finding the gravel roads. By choosing the gravel option whenever possible, you can often prove your hypothesis quicker, with a lot less work, all while building a positive reputation as a product that does the thing people need. The best part is - from a marketing perspective, you're mostly selling the same thing - we can get you from point A to point B.

In the opposite world, you risk eroding customer trust while also frustrating the engineers stuck with the task of fixing potholes on a road where customers are zooming down.

I see this concept of completeness - delivering a product that is cohesive for what it is, even if that something is slightly less than you hoped - as essential for healthy products and nine out of ten times, I will choose it over its more (potentially) impressive but confusing cousin. Completeness comes in a lot of forms - for code it might be shipping with few bugs; for the product, it might be making sure the default .

in engineering terms

As an engineer, I take a lot of pride in my craft and in my work, and if I find myself often releasing a proverbial road with potholes in it, it causes frustration.

If I were to push up code that behaves in surprising or inconsistent ways, it reduces trust in the code we're building on and makes it harder to plan future work on top of it - we have to go through and document the location of all the potholes or risk forgetting about them. For completeness specifically as it pertains to engineers, I really enjoy the mental model presented by What Shape are You?, where the author presents development as a subtractive process, rather than an additive one.

the exception

There's a caveat - what if the hypothesis is fully dependent on the road being paved?

In reality, there are a lot of parts of your product that don't need to be the paved road. Eventually yes, it'd be wonderful to make the gravel road faster, cleaner, and smoother by paving it, but often times this can come much later, and it's much more about the new destination and the value you've shown. Who knows, maybe your hypothesis wasn't even correct to start - what if people are really looking for a train. 😉

Build more gravel roads.