7 ms·

Why Slight Failed: A Slight Post-Mortem

155 points by KraftyOne 2y ago

mritchie712 2y ago
Didn't see you mention Retool. I'd think if a company was aware of Retool, they'd always pick that over Slight.
- colmanhumphrey 2y ago
  I am surprised to hear you say this given your previous experience founding a product that from a distance might look to cover some similar space to retool but in practice is quite different. My perspective: only investors ever asked us about retool, not customers. Some of them even used retool tool. Hah even just typing this out brings me back to investor meetings!
andybak 2y ago
I would also maybe add "picking a name that's impossible to Google and hard to remember". The number of emails I get along the lines to "Your trial period of Foowazzle will expire soon" and my reaction is usually "I can't remember what the hell Foowazzle is". In fact the reason I often fail to actually use trials of potentially interesting services after signing up is because I forget what they are called and can't find them when I need them. At least "Foowazzle" would be easy to search for...
- deleted 2y ago
  [deleted]
- mritchie712 2y ago
  In all our automated emails, we put something like "As a reminder,[name of company] is a ..."
  - andybak 2y ago
    That's better than most but it only solves half of my problem.
- Reimersholme 2y ago
  [dead]
- colmanhumphrey 2y ago
  haha, not sure I agree with this one at all, I think a name is pretty far down the list of priorities for a business. I would be extremely surprised if "customers who started trials but then didn't use the product at all, but then later wanted to, but couldn't because they couldn't find the name" is a segment that moves the needle. From this brief note, you sound like you potentially are trialling an order of magnitude more services than the average person. I bet that gives you a ton of interesting perspective on all these products, sign-up flows, etc, but probably puts you in a very unusual position with respect to product names!
eatonphil 2y ago
I chatted with Colman years ago when Slight was around about joining forces and I was really impressed by his character and intelligence. It didn't work out between us for unrelated reasons. And then later on they shut Slight down as described here. But failure is such a good learning experience. If he ever starts something again I would definitely recommend folks to follow/join it.
- ipnon 2y ago
  Yes I always think of this stat I read where the average successful business owner is currently working on their 7th business venture. The implication is then if you want a successful company you should speedrun 6 duds.
dccoolgai 2y ago
A really level-headed take on what must have been a very tough experience. I'm reminded of the Star Trek TNG quote "It's possible to commit no mistakes and still lose that's not weakness, that's life."
- moffkalast 2y ago
  "Sometimes you eat the bar, and sometimes the bar, well, he eats you."
- pmarreck 2y ago
  Had to look it up! I won't link the youtube but it is from ST:TNG s02e21 "Peak Performance"
YukiTanak8 2y ago
[flagged]
CharlieDigital 2y ago
> Distribution Incredibly hard with B2B/enterprise SaaS, even if you solve a problem that they have. Across three different startup efforts, I've learned that even if some team loves the product: 1) legal/compliance/IT team gets involved and kills it for a handful of common reasons, 2) it addresses a key part of their workflow, but the primary process exists in some *other* system so they are not willing to add a new system, 3) the potential customer sees a small startup team as a risk and are not willing to switch part of their process to an unproven entity. I think it can be overcome for small startups, but it requires that the pain point you are solving for is business critical, you have a very warm intro, or you have a team that has industry gravitas. EDIT: A key lesson learned for technical founders seeking co-founders where your target market is enterprise/B2B SaaS: the best non-technical candidates don't want to take the risk in a startup (because they are already making bank with enterprise sales) and most candidates that want to do a startup probably aren't the best candidates (because otherwise, they'd be making bank doing enterprise sales for an incumbent). It's really needle in the haystack that you find the right non-technical partner that can sell into an industry and is motivated by entrepreneurship.
- gregmac 2y ago
  > 3) the potential customer sees a small startup team as a risk and are not willing to switch part of their process to an unproven entity. This is one where having an open-source core helps a ton. In my role I'm often the one finding these and being a major influence in pushing for or against them, and one of the key things that pushes me away is having no exit path in case the company goes under, pivots or otherwise discontinues the product. If it's part part of our product or the delivery pipeline this is a critical factor, and sadly, I've said "no" to a lot of promising products for this reason alone. I've been burned before by this, and having to drop everything the team is doing to re-build something outside our control is not good for anybody -- it looks bad on me if I chose the thing, it makes all the developers irritated they have to shift focus, it causes chaos to PMs and their schedules, and it infuriates sales and everyone up the chain from there. Should be obvious, but: the more value the service provides, the more we're willing to pay, but also by its nature the more ingrained it is and thus more important there's an exit path.
