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.
I think the Apple II is one example of this.
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.
First let’s look at B2B, there the “user is not the buyer”. The buyer doesn’t care about “good taste” they care about a lot of other things.
(“Where is my SSO support for multiple users, I’m not going to have my IT department worry about tracking down usernames when Bob leaves)
https://news.ycombinator.com/item?id=46919794
Second, if you have the feature that people need or a service or network effect, they will suffer through a bad app - see every Electron app ever.
That “smaller team” may not be around in a year and if you are lucky, you’ll get an “Our Amazing Journey” blog post. Does this product export to a format that my design team can import into Figma if this product goes tits up?
Games are closer to that than any other type of software even if they tend to cluster around popular genres and styles a bit much.
I don't know anyone that doesn't use a combination of at least one simple, one feature laden, text editor. Most of us via notes apps, etc., routinely move between a range of text complexity, suitable to a range of things we want to write.
Having the simplest to the most powerful apps be consistent between each other, wherever they have feature commonality, would be really nice.
Are your customers selecting one of five features in your product, or choosing any twenty from among a hundred?
Especially when, who the heck has time for trying out a dozen products? That's at least a full day of work, which probably costs more than the software itself.
No, you just read a few reviews to find the best full price option and best budget option and figure out if the budget does what you need or not. And often go for full price just because you don't even know what features you'll need in 6 months which you don't need now, so safer to just learn the option that is the most future-proof.
Anecdotally I haven't tried Codex and use Claude Code. The day I try Codex will be when I hear from my friends/communities that it's much better. Same for IDEs, STT tools, etc
Then again, I do this in my free time. At work, I rarely deviate from what is provided and the handful of things that I explicitly added.
Let's be real, unless some soul somehow had the same 20% as yours and left a review somewhere, you won't know if the features you need, or their implemention, fit your need until you try.
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…
Hopefully you can afford to say "No" a lot.