[HN Gopher] Why Slight Failed: A Slight Post-Mortem
___________________________________________________________________
Why Slight Failed: A Slight Post-Mortem
Author : KraftyOne
Score : 118 points
Date : 2024-10-28 22:31 UTC (1 days ago)
(HTM) web link (www.colmanhumphrey.com)
(TXT) w3m dump (www.colmanhumphrey.com)
| mritchie712 wrote:
| Didn't see you mention Retool. I'd think if a company was aware
| of Retool, they'd always pick that over Slight.
| andybak wrote:
| 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...
| mritchie712 wrote:
| In all our automated emails, we put something like "As a
| reminder,[name of company] is a ..."
| andybak wrote:
| That's better than most but it only solves half of my
| problem.
| eatonphil wrote:
| 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.
| dccoolgai wrote:
| 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."
| moffkalast wrote:
| "Sometimes you eat the bar, and sometimes the bar, well, he
| eats you."
| pmarreck wrote:
| Had to look it up! I won't link the youtube but it is from
| ST:TNG s02e21 "Peak Performance"
| CharlieDigital wrote:
| > 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 wrote:
| > 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| > 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| Yeah... I am not sure people understand how powerful
| inertia is at bigger companies. It is incredibly difficult
| to overcome.
| danielmarkbruce wrote:
| 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.
| turnsout wrote:
| Don't forget 4) No one at the org wants to
| onboard a new vendor, because procurement can take 6-12 months.
| CharlieDigital wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| > 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 wrote:
| 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.
| magicalhippo wrote:
| 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 wrote:
| > 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 wrote:
| It's a pretty big adverse selection issue, it's kind of
| unknowable in general.
| CharlieDigital wrote:
| 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 wrote:
| > 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].
| devmor wrote:
| > 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.
| xnorswap wrote:
| 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.
| indulona wrote:
| 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.
| nicerob2010 wrote:
| 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"
| tyrw wrote:
| > 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.
| thenobsta wrote:
| 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.
| louthy wrote:
| 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.
| jprokay13 wrote:
| 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.
| DylanSp wrote:
| 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?
| danielmarkbruce wrote:
| "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.
| tschellenbach wrote:
| Failing is normal, good that you gave it a shot and learned.
| drdrek wrote:
| 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.
| hintymad wrote:
| > 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.
| acyou wrote:
| 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?
| dvt wrote:
| 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!).
| pmarreck wrote:
| 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?
| briandear wrote:
| 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.
| sirspacey wrote:
| 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!
___________________________________________________________________
(page generated 2024-10-29 23:00 UTC)