devmor 2y ago
> If you don’t know how your product will be adopted, how would your customers know? I feel like this is both correct and incorrect at the same time, possibly because it’s almost a catch-22. With any online product at all, not just SaaS, the way your customers use your product may end up entirely different than how you planned your product to work. Of course, it’s important to have a direction to begin with, but I feel like analyzing how your customers use your tools and adjusting rapidly to that instead of sticking to what you wanted to build in the first place is what makes or breaks a lot of startups. Take that with a grain of salt though, I’ve still never launched a product with an ROI greater than the value of the time I put into it.
- colmanhumphrey 2y ago
  oh that's an interesting perspective. I would say you're right, and maybe I didn't phrase it well. I probably should have said something more like: if you don't know how, or if you can't learn how (through iteration etc), then how can your customers. Or something to that effect.
xnorswap 2y ago
Watching the demo, it doesn't look like the kind of product that's really usable for anyone who doesn't know SQL. If you need to know SQL to fully appreciate the tool, you're not going to want the tool.
- indulona 2y ago
  yeah, the description of the product itself makes very little sense, let alone on a business level. but we learn by doing and we learn only by failing, so this will look great on their resumes for future jobs and give them priceless knowledge for their future startups. although i would argue that this american degeneration of business, where every paper company is a startup, and every startup needs investors to make the product or service, must die, so that we can have actually viable products and not waste developer hours on nonsense.
- nicerob2010 2y ago
  Yeah, I was expecting a low-code/no-code way to build queries in a GUI and wondering why any company wouldn't jump at that (at least based on my own experience). Instead, I feel like this is a really nice SQL "IDE"
