🗂️ Do users really want an all-in-one product?
by•
We often hear that users want fewer tools, fewer tabs, and everything in one place.
But does that really mean they want an all-in-one product?
There’s an interesting trade-off between all-in-one and best-in-class.
There’s probably a line where an all-in-one product becomes too complicated.
Adding more features can mean fewer tools, less context switching, and a more connected workflow.
But it can also mean more menus, more settings, a steeper learning curve, and a product that becomes harder to understand.
So where is the line?
Do users really want one product that does everything - or do they just want fewer problems to manage?
Curious to hear how other makers and users think about this.
111 views
Replies
honestly, I think users want fewer problems, not necessarily one product that does everything, all-in-one is great until you need it to be really good at one specific thing, then best-in-class wins. The line for me is whether the "extra" features actually save a step or just add another menu to learn.
RunEvr
@samran_elahi Agreed.
Do you see value in learning and configuring a little more upfront if it means you can then have an automated workflow?
For me, that’s probably the best option.
But I’ve noticed a trend these days where users want to put in almost no effort and still expect the product to solve complicated problems for them.
@adana Yeah, I actually agree with that, there's definitely a gap between wanting simple and wanting powerful. I think the upfront config is worth it if the payoff is real automation and not just moving the complexity somewhere else. The issue is more when a product asks for that setup time but doesn't actually delivery the automation after.
Curious though, do you think most users can tell the difference upfront, or does it only become obvious once they're already invested in the setup?
RunEvr
@samran_elahi I think if I have a problem to solve, I’ll research the automation capabilities the software offers. If I see a solution that could actually solve my problem, I’ll give it a try.
Although, we can never know for 100% if upfront setup will actually deliver the automation we need.
@adana that makes sense, research first then commit if it looks like it will actually solve the problem. I think that's probably the most realistic approach, you can't fully know upfront, you just have to make the best call with what's available and adjust from there.
"Fewer tools" and "one tool" aren't the same wish. What people actually hate is the handoff: copy this out of A, clean it up, paste it into B, remember to do it again next Tuesday. Nobody minds having two tabs open if the second one already knows what happened in the first.
So the test I use now is: does feature B read feature A's output? If yes, it belongs in the same product. If it just sits in the same sidebar, you haven't built an all-in-one, you've built a bundle with one login. Bundles are where the complexity comes from. Every new thing in the nav makes the nav worse, and nothing else gets better.
I ship a bunch of separate products rather than one big one, mostly because they share nothing, so they have no business sharing an app. The one place I did merge things is inside a flashcard tool, where you pick which app you want to export to. It doesn't export to all of them at once, which was the obvious feature and the wrong one, it just carries your text and settings over when you switch targets. Same input, different destination. That's the entire thing, and it's the only part anyone actually noticed.
Which is why for RunEvr I'd ask it per feature instead of per product. Chat plus project progress is a real merge, one is context for the other. Chat plus invoicing is two apps holding hands.
RunEvr
@siarheihamanovich Thanks for sharing your experience!
In RunEvr, the modules naturally fit together to form the product. We wanted to connect the different tabs so they can, as you said, “read” from one another and share context.
What kind of tools and products are you developing? Are you working solo or with a team?
@adana Solo, all of it. Day job is engineering management, so the products get evenings and weekends, which is its own design constraint: if a feature can't ship in a couple of sessions it usually means I haven't understood it yet.
Main one is NextLang, it turns a text, a PDF or a photo into flashcards you can import into Anki, Quizlet, Mochi or Brainscape. Started because I was learning Polish and hated typing decks by hand. Around it there's a wine recommender, a trading tools and a couple of Telegram bots, all things I actually use.
The modules fitting together naturally is the good version of the problem, by the way. That usually means the domain decided the shape and you're not talking yourself into a merge after the fact. How did you land on the current set of tabs, did you plan them upfront or did they show up one at a time?
Adjust Page Brightness - Smart Control
as user i think i need few problems to manage, i often try to use all profiles in same browser, i want my work to be organised, in every chrome profiles i use same sign ups of my chatgpt account , so yeah in my opinion i need less problems to manage c
RunEvr
@kshitij_mishra4Â As I understand it, you think that having everything in one environment could reduce your problems ? =)
There's a third option that's not really "all-in-one" or "best-in-class" - unify the interface, not the backend. I've been looking at a bunch of launches today that all do this: one product gives you a single URL/token/agent that routes to dozens of specialized tools underneath, so you get one thing to learn but the actual work still happens in whatever tool is best at that task. You get most of the "fewer problems to manage" benefit without the all-in-one product actually having to be good at everything itself, since it's not trying to replace the specialists, just the coordination overhead of using 10 of them. Feels like the honest answer to your question is: users don't want fewer tools, they want fewer places where they have to remember how something works.
RunEvr
@omri_ben_shoham1Â Absolutely agree with your last sentence.
And I agree that products that unify the interface rather than the backend are becoming a very interesting modern approach. Do you use any ?
@omri_ben_shoham1Â I'm finding I don't want to learn or use UI anymore I reach for connecting my agent and having it do it for me. I still build the UI for humans but I feel having an agent API available that can do everything is the way forward.