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.
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.