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 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.
In order for this to work, you have to possess good taste. Not everyone has it, and it often does not translate across domains.
Good taste is an incredibly powerful differentiator in competitive markets like software. Seems like there’s 3-5 decent choices for darn near anything I need, and usually 1 smaller team has the product that stands head and shoulders above the rest.
Unfortunately, good taste doesn’t matter for a successful software product.
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?
If you want to do the proverbial “moving upmarket” then yeah you’re going to have this and a lot of other problems. Taste does not sell (let’s be nice and add “on its own”) in that segment.
Does that mean no one should try? I'd rather a tool be built and I don't use it than the tool not exist.
Like Ron Swanson said... "Never half-ass two things. Whole-ass one thing."
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.
That is the alternative timeline for software I always wanted to live in, both as a user and as a developer. Make it 100 different tools instead to make it even more likely that there is a close enough match.
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.
If you give people a limited set of tools they quickly improve until then they need (well, want) different tools. In order to keep your customers you'll inevitably end up adding new things.
Tiered versions work well.
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.
“…good chance at having a match” might be a reach, as more use cases create a viable market.
Are your customers selecting one of five features in your product, or choosing any twenty from among a hundred?
How do the consumers find which of the dozen tools support the 20% they need?
By, get this, trying out the products. Revolutionary.
How about less snark?
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.
You're right. Even across stuff I _really_ use it's hard to bring myself to try.
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
I tried codex on a whim when my Claude code rate limited me. Canceled my max subscription and stuck with codex
It’s amusing how much of a difference in experience I hear about this. Almost hilarious if you take into account what this thread is discussing.
I dunno. I get that we have different needs, but I enjoy testing out new productivity tools. I'm sort of a productivity-software-junkie. I don't use almost any of the things I try, but I enjoy exploring the market.
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.
This post is about some highly interactive software with a lot of design decisions, and this thread is about finding whether or not your 20% feature niche is supported.
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.
>”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…
Assuming it's enterprise software.. then maybe?
Hopefully you can afford to say "No" a lot.