Uncomfortably Narrow at Product Launch

Recently an entrepreneur was talking about his new startup and how they were “uncomfortably narrow” with the feature set at product launch. For years we’ve been talking about the minimum viable product and “if you weren’t embarrassed by your product at launch, you waited too long.” Both drive home the point that entrepreneurs often build too many features for too many people before launch, thereby reducing their chance of success (too much capital burned, code base slowing down development, failure fatigue, etc.)

Ever since hearing the term “uncomfortably narrow” it’s been rattling around in my head. Entrepreneurs by their very nature are optimists, ready to resourcefully will their ideas into the world. Something that is uncomfortable narrow is, by definition, less than what is desired.

Fewer features. Fewer modules. Fewer use cases.

Entrepreneurs want to build more. Hence the internal conflict around purposefully limiting the product and making it uncomfortably narrow.

Getting a potential customer to say “yes” is much harder than saying “no.” Thus, the thinking goes that more features are needed to overcome these sales objections. While that can be the case, in the early days that’s often code for “your product doesn’t solve my core issue.”

Instead of adding more features around something that doesn’t solve the core issue, which is the normal approach, the better route is to be uncomfortably narrow and just solve the core issue. Then, once the customer is happy, add new functionality around it. This might mean a modest iteration or a serious pivot to build a valuable core.

Entrepreneurs should be uncomfortably narrow at product launch, and stay that way until it’s clear their limited feature set has provided customers something truly valuable.

With happy customers, and the start of product/market fit, only then is it time to expand the functionality. Start uncomfortably narrow at product launch.