tyrw 2y ago
> Large companies didn’t want it enough to deal with our lack of “big company features” (enterprise SSO, compliance certifications... > We spent a bunch of time on multi-tenant infrastructure... I'm in a position where I talk to SaaS businesses all day about both of these. Probably over 1,000 at this point. We help a lot of these companies add the enterprise features they need, but it's often a shame to hear they're just going to do standard login or build multi-tenancy themselves. Trying to sell to enterprises without meeting them where they are on login & compliance is asking for failure. I think a lot of founders and early employees are true believers in their value prop, and in this case it blinds them to the fact that there are people in the world like enterprise CSOs who simply don't care and will shut down a product for any number of security reasons. You have to check the boxes, and figuring out what those boxes are on the fly is painful and costly.
- thenobsta 2y ago
  I'd love to hear more insights about on this. I'm just kicking off a B2B SaaS, have a rough idea of the checklist in my head, and am trying to balance core tech development with box checking.
  - louthy 2y ago
    GDPR & ISO27001 compliance are the important ones, but depending on the industry there maybe others (HIPAA for example). You need to hire an advisor and start writing everything down. Being able to hand over compliance documentation along with proof of an audit is absolute gold. If you don’t do this, be prepared for a mini-audit on every sale (if you get that far). Sales to governments will likely come with even more compliance requirements, national security audits, and potentially staff vetting. It’s not worth it early on unless you’re really well funded. Compliance does actually scale with the business, so it’s not particularly onerous at the start. Although it can get out of hand if you’re not careful. Compliance should be pragmatic. SSO is clearly one of the major factors for integrating anything into an enterprise organisation. Their IT team will want to have complete control over who has access, when somebody leaves the company they want to make sure that they can shut them down immediately, not have to reach out to third-party providers, or login to multiple systems. Ignore this at your peril. Independent penetration tests are also really important. You can usually resist requests for self-hosting or multi-tenancy if you have all the above, but not always. If they don’t think you’ll be around tomorrow, then they won’t touch you.
tschellenbach 2y ago
Failing is normal, good that you gave it a shot and learned.
drdrek 2y ago
With a lot of assumptions I would wager that it was indeed the founder skill set issue. Doing B2B sales is a skill, doing B2B marketing is a skill, doing fundraising is a skill, managing R&D is a skill, customer relations, legal, compliance, etc. You can learn anything, but you cant learn everything. If he had two founders, one from a sales background and one from R&D management while he was the product guy, I would wager his story would be different.
hintymad 2y ago
> Slacking around SQL snippets, schlepping around CSVs, devs having minor inconsistencies when running a bunch of ad-hoc queries: problems for sure, but not major ones for a small company. This is a general theme: it is hard to fight "good enough". Even in a big-enough company, a competent engineer will have a good enough way to manage queries, while incompetent ones won't care. In the end, very few people will want to pay for such service, or even want to learn such service.
- colmanhumphrey 2y ago
  This rings true, and I guess further backs up how important it is to carefully choose your initial customers, so the product is actually good enough by the time it gets to the broader swathe of companies. At least, that's my guess — I'm the one that failed after all!
acyou 2y ago
We shouldn't forget the history of SQL. I wasn't there, but my impression has been that it was originally written so that non-technical users (business decision makers) could write queries and have access to data in order to make business decisions. The data accessibility feature is ostensibly already built into the language. I think this original vision never ended up working out. I believe that business decision maker brains are not the same as SQL query writing brains. You need to be able to choose some facts, ignore the rest and persuade people. So this product adds (added) a middle layer in between the end user and the database. Either the user could learn this, or they could just learn SQL. But if the end users really care about what the data shows, they might as well just learn to write SQL queries, they aren't that hard. The reality is that end user business decision makers may not care that much about the SQL query output from data sets that may have a whole series of built in errors and biases anyways. I think business decision makers want to make decisions based on gut feel. In bigger companies and publicly traded companies, they then pay data analysts to produce data analyses that support those decisions, to CYA. In order to accomplish that, you don't need this tool, you just need vanilla SQL. The successful (LLM) tool would essentially have the business decision maker write a prompt that says: "I want to do X. Write me a report using this dataset that supports my decision". Yes?
dvt 2y ago
Man, I do really miss these postmortems on HN. We used to see several a month back when the site was more startup-focused. Great read! Don't want to dogpile with criticism, I'd just suggest brushing yourself off and trying again (heck, after multiple failures, I still am!).
pmarreck 2y ago
A fantastic idea that didn't find interested clients first, instead of after it was built. Could they have potentially avoided this by building a PoC and shopping that around with an NDA to gauge receptivity?
briandear 2y ago
The company didn’t die because they didn’t raise money. They died because they weren’t making money. The SV idea of a company needs to raise money in order to survive is a bit strange to me. If you’re building software, people should pay to use it. If they don’t, then fundraising is irrelevant. In other words, raising money should be for scaling and growth, not figuring shit out.
sirspacey 2y ago
This is such an excellent reflection, especially the iterative nature. “Yes but” is now a part of my toolkit to help me authentically unpack all the justifications that come to mind & convert them into learning. I’ve lead B2B SaaS revenue efforts a number of times. You correctly identified all the things that are hard and how customer size is a major factor in choosing what to build and how to sell. My general recommendation for a tool like yours is to sell to the professional who would use it in a “b2b2c” format like Slack. First win the champion, then the market they live in. Excited to see what you choose next!
- colmanhumphrey 2y ago
  a very generous comment! Very interesting you say that, I believe we did at some point have some thoughts about targeting B2B2C, but sadly that was one of the areas we failed to fully learn about / experiment / iterate on.
ipnon 2y ago
Corporations are really good at paying people just enough money to fix problems in a suboptimal way. Actually I think that’s what they optimize for. Past a certain size they minimize costs for the “just barely good enough” solution in a microeconomic way. So if you’re selling to corporations it’s best to get down to brass tacks. Show them proof of how spending $DOLLAR_AMOUNT with you each month is going to practically guarantee them saving `$DOLLAR_AMOUNT * (1 + $MARGIN)` on their accounting books. That’s a much higher bar than “it looks cool and makes employees happy,” but the nature of business is that no C-suite could ever turn down such an offer.
trash_cat 2y ago
> "Building a solution isn’t enough – it needs an obvious path forward" This is called implementation. You basically have people who work full time just on implementation plans and executions of it.
bitbasher 2y ago
They fell for the classic, "build a product and then find customers" strategy. It's the quickest way to burn 1-2 years. I have a saas product that I have been running for several years by myself and I would consider it quite successful. The "strategy" I used (if you can call it that) was almost the exact opposite. I witnessed customers paying services for a product. I looked at the product and thought, "Huh, I could do that and charge half as much" and then (the most important part), I did it.
- colmanhumphrey 2y ago
  That sounds like a very viable and valuable type of business, but it's kind of a different category of business model

155 points by KraftyOne 2y ago

mritchie712 2y ago

Didn't see you mention Retool. I'd think if a company was aware of Retool, they'd always pick that over Slight.

colmanhumphrey 2y ago
I am surprised to hear you say this given your previous experience founding a product that from a distance might look to cover some similar space to retool but in practice is quite different. My perspective: only investors ever asked us about retool, not customers. Some of them even used retool tool. Hah even just typing this out brings me back to investor meetings!

andybak 2y ago

I would also maybe add "picking a name that's impossible to Google and hard to remember". The number of emails I get along the lines to "Your trial period of Foowazzle will expire soon" and my reaction is usually "I can't remember what the hell Foowazzle is". In fact the reason I often fail to actually use trials of potentially interesting services after signing up is because I forget what they are called and can't find them when I need them. At least "Foowazzle" would be easy to search for...

deleted 2y ago
[deleted]
mritchie712 2y ago
In all our automated emails, we put something like "As a reminder,[name of company] is a ..."
- andybak 2y ago
  That's better than most but it only solves half of my problem.
Reimersholme 2y ago
[dead]
colmanhumphrey 2y ago
haha, not sure I agree with this one at all, I think a name is pretty far down the list of priorities for a business. I would be extremely surprised if "customers who started trials but then didn't use the product at all, but then later wanted to, but couldn't because they couldn't find the name" is a segment that moves the needle. From this brief note, you sound like you potentially are trialling an order of magnitude more services than the average person. I bet that gives you a ton of interesting perspective on all these products, sign-up flows, etc, but probably puts you in a very unusual position with respect to product names!

eatonphil 2y ago

I chatted with Colman years ago when Slight was around about joining forces and I was really impressed by his character and intelligence. It didn't work out between us for unrelated reasons. And then later on they shut Slight down as described here. But failure is such a good learning experience. If he ever starts something again I would definitely recommend folks to follow/join it.

ipnon 2y ago
Yes I always think of this stat I read where the average successful business owner is currently working on their 7th business venture. The implication is then if you want a successful company you should speedrun 6 duds.

dccoolgai 2y ago

A really level-headed take on what must have been a very tough experience. I'm reminded of the Star Trek TNG quote "It's possible to commit no mistakes and still lose that's not weakness, that's life."

moffkalast 2y ago
"Sometimes you eat the bar, and sometimes the bar, well, he eats you."
pmarreck 2y ago
Had to look it up! I won't link the youtube but it is from ST:TNG s02e21 "Peak Performance"

YukiTanak8 2y ago

[flagged]

CharlieDigital 2y ago

> Distribution Incredibly hard with B2B/enterprise SaaS, even if you solve a problem that they have. Across three different startup efforts, I've learned that even if some team loves the product: 1) legal/compliance/IT team gets involved and kills it for a handful of common reasons, 2) it addresses a key part of their workflow, but the primary process exists in some *other* system so they are not willing to add a new system, 3) the potential customer sees a small startup team as a risk and are not willing to switch part of their process to an unproven entity. I think it can be overcome for small startups, but it requires that the pain point you are solving for is business critical, you have a very warm intro, or you have a team that has industry gravitas. EDIT: A key lesson learned for technical founders seeking co-founders where your target market is enterprise/B2B SaaS: the best non-technical candidates don't want to take the risk in a startup (because they are already making bank with enterprise sales) and most candidates that want to do a startup probably aren't the best candidates (because otherwise, they'd be making bank doing enterprise sales for an incumbent). It's really needle in the haystack that you find the right non-technical partner that can sell into an industry and is motivated by entrepreneurship.

