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?
Why Slight Failed: A Slight Post-Mortem
41–50 of 77 posts
Re: Why Slight Failed: A Slight Post-Mortem
#42> 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…
> 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 a pretty big adverse selection issue, it's kind of unknowable in general.
Re: Why Slight Failed: A Slight Post-Mortem
#43Earlier quoted context omitted.
> 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, This cannot be overstated enough. If you are planning a B2B product, especially anything middleware-ish, not planning for this on your upfront is just begging for failure.
Yeah, there are so so many B2B products that don’t seem to realize being 10% to 20% better than the existing X in a large company is close to meaningless. In practice it has to be more like 200% better, at least, to be a viable competitor that has realistic prospects of being adopted.
There is a reason even smart folks throw around "10x on some valuable dimension" as some kind of rule of thumb. It's not a bad rule.
Re: Why Slight Failed: A Slight Post-Mortem
#44> 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…
"build multi-tenancy themselves".... this is a weird thing to say. In the modern day, what product company builds single-tenancy..? Even if a customer explicitly wants it, you can make multi into single easily. The other way around is difficult.
Re: Why Slight Failed: A Slight Post-Mortem
#45Earlier quoted context omitted.
> 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…
In some cases, an alternate option is to put the code into escrow. At one of the bootstrapped startups I was a principal at, a very large enterprise customer stipulated that we had to work with a much larger entity (with which they already had an MSA) and technically, the software was licensed and delivered through the entity (who ended up getting the support contract in exchange). The code was put into escrow with t…
I worked at a startup where our software was in escrow, and we had a couple clients signed onto it. I've never been on the other end, though.
I can see a few problems with this. In the case of an MSA taking over, it doesn't necessarily satisfy the exit plan requirement, because as you say in another reply they could charge an arm and a leg. 10x'ing the price overnight isn't really much different from it shutting down.
The other issue: I am a developer and architect, I want to primarily design systems and write code and make stuff. Know what I definitely don't want to do? Sit in meetings and talk about escrow agreements with C-level people, lawyers and sales reps. If there are two startup products we could use, one is exact-fit amazing but needs an escrow arrangement, and the other is OS core but will need dev effort -- I'd 100% rather spend my time doing the dev work.
Re: Why Slight Failed: A Slight Post-Mortem
#46Watching 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.
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"
Re: Why Slight Failed: A Slight Post-Mortem
#47The 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.
Re: Why Slight Failed: A Slight Post-Mortem
#48> 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…
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.
If you are going after enterprise early, I highly recommend putting them on their own system instead of in a multi-tenant system.
Enterprise wants 30 days of immutable db backups?
They need to be able to rollback within X time?
They want guarantees that other people won’t affect them?
This all becomes easier if you turn it from an engineering problem to an operations problem. Enterprise really cares about how you operate in order to guarantee they won’t be negatively impacted by your system. SOC2 is much more about your operations than anything else.
My recommendation: have a multi-tenant system for the plebs and bespoke deployments for the enterprise. Save yourself the headache of trying to satisfy both with the same infrastructure.
Re: Why Slight Failed: A Slight Post-Mortem
#49> 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…
> 1) legal/compliance/IT team gets involved and kills it for a handful of common reasons What are the common reasons and why can't they be dealt with? There are platforms like WorkOS that (supposedly) make it easy to do compliance stuff.
Depending on the industry, once legal and compliance get involved, you can face a number of obstacles. Regulatory compliance like HIPAA, SOC2 is a common one (most small startups I've seen can bullshit their way around this for a bit); many early stage startups won't have this in place since it requires a not-insignificant investment in time and money.
Some industries like life sciences will request external/3rd party audits of your system and system validation documentation (documented formal testing, check out "GAMP5 V-Model" if you're curious). Life sciences also wants to see your validated QA system, your employee training records, your internal SOPs, etc.
IT teams may want 3rd party security audits, attestations of data residency (EU companies especially), your policies around privacy and process level security (again, dependent on industry and teams). Some will stonewall you by demanding specific integrations (e.g. SAML-based SSO, SCIM, etc.) that are just too early in many cases.
Sometimes the purchasing team will ask about your funding because they want to know how much runway you have and whether you'll be around 6 months from now.
Re: Why Slight Failed: A Slight Post-Mortem
#50> 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…
> 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…
That's more or less what I wrote in my last sentence, right? (that you left off...)
> 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.