6 ms·

> 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

> 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.
- CharlieDigital 2y ago
  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.
  - enugu 2y ago
    Is there a good way for a startup to find a vendor who has agreements with larger companies and is willing to ship the startup's product?
    - CharlieDigital 2y ago
      You can often search for press releases with big name services vendor or big name software vendor + your target customer and see if there are press releases. Many large companies work with specific partners for IT services and these providers are the ones with the MSAs that you can attach to. Examples: Cognizant, Tata, Accenture, etc. It won't be easy unless you know someone on those teams already. Sometimes if you find a customer that loves your product but cannot procure through a startup, you can ask them if they can refer you to one of their partners and see if you can work something out with them (most of the time, those partners will want an arm and a leg).
  - gregmac 2y ago
    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.
Chabsff 2y ago
> 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.
- MichaelZuo 2y ago
  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.
  - chubot 2y ago
    Yeah the way I think of it is that most big organizations are willing to burn the costs of a whole employee or a whole team to avoid adopting new/risky software As long as the cost is kinda spread out and not directly visible by management So yeah just being 20% better doesn’t mean anything, because most big orgs are much more inefficient than that anyway, almost across the board
    - hobs 2y ago
      Many people have to remember that the initial glut of SaaS sales were because they were transferring old and very broken software models into one they could charge a monthly fee on. Most younger folks wont have an experience of enterprisey stuff like remoting into a terminal server so that you could run a fat client in a shitty and slow network connection, or have the most awkward tech stack installed on your local computer. Moving to "its just a website" was way more than a 200% improvement on many things, even with the tradeoffs that javascript gave, moving people to the next level of more streamlined workflows doesn't have nearly the sales pitch.
  - cortesoft 2y ago
    Yeah... I am not sure people understand how powerful inertia is at bigger companies. It is incredibly difficult to overcome.
turnsout 2y ago
Don’t forget 4) No one at the org wants to onboard a new vendor, because procurement can take 6-12 months.
- CharlieDigital 2y ago
  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.)
  - SoftTalker 2y ago
    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.
    - CharlieDigital 2y ago
      Maybe it's own bullet. We talked to one potential customer and he told us that they had an internal team working on something similar and admitted that they were much further behind and the experience was nowhere near as good as ours. I think that's why you need really warm intros at very high levels or you need industry gravitas to pull this off without a very, very hard grind.
vosper 2y ago
> 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.
- CharlieDigital 2y ago
  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.
  - 8note 2y ago
    This sounds like a business opportunity, for selling to VCs to recommend to their startups
    - mlinhares 2y ago
      That is one of the reasons Y Combinator startups are so successful, they get recommended inside the circle of startups funded by them.
- magicalhippo 2y ago
  Besides WorkOS being stupid expensive as far as I can see, the compliance requests we get goes far beyond that. It includes our development practices, internal security, who has physical access to stuff and so on. And it's never the same, and they usually won't do any work themselves so we have to figure out how our situation maps to their 2000 custom questions.
rKarpinski 2y ago
> 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). Disagree. Those are two very different roles - the most successful enterprise AE's are specialists and most of the time aren't going to have the generalist skillset or mindset that is needed to build a business from scratch.
- danielmarkbruce 2y ago
  It's a pretty big adverse selection issue, it's kind of unknowable in general.
- CharlieDigital 2y ago
  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. The right candidate with the right mindset is very hard to find.
  - rKarpinski 2y ago
    > The right candidate with the right mindset is very hard to find. Yeah strongly agree but I also think you are looking in the wrong place. What I disagree with is the notion that the best co-founder is hard to find because they are doing well in the corporate world. Building a business is a very different problem and environment, and it requires different adaptations. The playbook of an enterprise AE is often counter productive that early; in the same way that implementing amazon/google scale tools and infra are on the technical side [that early].
marcus_holmes 2y ago
Agree completely, and I'd add that the sales cycle for a large enterprise customer can be a killer too. Generally speaking, for a large organisation, getting from a product demo to a purchase order takes two years. This can be an absolute killer for startup cashflow - you need to keep an active sales presence with the customer for that entire time, doing regular meetings and presentations, before you'll see a cent from them [0]. The advantage is that they're generally not price-sensitive, and much less willing to switch to a competitor. [0] I make this point every time I talk to a founder who plans on bootstrapping in this space, and their usual answer is that this won't take that long for them because $reason. It always takes this long.

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.