gregmac 2y ago
> 3) the potential customer sees a small startup team as a risk and are not willing to switch part of their process to an unproven entity. This is one where having an open-source core helps a ton. In my role I'm often the one finding these and being a major influence in pushing for or against them, and one of the key things that pushes me away is having no exit path in case the company goes under, pivots or otherwise discontinues the product. If it's part part of our product or the delivery pipeline this is a critical factor, and sadly, I've said "no" to a lot of promising products for this reason alone. I've been burned before by this, and having to drop everything the team is doing to re-build something outside our control is not good for anybody -- it looks bad on me if I chose the thing, it makes all the developers irritated they have to shift focus, it causes chaos to PMs and their schedules, and it infuriates sales and everyone up the chain from there. Should be obvious, but: the more value the service provides, the more we're willing to pay, but also by its nature the more ingrained it is and thus more important there's an exit path.

devmor 2y ago

> If you don’t know how your product will be adopted, how would your customers know? I feel like this is both correct and incorrect at the same time, possibly because it’s almost a catch-22. With any online product at all, not just SaaS, the way your customers use your product may end up entirely different than how you planned your product to work. Of course, it’s important to have a direction to begin with, but I feel like analyzing how your customers use your tools and adjusting rapidly to that instead of sticking to what you wanted to build in the first place is what makes or breaks a lot of startups. Take that with a grain of salt though, I’ve still never launched a product with an ROI greater than the value of the time I put into it.

