Comment by crazygringo
18 days ago
> I kept finding myself using a small amount of the features while the rest just mostly got in the way. So a few years ago I set out to build a design tool just like I wanted. So I built Vecti with what I actually need...
Joel Spolsky said (I'm paraphrasing) that everybody only uses 20% of a given program's features, but the problem is that everyone is using a different 20%, so you can't ship an "unbloated" version and expect it to still work for most people.
So it looks like you've built something really cool, but I have to ask what makes you think that the features that are personally important to you are the same features that other potential users need? Since this clearly seems to be something you're trying to create a business out of rather than just a personal hobby project. I'm curious how you went about customer research and market validation for the specific subset of features that you chose to develop?
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.
4 replies →
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.
1 reply →
“…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?
7 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.
> Joel Spolsky said (I'm paraphrasing) that everybody only uses 20% of a given program's features, but the problem is that everyone is using a different 20%, so you can't ship an "unbloated" version and expect it to still work for most people.
To me this is an argument for more apps that do less extremely well instead of a handful of apps that do everything poorly. There's nothing wrong with a tool that's honed for very specific user. They'll never hyperscale, but that's also fine.
Or then again maybe they can. Google Docs is plenty popular despite being closer to WordPad or TextEdit in terms of functionality than it is to MS Word.
Then you'll need interoperability of development artifacts to work with teams.
opendoc remembers...
3 replies →
Every now and then I stumble on video game developers who have been chugging along for many years, even decades with a handful of dedicated fans. They make obscure niche games that play so well into that niche that they can sustain themselves. Honestly this is something I'd aspire to get to eventually, building a niche product that I love and that just enough people love that I could live sustainably on it, not trying to please anyone but a little collective of people who all agree on what the product should be.
Creeper World, am I right?
This is a far bigger small world than some might expect. The number of devs and games he's referring to numbers well into the thousands. A quick search [1] shows more than 4 games are released per day on Steam which will go on to earn more than $50k in revenue, so about 1500 per year.
It's wild - I'm a big gamer but I strongly doubt I could even list 1500 games across all systems and time. And that many games make $50k+ each year.
[1] - https://gameworldobserver.com/2023/10/06/steam-stats-41k-gam...
1 reply →
A quick web search suggests that you are probably paraphrasing a newsletter [1] that Joel Spolsky published in 2001. He was talking about software like Excel (of which he was the Product Manager) and Word. Maybe a tool that is more focused on a narrower task (like UI design) can be less "bloated"?
[1] https://www.joelonsoftware.com/2001/03/23/strategy-letter-iv...
Not just that, it was Excel a quarter of a century ago.
I am not even sure it was still true by the time her wrote it. It think that there is a set of core features (laying out stuff in a table, simple formulae) and some very commonly used features (e.g. graphs, data filtering) and a long tail of less commonly used advanced features (pivot tables, database like formulae like VLOOKUP).
Its more like 80% of users only use the same subset. Less commonly used stiff is important to the people who do use them, so you need it to sustain the network effects and enterprise sales.
Agree. This quote is being used out of context here. Niche software can and does succeed especially when it’s only supporting a single dev. This isn’t trying to dethrone an adobe product, or doesn’t need to.
A tool focusing on design is not “niche software” - every company of any size has designers. It’s trying to get professionals to use their software instead of Figma. Why would I move my team from an industry standard that they know or would be willing to learn because they know it will be important at their n+1 job?
3 replies →
"everyone is using a different 20%"
In my experience, what people use is very malleable to how easy/good the flows are they are presented with. Given 100 equal options, they might use 20, and nobody picks the same 20, but given 25 options, 20 of which present a very good experience, almost 90% will go with those 20 without complaints.
Maybe the problem with software is feeling the need to satisfy 100% of users instead of being OK with "only" 20%. Not everything needs to be a min/max problem.
As long as the 20% is enough to sustain your company, sure. You might have to charge more, however. Luxury brands do this, for instance (fewer consumers is actually a strategic choice to make the product more exclusive). “Pro” products also do this (though often “pro” means more features, not fewer).
The point is that 20% of features doesn't satisfy even 20% of users. It's going to be only a tiny fraction of that because something like 99% of potential users are going to need at least one feature outside the 20%. And if a competitor has all the features they need, but you don't, then you lose the sale.
He was talking about Excel. Google Sheets with a tiny fraction of Excel features destroyed Excel except for a tiny minority of hardcore finance and Windows users.
> what makes you think that the features that are personally important to you are the same features that other potential users need?
I think this is a weird question. Sure he can't be the only soul in the world to need only those features. Those 20% people need gotta overlap. So I think a more generous way to read your question would be "what makes you think that the features that are personally important to you are the same features that the mass audience need?". If that's what you meant then I'd ask why appealing to the mass audience so important? Why maximize sales and risk making your product worse if the core of your product is to make things you care about?
> everybody only uses 20% of a given program's features, but the problem is that everyone is using a different 20%
This is a phrase that gets repeated and it sounds clever. But it's completely at odds with statistics, specifically the normal distribution.
We should say, people use 80-90% the same features, and then there's a tail of less common features that only some people use but are very important to them.
This is why plugin systems for apps are so important. You can build an app that supports the 80% with a tightly designed set of core features, and if someone needs to go outside of those they can use/build a plugin.
Assuming that users only use 20% of the program and that the usage is evenly distributed, which would be a really big assumption right there, then there is still a finite number of users before you will have used up every part of program functionality between your user base and that any users past that amount will be repeating an actual and specific percentage of program functionality already assigned to some other user, unless you want to argue that functionality can be reduced infinitesimally in a sort of Zeno-like process.
If you agree however that functionality profiles will repeat among users given a large enough user base then it implies a particular limited feature set can still be totally adequate to support program development.
And that is with assumptions stacked against you succeeding, if indeed, as would seem likely, that some user profiles are more widely distributed than others it would follow that a successful product can just focus on those.
Could it be more people want Instagram instead of Photoshop? Take a picture, choose from one of 10 filters. Have a ~12 adjustable settings. Vs Photoshop's 1000s of options.
Like lots of people prefer Trader Joes (limited selection) to a bigger super market
> Joel Spolsky said (I'm paraphrasing) that everybody only uses 20% of a given program's features, but the problem is that everyone is using a different 20%, so you can't ship an "unbloated" version and expect it to still work for most people.
I remember reading something like this while talking about developing in C++.
Makes me wish more apps had feature toggles
VIM does this perfectly. Not a single feature is exposed to the user. Every feature the user might ever want is supported, they need just Google for which keyboard incantation to invoke it.
Or follow the directions on the startup screen and type :help.
The testing that would be required to support toggles would be for 2^n. I’m not sure that’s a good solution.
> The testing that would be required to support toggles would be for 2^n
I don't think that's really true, unless the behavior of each toggle is tightly coupled to the behavior each other toggle.
Case in point - most mature apps nowadays do have hundreds of toggles for various settings and features.
Makes me wish more apps followed the UNIX model of separating every feature into separate applications with well documented interfaces that only change when new features absolutely require it and otherwise are only updated for security patches.
6 replies →
"customer research and market validation".
This is a provocative joke, isn't it?
Could you elaborate a little bit more, how a sole developer should do these things in a meaningful way, if even larger companies and start-ups fail with this?
Not at all.
The most basic way is to do a 30 min interview with 20 designers that cover a few each of freelance, small company, med company, large company. Find out which features they use and don't, and what their pain points are, and whether a tool with less features is something that would be majorly helpful or not very important.
Then do a round of validation with AdWords, can you get designers to click on the ad for something advertised as simpler and bloat-free, go to a landing page that explains what it has and doesn't have, and then put it their email to find out when it launches.
To me, that is the absolute bare minimum to make sure you're developing something that can be a business, rather than just a hobby for yourself.
And these are not my ideas or anything. They're pretty standard stuff, and there's a lot more you can and should do as well.
[dead]
> what makes you think that the features that are personally important to you are the same features that other potential users need?
Good question, what's the pitch:
“Vecti is a browser-based UI design tool built from the ground up with one core belief, that creators deserve tools built specifically for them. Better performance, better privacy, and better alignment with their actual needs. A tool that just works, built by someone who genuinely cares about the people using it.”
Hmm. Did founders of Balsamiq or Figma not care about the people using it? And who if not creators were they built for?
“Share & Present - Set viewer and editor permissions at the team or project level. When it's time to present … let your work shine.”
Oh, right, for the people who pay the creator.
Assuming a big enough audience, that 20% can still be significant enough to build a business around.
I feel like HTML and CSS could remove 90% of the functionality and only affect 1% of developers, then we could get some actually good web browsers.
The issue here is backwards compatibility with web pages that will never be updated. Nobody wants a browser that works with “most of the web.”
Well they did get rid of the blink tag
https://developer.mozilla.org/en-US/docs/Glossary/blink_elem...
And Gopher support…
2 replies →
For this was invented Quirks Mode.
1 reply →
I for one, would certainly prefer a wider ecosystem of _more refined_, less bloated tools.
The current system of a near-monoculture of garbage sucks.