Why Slight Failed: A Slight Post-Mortem(colmanhumphrey.com)
colmanhumphrey.com
Why Slight Failed: A Slight Post-Mortem
https://www.colmanhumphrey.com/posts/why-slight-failed/
76 comments
> 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.
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.
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.
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
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.
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.
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.)
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.
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.
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.
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.
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.
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.
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.
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).
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).
> 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.
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.
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.
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].
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].
It's a pretty big adverse selection issue, it's kind of unknowable in general.
> 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.
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.
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.
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.
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.
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.
> 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.
> 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.
"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.
Depends on the app and the context. A lot of apps need multi-tenant access control but not necessarily separate containers etc. In those cases, "adding" multi-tenancy means maintaining an Organizations table, a Roles table, and a table to map them to Users.
Maybe it's just different worlds, but in my world people wouldn't consider an app using isolation via containers etc "multi-tenancy". It would be a single-tenancy application. But I guess there are are hybrids these days with such granular database options in the cloud etc.
Question about multi-tenancy - do you recommend starting with a single-tenant approach, or are there off-the-shelf options for multi-tenancy that you'd recommend using, instead of building it from scratch?
We build a system that is multi-tenant capable but can run as single tenant until you need it. Happy to chat if helpful
Not sure how to DM on here, but I just checked your landing and wanted to ask in what ways you're better than clerk.dev?
Clerk is great for new builds in the react ecosystem. We focus on more complex use cases where there are multiple user types (e.g. freemium, enterprise, partner, internal), multiple applications, or both. Having everything in one system removes a lot of tech debt and helps teams move faster.
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!
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'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.
GDPR & ISO27001 compliance are the important ones, but depending on the industry there maybe others (HIPAA for example). You need to hire an advisor and start writing everything down. Being able to hand over compliance documentation along with proof of an audit is absolute gold. If you don’t do this, be prepared for a mini-audit on every sale (if you get that far).
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.
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.
> If you don’t do this, be prepared for a mini-audit on every sale (if you get that far).
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.
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.
It never stops, but at least with evidence of audits, evidence of pen tests, and policy documentation, it can be a little easier!
Edit: meant to say self-host/single-tenant in the last paragraph.
Sorry I got busy today (more convos!). I'd be happy to chat or email and try to be helpful -- if you want you can check my bio.
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.
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.
A really level-headed take on what must have been a very tough experience.
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."
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."
Had to look it up! I won't link the youtube but it is from ST:TNG s02e21 "Peak Performance"
"Sometimes you eat the bar, and sometimes the bar, well, he eats you."
Man, I do really miss these postmortems on HN. We used to see several a month back when the site was more startup-focused. Great read! Don't want to dogpile with criticism, I'd just suggest brushing yourself off and trying again (heck, after multiple failures, I still am!).
Watching 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"
yeah, the description of the product itself makes very little sense, let alone on a business level.
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.
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.
I chatted with Colman years ago when Slight was around about joining forces and I was really impressed by his character and intelligence. It didn't work out between us for unrelated reasons. And then later on they shut Slight down as described here. But failure is such a good learning experience. If he ever starts something again I would definitely recommend folks to follow/join it.
Yes I always think of this stat I read where the average successful business owner is currently working on their 7th business venture. The implication is then if you want a successful company you should speedrun 6 duds.
With a lot of assumptions I would wager that it was indeed the founder skill set issue.
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.
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.
> If you don’t know how your product will be adopted, how would your customers know?
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.
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.
oh that's an interesting perspective. I would say you're right, and maybe I didn't phrase it well. I probably should have said something more like: if you don't know how, or if you can't learn how (through iteration etc), then how can your customers. Or something to that effect.
This is such an excellent reflection, especially the iterative nature.
“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!
“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!
a very generous comment! Very interesting you say that, I believe we did at some point have some thoughts about targeting B2B2C, but sadly that was one of the areas we failed to fully learn about / experiment / iterate on.
We shouldn't forget the history of SQL. I wasn't there, but my impression has been that it was originally written so that non-technical users (business decision makers) could write queries and have access to data in order to make business decisions. The data accessibility feature is ostensibly already built into the language. I think this original vision never ended up working out. I believe that business decision maker brains are not the same as SQL query writing brains. You need to be able to choose some facts, ignore the rest and persuade people.
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?
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?
The 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.
Didn't see you mention Retool. I'd think if a company was aware of Retool, they'd always pick that over Slight.
I am surprised to hear you say this given your previous experience founding a product that from a distance might look to cover some similar space to retool but in practice is quite different. My perspective: only investors ever asked us about retool, not customers. Some of them even used retool tool. Hah even just typing this out brings me back to investor meetings!
Corporations are really good at paying people just enough money to fix problems in a suboptimal way. Actually I think that’s what they optimize for. Past a certain size they minimize costs for the “just barely good enough” solution in a microeconomic way. So if you’re selling to corporations it’s best to get down to brass tacks. Show them proof of how spending $DOLLAR_AMOUNT with you each month is going to practically guarantee them saving `$DOLLAR_AMOUNT * (1 + $MARGIN)` on their accounting books. That’s a much higher bar than “it looks cool and makes employees happy,” but the nature of business is that no C-suite could ever turn down such an offer.
They fell for the classic, "build a product and then find customers" strategy. It's the quickest way to burn 1-2 years.
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.
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.
That sounds like a very viable and valuable type of business, but it's kind of a different category of business model
> Slacking around SQL snippets, schlepping around CSVs, devs having minor inconsistencies when running a bunch of ad-hoc queries: problems for sure, but not major ones for a small company.
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 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 rings true, and I guess further backs up how important it is to carefully choose your initial customers, so the product is actually good enough by the time it gets to the broader swathe of companies. At least, that's my guess — I'm the one that failed after all!
> "Building a solution isn’t enough – it needs an obvious path forward"
This is called implementation. You basically have people who work full time just on implementation plans and executions of it.
This is called implementation. You basically have people who work full time just on implementation plans and executions of it.
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?
Could they have potentially avoided this by building a PoC and shopping that around with an NDA to gauge receptivity?
Failing is normal, good that you gave it a shot and learned.
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 find them when I need them.
At least "Foowazzle" would be easy to search for...
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...
In all our automated emails, we put something like "As a reminder,[name of company] is a ..."
That's better than most but it only solves half of my problem.
haha, not sure I agree with this one at all, I think a name is pretty far down the list of priorities for a business. I would be extremely surprised if "customers who started trials but then didn't use the product at all, but then later wanted to, but couldn't because they couldn't find the name" is a segment that moves the needle.
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!
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!
[deleted]
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:
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.