I think a successful product strategy can be "build something you love, see if others love it too". If that's enough customers, you can judiciously expand out from there. The "fail honestly" method.

I think the Apple II is one example of this.

This is the best way to build products imo. I'm like this, and I've been accused of being very "vibes-based." However, that's a way more tractable way of shipping stuff instead of "well Jim said he wants X, but Amy said she wants Y" so you end up just kind of half-assing features because you think they might get you users, instead of just being passionately all-in into a very defined product vision (which is a very Jobsian way of doing things).

It's also easier to run a feedback loop. If you implement Y, but Amy doesn't give you $5 a month, what are you going to do? Knock on her door? Users have no idea what they want half the time, anyway.

If you build a product and no one cares, it bruises the ego a bit more, sure, but if you self reflect, you can eek out your own bad assumptions, or bad implementation, or maybe a way to pivot that keeps your product ethos.

>”you can judiciously expand out from there”

Which is where the bulk of the other 80% of features come from. It’s a cycle.

You start as you describe, you expand, you end up with this enterprise monstrosity, everyone using a different 20%. New tool comes along, you start as you describe…

If ten people make focused tools covering different 20% subsets of the giant ones, there's a good chance of having a choice that matches what any given customer wants. And for most customers, that's going to be a better match than a big tool that does tons of other stuff they didn't want.