Why Slight Failed: A Slight Post-Mortem
colmanhumphrey.com
colmanhumphrey.com
> Distribution
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.
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.
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.
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.
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 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.
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.
In practice it has to be more like 200% better, at least, to be a viable competitor that has realistic prospects of being adopted.
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
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.
4) No one at the org wants to onboard a new vendor, because procurement can take 6-12 months.But yes, enterprise rollouts are just a different beast for any number of reasons (contracting, legal, compliance, industry certifications, security audits, etc.)
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.
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.
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.
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.
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.
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 really needle in the haystack that you find the right non-technical partner that can sell into an industry and is motivated by entrepreneurship.
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].
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.
> 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.
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.
That's the position we're in, though as an older but still growing B2B we have to do this for existing customers as well.
We're in the process of getting ISO27001, meanwhile we got one guy out of 40ish almost full-time answering such questions now.
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.
And by "happy to chat" I meant by my email in my bio (which I just added to the public part), if it'd be helpful!
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."
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.
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.
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.
“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!
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?
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.
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.
This is called implementation. You basically have people who work full time just on implementation plans and executions of it.
Could they have potentially avoided this by building a PoC and shopping that around with an NDA to gauge receptivity?
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...
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!