Comment by nielsbot
20 days ago
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.
2 replies →
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.
6 replies →
>”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.