Live data from Hacker News

Why Slight Failed: A Slight Post-Mortem

colmanhumphrey.com

11–20 of 77 posts

Re: Why Slight Failed: A Slight Post-Mortem

#11

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

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

Re: Why Slight Failed: A Slight Post-Mortem

#12

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

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

Re: Why Slight Failed: A Slight Post-Mortem

#13
post #11

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

> 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 this larger entity in case our startup failed.

(For all intents and purposes, this entity was absolute trash and ultimately ended up actively sabotaging us in some later deals because they wanted a bigger piece of the pie).

OS core is one way; maybe more prevalent in very large orgs that require MSAs is licensing through another entity that already has an MSA and putting the code into escrow with the third party.

Re: Why Slight Failed: A Slight Post-Mortem

#14

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

Don’t forget

    4) No one at the org wants to onboard a new vendor, because procurement can take 6-12 months.

Re: Why Slight Failed: A Slight Post-Mortem

#15

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

Don’t forget 4) No one at the org wants to onboard a new vendor, because procurement can take 6-12 months.

For me, that falls under one of the handful of reasons under (1).

But yes, enterprise rollouts are just a different beast for any number of reasons (contracting, legal, compliance, industry certifications, security audits, etc.)

Re: Why Slight Failed: A Slight Post-Mortem

#16
post #3

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 f…

[dead]

Re: Why Slight Failed: A Slight Post-Mortem

#17
post #12

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

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

Re: Why Slight Failed: A Slight Post-Mortem

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

Re: Why Slight Failed: A Slight Post-Mortem

#20

Earlier quoted context omitted.

Don’t forget 4) No one at the org wants to onboard a new vendor, because procurement can take 6-12 months.

For me, that falls under one of the handful of reasons under (1). But yes, enterprise rollouts are just a different beast for any number of reasons (contracting, legal, compliance, industry certifications, security audits, etc.)

Perhaps under (1) as well but especially at large enterprises you will likely deal with internal politics in the potential customer organizations. If the right person likes your offering, that can grease a lot of skids. If they don't, or your internal champion isn't well liked, you will face difficulty. This is all entirely separate from whether your product objectively meets a need the customer has.
Post reply on HN