CharlieDigital 2y ago
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.
- enugu 2y ago
  Is there a good way for a startup to find a vendor who has agreements with larger companies and is willing to ship the startup's product?
  - CharlieDigital 2y ago
    You can often search for press releases with big name services vendor or big name software vendor + your target customer and see if there are press releases. Many large companies work with specific partners for IT services and these providers are the ones with the MSAs that you can attach to. Examples: Cognizant, Tata, Accenture, etc. It won't be easy unless you know someone on those teams already. Sometimes if you find a customer that loves your product but cannot procure through a startup, you can ask them if they can refer you to one of their partners and see if you can work something out with them (most of the time, those partners will want an arm and a leg).
- gregmac 2y ago
  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.

Chabsff 2y ago

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

MichaelZuo 2y ago
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.
- chubot 2y ago
  Yeah the way I think of it is that most big organizations are willing to burn the costs of a whole employee or a whole team to avoid adopting new/risky software As long as the cost is kinda spread out and not directly visible by management So yeah just being 20% better doesn’t mean anything, because most big orgs are much more inefficient than that anyway, almost across the board
  - hobs 2y ago
    Many people have to remember that the initial glut of SaaS sales were because they were transferring old and very broken software models into one they could charge a monthly fee on. Most younger folks wont have an experience of enterprisey stuff like remoting into a terminal server so that you could run a fat client in a shitty and slow network connection, or have the most awkward tech stack installed on your local computer. Moving to "its just a website" was way more than a 200% improvement on many things, even with the tradeoffs that javascript gave, moving people to the next level of more streamlined workflows doesn't have nearly the sales pitch.
- cortesoft 2y ago
  Yeah... I am not sure people understand how powerful inertia is at bigger companies. It is incredibly difficult to overcome.

turnsout 2y ago

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

CharlieDigital 2y ago
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.)
- SoftTalker 2y ago
  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.
  - CharlieDigital 2y ago
    Maybe it's own bullet. We talked to one potential customer and he told us that they had an internal team working on something similar and admitted that they were much further behind and the experience was nowhere near as good as ours. I think that's why you need really warm intros at very high levels or you need industry gravitas to pull this off without a very, very hard grind.

vosper 2y ago

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

CharlieDigital 2y ago
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.
- 8note 2y ago
  This sounds like a business opportunity, for selling to VCs to recommend to their startups
  - mlinhares 2y ago
    That is one of the reasons Y Combinator startups are so successful, they get recommended inside the circle of startups funded by them.
magicalhippo 2y ago
Besides WorkOS being stupid expensive as far as I can see, the compliance requests we get goes far beyond that. It includes our development practices, internal security, who has physical access to stuff and so on. And it's never the same, and they usually won't do any work themselves so we have to figure out how our situation maps to their 2000 custom questions.

rKarpinski 2y ago

> 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). Disagree. Those are two very different roles - the most successful enterprise AE's are specialists and most of the time aren't going to have the generalist skillset or mindset that is needed to build a business from scratch.

danielmarkbruce 2y ago
It's a pretty big adverse selection issue, it's kind of unknowable in general.
CharlieDigital 2y ago
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. The right candidate with the right mindset is very hard to find.
- rKarpinski 2y ago
  > The right candidate with the right mindset is very hard to find. Yeah strongly agree but I also think you are looking in the wrong place. What I disagree with is the notion that the best co-founder is hard to find because they are doing well in the corporate world. Building a business is a very different problem and environment, and it requires different adaptations. The playbook of an enterprise AE is often counter productive that early; in the same way that implementing amazon/google scale tools and infra are on the technical side [that early].

marcus_holmes 2y ago

Agree completely, and I'd add that the sales cycle for a large enterprise customer can be a killer too. Generally speaking, for a large organisation, getting from a product demo to a purchase order takes two years. This can be an absolute killer for startup cashflow - you need to keep an active sales presence with the customer for that entire time, doing regular meetings and presentations, before you'll see a cent from them [0]. The advantage is that they're generally not price-sensitive, and much less willing to switch to a competitor. [0] I make this point every time I talk to a founder who plans on bootstrapping in this space, and their usual answer is that this won't take that long for them because $reason. It always takes this long.