The Product Nobody Sees

The most impactful product I have ever built had no interface.

No onboarding flow, no settings page, no button that said “Try it now.” It was a routing algorithm that matched buyers with the nearest seller who had the item in stock. The buyer never knew it existed. They just noticed their order arrived faster.

I spent three months on that system. Mapping seller locations, defining distance thresholds, building fallback logic for edge cases where the nearest seller was out of stock but the next-nearest had a surplus. The A/B test results came back strong: fulfillment time dropped, shipping costs fell, and the promotional budget stretched further because we stopped subsidizing cross-country deliveries.

Nobody on the marketing team wrote a launch announcement. No product hunt post. No “we are excited to announce” email. The feature shipped silently, improved millions of transactions, and the only people who knew it existed were the engineers who built it and the PM who specced it.

This experience changed how I think about product impact.

Visibility is not a proxy for value

Product managers love launches. The demo, the screenshot in the company all-hands, the Slack thread full of party emojis. I understand the appeal. Launches feel like progress, and visible features are easy to explain to stakeholders.

But the systems underneath — the data layer, the routing logic, the synchronization engine — carry most of the weight. They determine whether the visible features actually work at scale.

I have built both kinds. The multi-location inventory system had a seller-facing UI. Sellers could see their warehouses, manage stock levels, switch between locations. That was the visible product. Behind it sat a data model that tracked inventory at the location level, synchronized across the platform in near-real-time, and handled conflict resolution when two locations reported different stock counts for the same SKU.

The UI took a month. The data layer took three. The data layer is why it worked.

How I evaluate what to build

I ask two questions now before committing to any initiative:

First, what breaks if this does not exist? If the answer is “users would be mildly inconvenienced,” it is a feature. If the answer is “the platform cannot reliably process orders,” it is infrastructure. I prioritize infrastructure.

Second, who notices when this works correctly? If the answer is “nobody,” that is usually a sign I am working on the right thing. The best infrastructure is invisible. Users notice when it fails, never when it succeeds.

The uncomfortable truth

This is hard to sell to stakeholders. “I want to spend three months on something nobody will see” does not win budget fights. I have learned to frame it differently: “This will reduce fulfillment time by several hours and save the company significant promotional spend per quarter.” Same work, different frame. The numbers do the selling.

Product managers who can only ship visible features will always be at the mercy of the roadmap. Product managers who can build the systems underneath get to shape what the roadmap is capable of delivering.

I prefer working on the plumbing.