colmanhumphrey 2y ago
oh that's an interesting perspective. I would say you're right, and maybe I didn't phrase it well. I probably should have said something more like: if you don't know how, or if you can't learn how (through iteration etc), then how can your customers. Or something to that effect.

xnorswap 2y ago

Watching the demo, it doesn't look like the kind of product that's really usable for anyone who doesn't know SQL. If you need to know SQL to fully appreciate the tool, you're not going to want the tool.

indulona 2y ago
yeah, the description of the product itself makes very little sense, let alone on a business level. but we learn by doing and we learn only by failing, so this will look great on their resumes for future jobs and give them priceless knowledge for their future startups. although i would argue that this american degeneration of business, where every paper company is a startup, and every startup needs investors to make the product or service, must die, so that we can have actually viable products and not waste developer hours on nonsense.
nicerob2010 2y ago
Yeah, I was expecting a low-code/no-code way to build queries in a GUI and wondering why any company wouldn't jump at that (at least based on my own experience). Instead, I feel like this is a really nice SQL "IDE"

tyrw 2y ago

> Large companies didn’t want it enough to deal with our lack of “big company features” (enterprise SSO, compliance certifications... > We spent a bunch of time on multi-tenant infrastructure... I'm in a position where I talk to SaaS businesses all day about both of these. Probably over 1,000 at this point. We help a lot of these companies add the enterprise features they need, but it's often a shame to hear they're just going to do standard login or build multi-tenancy themselves. Trying to sell to enterprises without meeting them where they are on login & compliance is asking for failure. I think a lot of founders and early employees are true believers in their value prop, and in this case it blinds them to the fact that there are people in the world like enterprise CSOs who simply don't care and will shut down a product for any number of security reasons. You have to check the boxes, and figuring out what those boxes are on the fly is painful and costly.

thenobsta 2y ago
I'd love to hear more insights about on this. I'm just kicking off a B2B SaaS, have a rough idea of the checklist in my head, and am trying to balance core tech development with box checking.
- louthy 2y ago
  GDPR & ISO27001 compliance are the important ones, but depending on the industry there maybe others (HIPAA for example). You need to hire an advisor and start writing everything down. Being able to hand over compliance documentation along with proof of an audit is absolute gold. If you don’t do this, be prepared for a mini-audit on every sale (if you get that far). Sales to governments will likely come with even more compliance requirements, national security audits, and potentially staff vetting. It’s not worth it early on unless you’re really well funded. Compliance does actually scale with the business, so it’s not particularly onerous at the start. Although it can get out of hand if you’re not careful. Compliance should be pragmatic. SSO is clearly one of the major factors for integrating anything into an enterprise organisation. Their IT team will want to have complete control over who has access, when somebody leaves the company they want to make sure that they can shut them down immediately, not have to reach out to third-party providers, or login to multiple systems. Ignore this at your peril. Independent penetration tests are also really important. You can usually resist requests for self-hosting or multi-tenancy if you have all the above, but not always. If they don’t think you’ll be around tomorrow, then they won’t touch you.

tschellenbach 2y ago

Failing is normal, good that you gave it a shot and learned.

drdrek 2y ago

With a lot of assumptions I would wager that it was indeed the founder skill set issue. Doing B2B sales is a skill, doing B2B marketing is a skill, doing fundraising is a skill, managing R&D is a skill, customer relations, legal, compliance, etc. You can learn anything, but you cant learn everything. If he had two founders, one from a sales background and one from R&D management while he was the product guy, I would wager his story would be different.

hintymad 2y ago

> Slacking around SQL snippets, schlepping around CSVs, devs having minor inconsistencies when running a bunch of ad-hoc queries: problems for sure, but not major ones for a small company. This is a general theme: it is hard to fight "good enough". Even in a big-enough company, a competent engineer will have a good enough way to manage queries, while incompetent ones won't care. In the end, very few people will want to pay for such service, or even want to learn such service.

colmanhumphrey 2y ago
This rings true, and I guess further backs up how important it is to carefully choose your initial customers, so the product is actually good enough by the time it gets to the broader swathe of companies. At least, that's my guess — I'm the one that failed after all!

acyou 2y ago

We shouldn't forget the history of SQL. I wasn't there, but my impression has been that it was originally written so that non-technical users (business decision makers) could write queries and have access to data in order to make business decisions. The data accessibility feature is ostensibly already built into the language. I think this original vision never ended up working out. I believe that business decision maker brains are not the same as SQL query writing brains. You need to be able to choose some facts, ignore the rest and persuade people. So this product adds (added) a middle layer in between the end user and the database. Either the user could learn this, or they could just learn SQL. But if the end users really care about what the data shows, they might as well just learn to write SQL queries, they aren't that hard. The reality is that end user business decision makers may not care that much about the SQL query output from data sets that may have a whole series of built in errors and biases anyways. I think business decision makers want to make decisions based on gut feel. In bigger companies and publicly traded companies, they then pay data analysts to produce data analyses that support those decisions, to CYA. In order to accomplish that, you don't need this tool, you just need vanilla SQL. The successful (LLM) tool would essentially have the business decision maker write a prompt that says: "I want to do X. Write me a report using this dataset that supports my decision". Yes?

dvt 2y ago

Man, I do really miss these postmortems on HN. We used to see several a month back when the site was more startup-focused. Great read! Don't want to dogpile with criticism, I'd just suggest brushing yourself off and trying again (heck, after multiple failures, I still am!).

pmarreck 2y ago

A fantastic idea that didn't find interested clients first, instead of after it was built. Could they have potentially avoided this by building a PoC and shopping that around with an NDA to gauge receptivity?

briandear 2y ago

The company didn’t die because they didn’t raise money. They died because they weren’t making money. The SV idea of a company needs to raise money in order to survive is a bit strange to me. If you’re building software, people should pay to use it. If they don’t, then fundraising is irrelevant. In other words, raising money should be for scaling and growth, not figuring shit out.

sirspacey 2y ago

This is such an excellent reflection, especially the iterative nature. “Yes but” is now a part of my toolkit to help me authentically unpack all the justifications that come to mind & convert them into learning. I’ve lead B2B SaaS revenue efforts a number of times. You correctly identified all the things that are hard and how customer size is a major factor in choosing what to build and how to sell. My general recommendation for a tool like yours is to sell to the professional who would use it in a “b2b2c” format like Slack. First win the champion, then the market they live in. Excited to see what you choose next!

colmanhumphrey 2y ago
a very generous comment! Very interesting you say that, I believe we did at some point have some thoughts about targeting B2B2C, but sadly that was one of the areas we failed to fully learn about / experiment / iterate on.

ipnon 2y ago

Corporations are really good at paying people just enough money to fix problems in a suboptimal way. Actually I think that’s what they optimize for. Past a certain size they minimize costs for the “just barely good enough” solution in a microeconomic way. So if you’re selling to corporations it’s best to get down to brass tacks. Show them proof of how spending $DOLLAR_AMOUNT with you each month is going to practically guarantee them saving `$DOLLAR_AMOUNT * (1 + $MARGIN)` on their accounting books. That’s a much higher bar than “it looks cool and makes employees happy,” but the nature of business is that no C-suite could ever turn down such an offer.

trash_cat 2y ago

> "Building a solution isn’t enough – it needs an obvious path forward" This is called implementation. You basically have people who work full time just on implementation plans and executions of it.

bitbasher 2y ago

They fell for the classic, "build a product and then find customers" strategy. It's the quickest way to burn 1-2 years. I have a saas product that I have been running for several years by myself and I would consider it quite successful. The "strategy" I used (if you can call it that) was almost the exact opposite. I witnessed customers paying services for a product. I looked at the product and thought, "Huh, I could do that and charge half as much" and then (the most important part), I did it.

colmanhumphrey 2y ago
That sounds like a very viable and valuable type of business, but it's kind of a different category of business model