| ▲ | crazygringo 3 hours 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? |
|
| ▲ | nielsbot 3 hours ago | parent | next [-] |
| 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. |
| |
| ▲ | dvt 3 hours ago | parent | next [-] | | 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. | | |
| ▲ | linkregister 11 minutes ago | parent [-] | | In order for this to work, you have to possess good taste. Not everyone has it, and it often does not translate across domains. |
| |
| ▲ | reactordev 3 hours ago | parent | prev | next [-] | | >”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… | |
| ▲ | thfuran 3 hours ago | parent | prev [-] | | 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. |
|
|
| ▲ | vitaflo an hour ago | parent | prev | next [-] |
| 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. |
|
| ▲ | cosmic_cheese 3 hours ago | parent | prev | next [-] |
| > 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. |
|
| ▲ | PeterStuer 2 hours ago | parent | prev | next [-] |
| "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. |
|
| ▲ | Alex63 2 hours ago | parent | prev | next [-] |
| 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... |
| |
| ▲ | conductr 33 minutes ago | parent [-] | | 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. |
|
|
| ▲ | james2doyle 3 hours ago | parent | prev | next [-] |
| Makes me wish more apps had feature toggles |
| |
| ▲ | roberthahn 3 hours ago | parent | next [-] | | The testing that would be required to support toggles would be for 2^n. I’m not sure that’s a good solution. | | |
| ▲ | wavemode an hour ago | parent | next [-] | | > 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. | |
| ▲ | dlcarrier 3 hours ago | parent | prev [-] | | 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. | | |
| ▲ | roberthahn 3 hours ago | parent | next [-] | | Yeah I like that idea too. Theres a lot of people who would have trouble with that approach though. | |
| ▲ | AlienRobot 2 hours ago | parent | prev [-] | | One common case I notice this is with FFMPEG. Everything that saves a video needs its own dialog with different settings. It would make a lot more sense if you had 1 single polished FFMPEG frontend that everyone just streamed data to. On the other hand, I'm afraid that if this did happen that FFMPEG frontend would look like a GNOME app and I would hate using it. | | |
| ▲ | mylastattempt 2 hours ago | parent [-] | | Me, on the other hand, love ffmpeg, because I notice my ytdlp using it and my vlc player sometimes using it and I have two homemade powrshell scripts using it to convert flac to mp3 and whatever. I don't want to open a program and figure out it's UI for those things. It has a job, it does it well, you can sort of pipe things to it and I'm very happy. | | |
| ▲ | AlienRobot 2 hours ago | parent [-] | | I'm not sure you understood what I mean. I'm talking about applications like Krita using FFMPEG to export their data as video. Sometimes they include their own FFMPEG instead of using FFMPEG installed in the system. Each of them has its own dialog. The only way to input custom settings for FFMPEG would be to export in a lossless video format and then reencode using FFMPEG, when you should be able to just "connect" a data stream to an FFMPEG frontend as the input and the frontend has all the options you might want to customize how that data is turned into a .mp4 file or .mov file. |
|
|
|
| |
| ▲ | 3 hours ago | parent | prev [-] | | [deleted] |
|
|
| ▲ | dlcarrier 3 hours ago | parent | prev [-] |
| 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. |
