completeness

Imagine your county is announcing two new roads that have just been built to connect neighboring towns:

1. A gravel road
2. A smooth paved road ... but a stretch of the road has massive potholes

The paved road has challenges. The road crews are out there right now fixing the potholes. With the announcement, people start trying to use it only to run into the potholes and have to turn around. They might not try it again - not worth the hassle. They might tell their friends to save the trip and avoid the road. They could get stuck in the potholes and cause delays for the crew out there trying to fix them.

The gravel road is not perfect, but people have used gravel roads before and know how to drive on them. Some people don't want to drive on gravel roads (you have to go slower, you have to get your car washed after) and so they won't try it out, but that's okay. The people who do will use it and be happy to be getting where they're going. They'll mention it to their neighbors and someone else might try it out. With more usage, you can justify paving the road, thus making it faster, smoother, and less dusty. Even if you discover less people want to visit their neighboring town than you thought - you've wasted less time and money.

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 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.

I see this concept of “completeness” - delivering a product that is cohesive for what it is - as essential for healthy products.

That product will inevitably do less than you hoped, but nearly every time, I will choose it over its more (potentially) impressive but confusing cousin. 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.

incorporating into engineering

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 user journey leaves little space for confusion. As an engineer, if I find myself releasing a proverbial road with potholes in it too often, it’s a recipe for 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 as it specifically pertains to engineers and how you should think about your work, I 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

What if the product hypothesis is strictly dependent on the road being paved?

I’d challenge that this scenario is a lot less common than you think. When put to a microscope, there are a lot of parts of your product that don't need to be the paved road than you think. Eventually yes, it'd be wonderful to improve the gravel road by paving it, but oftentimes this can come much later.

In practice, I’ve seen that it’s much more about showing value and getting feedback sooner. Our first instincts can be trained, but are often wrong. Perhaps the hypothesis wasn't even correct to start - what if instead of a road, people are really just looking for a train!

Build more gravel roads.