And this really makes it hard for me as an “indie hacker” to do what people often recommend: solve one very specific problem. Find a niche. Something narrow and focused. “Zoom in”. This works in areas where problems have low cohesiveness, but not when they have high cohesiveness.
It’s really hard to solve a lot of problems well. The value of an all-in-one product is that you really don’t need anything else. Everything it doesn’t do, or doesn’t do well enough to meet your needs, is a ding against it, and it’s relatively easy to peel off specific problem spaces from the general problem of basic business operations needs.
Here’s a specific example from the company I’m part of (Anrok). We sell a product that aims to replace a SaaS business’s need for an accounting team to be compliant with sales tax & VAT. We compete against both all-in-one solutions from billing systems that offer to also solve this problem because the problem is hard and they are trying to solve at least two problems: billing and tax. Since we just try to solve tax, we can do a better job of it. We also compete against accounting firms who try to offer you all-in-one services, but again same problem, plus the cost is a lot higher because they use humans to do what we do with code.
So I wouldn’t worry too much about the existence of everything apps. It takes a long time to build a good everything app that actually does “everything” within its domain (think Salesforce or Jira), and even then “everything” is often achieved via outsourcing some of the everything to third parties who build plugins and integrations.
I guess it’s a matter of pros and cons and tradeoffs.
On the one hand a product that solves a narrow and specific problem can focus more on that problem and do a better job of addressing it than a general, all-in-one product can. But then on the other hand it still seems to me that the what I propose about cohesion stands.
Using Anrok as an example, on the one hand the fact that Anrok is narrowly focused on tax and thus is able to do a better job of solving tax-related problems works in Anrok’s favor. But on the other hand, there are cohesion-related things that work against Anrok such as having to integrate with other tools and such as customers having to spend more time shopping (with an all-in-one solution they just buy one thing and are done).
I suppose you’d agree that there are in fact tradeoffs at play here and that the real question is what direction the scale tends to lean. And I suppose you are of the opinion that the scale tends to lean in favor of narrower, more targeted solutions than broader, more all-in-one solutions. Is all of that true? If so, would you mind elaborating more on why you are of that belief?
(with an all-in-one solution they just buy one thing and are done)
That’s a very common misconception regarding all-in-one tools. In practice, all-in-one tools always need a significant degree of setup, configuration and customization before they are useful for the customer. Salesforce, for example, requires so much customization, you can make a career out of just doing Salesforce customization. Sharepoint is similar.
Thus the trade-off isn’t between a narrowly focused tool that does one job extremely well versus an all-in-one tool that does a bunch of things somewhat well. The tradeoff is between a narrowly focused tool that does one job extremely well immediately, with little or no setup versus an all-in-one-tool that does many things somewhat well after extensive setup and customization, which itself might require hiring a specialized professional.
To use the Anrok example, is it possible to do VAT calculations in the existing tools that the business already has, such as ERP systems or CRM software? Yes, of course. But that software would need to be customized to handle the specific tax situation for the business, which is something that Anrok might handle out-of-the-box with little setup required.
In practice, all-in-one tools always need a significant degree of setup, configuration and customization before they are useful for the customer. Salesforce, for example, requires so much customization, you can make a career out of just doing Salesforce customization.
I can see that being true for all-in-one tools like Salesforce that are intended to be used across industries, but what about all-in-one tools that are more targeted?
For example, Bikedesk is an all-in-one piece of software that is specifically for bike shops and I would guess that the overall amount of setup and configuration for a shop using Bikedesk is lower than that of a bike shop using a handful of more specific tools.
The tradeoff is between a narrowly focused tool that does one job extremely well immediately, with little or no setup
I suppose the “little or no setup” part is sometimes this is the case, but it seems to me that often times it is not the case. Specifically, when the level of cohesiveness is high it seems to me that it is probably not the case.
Using the bike shop as an example, inventory management software that isn’t part of an all-in-one solution needs inventory data to be fed to it and thus will require a moderate amount of setup and configuration.
I suppose you’d agree that there are in fact tradeoffs at play here and that the real question is what direction the scale tends to lean. And I suppose you are of the opinion that the scale tends to lean in favor of narrower, more targeted solutions than broader, more all-in-one solutions. Is all of that true? If so, would you mind elaborating more on why you are of that belief?
Scaling the business is different than getting started.
To get started it’s really useful to have a very specific problem you’re trying to solve. Provides focus and let’s you outperform on quality by narrowly addressing a single need better than anyone else can.
That is often the wedge to scale the business. You get in by solving a narrow, hard problem, then look for opportunities to expand your business by seeing what else your customers need or what else you could do given the position your in.
To give another example from a previous employer, Plaid got their start by providing an API to access banks, and they did everything they could to make it the best-in-class experience, with special attention on making the experience great for developers so they would advocate for paying a premium price over cheaper alternatives. That’s still the core business, but they’ve expanded into other adjacent products both as API access to banks has become easier to come by (in part thanks to Plaid’s success) and as customers have come looking for more all-in-one solutions to their fintech platform needs (e.g. a money-movement product so they don’t have to manage transfers on their own, alternative credit decisions tools, etc.).
Given your desire to do something that’s more lifestyle business than a high-growth startup, better examples might be to look at similar lifestyle products. In the LW-sphere there’s things like Complice and Roam, and outside LW you’ll find plenty of these that have been quite successful or were successful in the past (Basecamp is a prime example here, but I think Slack was arguably a lifestyle business that accidentally figured out how to take off when they pivoted to messaging away from MMOs, etc.).
I agree with everything you’ve said. Let me try to clarify where it is that I think we might be disagreeing.
I am of the opinion that some “narrow problems” are “good candidates” to build “narrow solutions” for but that other “narrow problems” are not good candidates to build “narrow solutions” for and instead really call for being solved as part of an all-in-one solution.
I think you would agree with this. I don’t think you would make the argument that all “narrow problems” are “good candidates” to build “narrow solutions” for.
Furthermore, as I argue in the post, I think that the level of “cohesion” often plays an important role in how “appropriate” it is to use a “narrow solution” for a “narrow problem”. I think you would agree with this as well.
I suspect that our only real disagreement here is how we would weigh the tradeoffs. I think I lean moderately more in the direction of thinking that cohesiveness is important enough to make various “narrow problems” insufficiently good candidates for a “narrow solution” and you lean moderately more in the direction of thinking that cohesiveness isn’t too big a deal and the “narrow problem” still is a good candidate for building a “narrow solution” for.
To be clear, I don’t think that any of this means that I should attempt to build all-in-one products. I think it means that in my calculus for what “narrow problem” I should attempt to tackle I should factor in the level of cohesion.
It’s really hard to solve a lot of problems well. The value of an all-in-one product is that you really don’t need anything else. Everything it doesn’t do, or doesn’t do well enough to meet your needs, is a ding against it, and it’s relatively easy to peel off specific problem spaces from the general problem of basic business operations needs.
Here’s a specific example from the company I’m part of (Anrok). We sell a product that aims to replace a SaaS business’s need for an accounting team to be compliant with sales tax & VAT. We compete against both all-in-one solutions from billing systems that offer to also solve this problem because the problem is hard and they are trying to solve at least two problems: billing and tax. Since we just try to solve tax, we can do a better job of it. We also compete against accounting firms who try to offer you all-in-one services, but again same problem, plus the cost is a lot higher because they use humans to do what we do with code.
So I wouldn’t worry too much about the existence of everything apps. It takes a long time to build a good everything app that actually does “everything” within its domain (think Salesforce or Jira), and even then “everything” is often achieved via outsourcing some of the everything to third parties who build plugins and integrations.
I guess it’s a matter of pros and cons and tradeoffs.
On the one hand a product that solves a narrow and specific problem can focus more on that problem and do a better job of addressing it than a general, all-in-one product can. But then on the other hand it still seems to me that the what I propose about cohesion stands.
Using Anrok as an example, on the one hand the fact that Anrok is narrowly focused on tax and thus is able to do a better job of solving tax-related problems works in Anrok’s favor. But on the other hand, there are cohesion-related things that work against Anrok such as having to integrate with other tools and such as customers having to spend more time shopping (with an all-in-one solution they just buy one thing and are done).
I suppose you’d agree that there are in fact tradeoffs at play here and that the real question is what direction the scale tends to lean. And I suppose you are of the opinion that the scale tends to lean in favor of narrower, more targeted solutions than broader, more all-in-one solutions. Is all of that true? If so, would you mind elaborating more on why you are of that belief?
That’s a very common misconception regarding all-in-one tools. In practice, all-in-one tools always need a significant degree of setup, configuration and customization before they are useful for the customer. Salesforce, for example, requires so much customization, you can make a career out of just doing Salesforce customization. Sharepoint is similar.
Thus the trade-off isn’t between a narrowly focused tool that does one job extremely well versus an all-in-one tool that does a bunch of things somewhat well. The tradeoff is between a narrowly focused tool that does one job extremely well immediately, with little or no setup versus an all-in-one-tool that does many things somewhat well after extensive setup and customization, which itself might require hiring a specialized professional.
To use the Anrok example, is it possible to do VAT calculations in the existing tools that the business already has, such as ERP systems or CRM software? Yes, of course. But that software would need to be customized to handle the specific tax situation for the business, which is something that Anrok might handle out-of-the-box with little setup required.
I can see that being true for all-in-one tools like Salesforce that are intended to be used across industries, but what about all-in-one tools that are more targeted?
For example, Bikedesk is an all-in-one piece of software that is specifically for bike shops and I would guess that the overall amount of setup and configuration for a shop using Bikedesk is lower than that of a bike shop using a handful of more specific tools.
I suppose the “little or no setup” part is sometimes this is the case, but it seems to me that often times it is not the case. Specifically, when the level of cohesiveness is high it seems to me that it is probably not the case.
Using the bike shop as an example, inventory management software that isn’t part of an all-in-one solution needs inventory data to be fed to it and thus will require a moderate amount of setup and configuration.
Scaling the business is different than getting started.
To get started it’s really useful to have a very specific problem you’re trying to solve. Provides focus and let’s you outperform on quality by narrowly addressing a single need better than anyone else can.
That is often the wedge to scale the business. You get in by solving a narrow, hard problem, then look for opportunities to expand your business by seeing what else your customers need or what else you could do given the position your in.
To give another example from a previous employer, Plaid got their start by providing an API to access banks, and they did everything they could to make it the best-in-class experience, with special attention on making the experience great for developers so they would advocate for paying a premium price over cheaper alternatives. That’s still the core business, but they’ve expanded into other adjacent products both as API access to banks has become easier to come by (in part thanks to Plaid’s success) and as customers have come looking for more all-in-one solutions to their fintech platform needs (e.g. a money-movement product so they don’t have to manage transfers on their own, alternative credit decisions tools, etc.).
Given your desire to do something that’s more lifestyle business than a high-growth startup, better examples might be to look at similar lifestyle products. In the LW-sphere there’s things like Complice and Roam, and outside LW you’ll find plenty of these that have been quite successful or were successful in the past (Basecamp is a prime example here, but I think Slack was arguably a lifestyle business that accidentally figured out how to take off when they pivoted to messaging away from MMOs, etc.).
I agree with everything you’ve said. Let me try to clarify where it is that I think we might be disagreeing.
I am of the opinion that some “narrow problems” are “good candidates” to build “narrow solutions” for but that other “narrow problems” are not good candidates to build “narrow solutions” for and instead really call for being solved as part of an all-in-one solution.
I think you would agree with this. I don’t think you would make the argument that all “narrow problems” are “good candidates” to build “narrow solutions” for.
Furthermore, as I argue in the post, I think that the level of “cohesion” often plays an important role in how “appropriate” it is to use a “narrow solution” for a “narrow problem”. I think you would agree with this as well.
I suspect that our only real disagreement here is how we would weigh the tradeoffs. I think I lean moderately more in the direction of thinking that cohesiveness is important enough to make various “narrow problems” insufficiently good candidates for a “narrow solution” and you lean moderately more in the direction of thinking that cohesiveness isn’t too big a deal and the “narrow problem” still is a good candidate for building a “narrow solution” for.
To be clear, I don’t think that any of this means that I should attempt to build all-in-one products. I think it means that in my calculus for what “narrow problem” I should attempt to tackle I should factor in the level of cohesion.