Hacker News Reader

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

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

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.

Yeah... I am not sure people understand how powerful inertia is at bigger companies. It is incredibly difficult to overcome.

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.

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.

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.

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.

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

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.

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?

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

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.

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

It's a pretty big adverse selection issue, it's kind of unknowable in general.

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.

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

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

This sounds like a business opportunity, for selling to VCs to recommend to their startups

That is one of the reasons Y Combinator startups are so successful, they get recommended inside the circle of startups funded by them.

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.

Or you quit excusing your half assed practices, put on your big boy pants and do the work to get ISO270001 certification

We're on our way but it's a lot to do, especially as a more mature company.

If you're a startup, it might be beneficial to study ISO27001 early on, so you avoid relying on things which are difficult under ISO27001.

Anyway, my point was that just relying on WorkOS won't help that much in answering the security questionaires.