>I perfectly understand the rationale behind the pricing model. The point is that "only large enterprises need or care about SSO" is completely wrong-headed and detrimental to the overall security posture of any business customer. That is and should be unacceptable.
I made this comment the last time the SSO Tax question came up: We routinely deploy our platform to large customers for 6 or 7 figure contracts.
The number of them who actually deployed SSO (without just asking if we comply with it) is less than 20%.
FWIW, I've mentioned elsewhere in the thread, but I'm in healthcare. SSO (and MFA) have only really become hot topics in the past 5 years or so.
In the past? People with enough weight would absolutely blow right past implementing SSO if it was slowing them down or adding to their cost.
These days it's a hard requirement for us: if it's not SSO it doesn't go into the environment. That's becoming the norm across the industry.
This is one of those very, very rare cases where healthcare is probably ahead of the curve relative to a lot of other industries. Consequence of being highly targeted by attacks and insurers starting to get very particular about how the ship is run.
We routinely sell mostly to large enterprises. Yes, its not proportionally more difficult than selling to SMEs.
However the problem with enterprise accounts are:
1. They hijack your roadmap. You go into danger of building one-off features and bespoke software
2. Your risk is concentrated into fewer accounts. When you lose an enterprise customer you risk disrupting your cashflow and quarterly targets
3. If you dont yet have product market fit it becomes more difficult to achieve it (related to point 1)
There's also the element of what I call "structural corruption". This isn't "money in brown paper bags" style corruption, as much as it is key stakeholders at customers having existing relationships with certain vendors, and having built their position at the company they work at based on being subject matter experts in that vendors tools.
Try breaking in to an established market as a new product, even if you have a distinctly better value proposition.
You will face a near impenetrable brick wall of critical customer stakeholders who are using the incumbent product and have very strong vested interests in NOT changing solution, no matter how much better your solution may be.
Another word for the corruption you speak of is friendship.
The key stakeholders and their vendors are friends. They know each other, they get along, they get the product, and like you said, they've built their clout on the know-how of people and product. To choose another vendor, is to disrupt that friendship, and its ancillary benefits, e.g., a ring of trust and a status quo.
I wrote this comment because I've been on the inside. It doesn't feel like corruption when you're in it. It feels like you're getting work done with people you like, just ignoring silly process and distractions that make you think too hard and feel weird. Seeing things differently requires an outside power to intervene, or for the few key insiders to have an ethic that forces them to question their good time and each other.
Most groups of people, not just businesses, punish ethics in pursuit of collective self-interest. That is indeed corruption but it exists so systemically and so personally that I would first call it human nature.
> The key stakeholders and their vendors are friends. They know each other, they get along, they get the product, and like you said, they've built their clout on the know-how of people and product.
It's not even a friendship in many cases: This is how CEOs fail upwards, after all. It's better to take on a CEO/vendor with a known incompetence level than take a risk on an unknown.
Look at it from this point of view: you're the customer, you have an existing supplier, who frequently fucks up. Due to the frequency, you already have controls in place to mitigate the fuck ups. Do you really want to try someone new with different fuckups that will get past your existing controls?
To be clear, I 100% agree. That's why I refer to it as "structural". No individual or even group of individuals is actively doing anything corrupt, but the overall structure creates an environment where self-interested individuals create an outcome that is VERY difficult to distinguish vs the outcome you would get from more obtuse corruption.
More often than not the whippersnappers that do sales and think they have a better product we should replace, 1) don't actually have a better product and 2) assume there's no cost to migrate and re-train.
And even if your thing is 5% better at some core functionality, if it misses important integrations or security controls and will take a year to replace, it makes no sense to switch.
This may be relevant to a space with a large(r) amount of mature competitors, but I am not sure it exists in smaller (less mature) markets to the extent it impacts your ability to sell.
You need a considerable amount of internal political power to push away a new “competitor”, which generally requires time (maturity).
This is not to say it does not happen, but I think the markets where this is a key element of friction in selling possess enough capital to win-over entrenched “rent-seekers” if needed.
This is all true, but it misses one nuance, your "competitors" might not be other products/services. In an untried space they are at likely as not to be manual processes emailing spreadsheets around.
Enterprise hijacking your roadmap is undeniably true. We had an enterprise client that would regularly say "perhaps your company is not fit to support an organization of our size" whenever they didn't get the feature they wanted pushed to the top.
This is 100% true, and what’s worse is that in many cases, due to the flawed internal processes that got the customer to request the feature in the first place, it will most often be poorly considered, break all kinds of valid assumptions (ie, be hard to implement), and will often not be used. I don’t know how many features I shipped for UAT only to never get feedback, but it happened so often that I ended up making it part of my services contract that if they don’t UAT within a specific time then I get paid regardless.
And while you’re working on this useless feature, you’re distracted from your own road map, which is (hopefully) well considered and likely to lead to new clients. So it’s a triple whammy - tech debt, wasted time, restricted progress.
This is why I’m not interested in enterprise any more. I want to do quality work that helps my customers. That attitude alone makes it easier to sell to midrange clients.
Yep. Healthy businesses should have a diversified revenue stream.
The hardest thing for me in the CRO role has been getting product to understand this, which pisses them off – but if we don't, the only way to survive will be to change the roadmap at every shift in the market, which will piss them off even more!
With respect to "highjacking roadmaps", recycling a comment from a few days ago [0]...
____
> > So many vendors are focused on charging money for customer specific features or adding new features to win new tenders.
> In turn, this enterprisey anti-pattern creates unfocused products which can be configured to sort-of-solve every niche customer requirement that might block the sale.
> The result is a massive ball of muddy configurations and feature-flags, so that learning isn't very portable and backend integrations are very painful.
Well it’s possible to support enterprise features as part of your product roadmap without it being “hijacked” but this requires building an understanding with the client that they can’t get everything that they’re asking for right away, that they should be open to a back and forth when it comes to new product features.
Often the account managers have a Golden Goose attitude and don’t want to say no. But it’s possible to build healthy relationships that allow this to work.
PMF is a bit of a lie in that sense; there's no such thing as perfect fit, and sometimes we might have to solve for one or two major customers before we have enough runway to built the perfectly-focused roadmap product desires.
that's my thought. first customer: build anything they want. second customer: add everything they want, and pay attention to what they don't want. third customer: ok, now we are starting to see a pattern. see if we can satisfy them without any custom features. fourth: ok, this is our product, take it or leave it. new features only if more than half of all customers want it. fifth: by now the first customer may be the odd one out. need to find a strategy to deal with that.
I mean I hate to say this but it's the stuff they teach in CS and PMI: modularity, abstraction, loose coupling, thorough documentation, version control, and design-for-change.
It's 2023 and there's a long ton of off-the-shelf tooling that makes all of this much easier than it was ten years ago.
Modularity and abstraction come up against some limits when different customers have incompatible domain models, and thus different ideas of what your product ought to be.
not in the undergrad courses that i have taken. but that was a few decades ago when computer science covered anything related, and the degrees have diversified since then.
the problem with modularity and abstraction is that in order to make that work you need to step back and be able to build tools and frameworks that are completely independent of customer requirements.
ruby on rails is a successful example of doing that, and other frameworks that came out of some industry need. but a startup who is just getting their first customers doesn't have the resources for that, but also in my opinion are 5 customers not enough to make that move. maybe after 10, or after a few years of working you have accumulated enough experience that you are able to create something like ruby on rails that is modular and abstract enough to really be able to handle every need a potential customer might have.
(basecamp was founded 1999, RoR was released 2004. basecamp as a product came out in 2005. so it took roughly 5 years of consulting work for RoR to emerge)
#1 put my current employer through a lot of pain about a decade ago, and we're still digging ourselves out from that quagmire in a few ways. Despite that pain, I still give them a lot of credit for not prematurely optimizing and building a fully mature product before confirming market viability.
#2 you can live with if you don't let it get out of hand. Watch out for one enterprise customer dominating 80 or more % of your revenue though - monopsonists are as big jerks as monopolists are. (Monopoly = 1 seller / ∞ buyers, monopsony = ∞ sellers / 1 buyer.)
1. customer/market should never dictate product roadmap -- important to say no OR show why it's coming in next year or so
2. true for anything, there is always risk -- easier to mitigate by ensure healthy pipeline -- down-market churn is so much more rampant
3. i actually think it's opposite, you can be further away from product/market fit in enterprise as services add value outside product AND far more forgiving -- they'll give you time to sort
There's also the fact that enterprise purchasing decisions are often made on the golf course. My coworkers were lamenting that they had to deal with Oracle on a previous job and I explained it to them thus: why is Donald Trump orange? Donald Trump is orange because his buddy owns a company which makes a line of fake tan products. The products don't have to be any good; Trump uses them because his buddy makes them. His buddy gets promoted or at least attracts attention, and Trump gets someone powerful he can call in a favor from if needed. And that's how purchasing decisions for big-ticket enterprise software like Oracle get made: the head of sales of Oracle becomes buddies with our CTO on the golf course and convinces him to use the database his buddy represents. Not for any technical reasons... to help your buddy and your buddy will help you.
If you’re relatively small and you have a significant enterprise client, they have multiple ways to make your life a misery.
Are there times I wished I’d stood my ground? Yes, absolutely. But, worst case, it would have meant sacking people, and potentially a long period of time struggling while we made that revenue back.
Then there’s the reputations damage it can cause, and (at least in my case) the potential loss of referrals, and loss of a top tier referee.
> it could have been bad if it was an external ip with a machine setup by a phisherman
I.e. one of the IPs for microsoft.com belongs to $phisher, which means they control (a subset of the traffic going to) the domain. They can't add CNAME records for certificate validation, but LetsEncrypt for example offers HTTP-based validation.
Not sure how Microsoft sets up their certificate pinning, it might not be quite that easy.
For the Microsoft.com domain, proper, there seem to be no existing CAA rules, allowing each and every CA on earth to issue certificates based on whatever criteria the CA requires. What could possibly go wrong with that approach?
It might also be a highly targeted attack on someone with precious information wherein someone was able to hack a simple router and in order to get access to their actual microsoft.com account, they simply setup a phisherman's clone on the router and captured the login/password/2fa and got into the account.
EMQX has several auth modules. We use the Mnesia auth module with HTTP API client id provisioning. They also have NanoMQ, a MQTT broker for IoT edge (on resource constrained devices). The documentation is also quite decent compared to this.
Shameless plug since i'm a contributor but VerneMQ [1] is a pretty programmable one. You have options from using webhooks to writting your plugins in Lua or Erlang/Elixir.
Or equally likely he's on his way out? If there is doubt about whether a person of his stature belongs on the leadership team or not, it seems to signal that he won't be on the leadership team.
How much of OpenAI’s success can you attribute to sama’s leadership and how much to the technical achievements of those who work under him.
My understanding is that OpenAI’s biggest advantage is that they recruited and attracted the best in the field, presumably under the charter of providing AI for everyone.
Not sure that sama and gdb starting their own company in the same space will produce similar results.
Big part of it is a typical YC execution of a product/pump/hype/VC/scale cycle and ignoring every ethical rule.
If you ever stood in the hall of YC and listened to Zuck pumping the founders, you’ll understand.
I’d argue this is a useful thing to lift up a nonprofit on a path to AGI, but hardly a good way to govern a company that builds AGI/ASI technology in the long term.
But sama and gdb were largely instrumental in that recruitment.
The whole open vs closed ai thing... the fact is Pandora's box is open now, it's shown to have an outsized impact on society and 2 of the 3 founders responsible for that may be starting a new company that won't be shackled by the same type of corporate governance.
SV will happily throw as much $$ as possible in their direction. The exodus from OpenAi has already begun, and other researchers who are of the mindset that this needs to be commercialized as fast as possible while having an eye on safety will happily come on board, esp. given how much they stand to gain financially.
Who hired those people? The answer to that is either the founders or some chain of people hired by the founders. And hiring is hard. If you're good at hiring the right people and absolutely nothing else on earth, you will be better than 90% of CEOs.
My understanding from being close to but not directly connected with part of a company successfully infested by Palantir’s sales is that it’s a lot of “oh yeah our tools do everything” but then it turns out you’ll be needing to hire them for a lot of expensive development to get anything cool out of it, because it’s not actually a stand-out product that magically does all the stuff they’ll try to convince you it will.
Just another data platform, not much different from the others except better at convincing execs they are.
This seems to be the way a lot of companies are organized. They have a data analysis product that can do everything you need no matter what that is. However, their product is actually a subscription service to their company to access what amounts to a list of their consultants who then implement some custom solution, for a price, into the platform.
Wouldn't it be easier to simply hire consultants directly?
One of the most successful sales stratergies for high end products is to sell "Black Magic", that is, procducts that are too complex to explain.
eg if you are selling a "hedge fund stratergy", you tell the client it is too hard for them or they are not large enough to invest. And they will fight to be included.
Palantir works great in as much as it is primarily meant to keep Peter Thiel in the same room as government officials. The software side of the project is by all accounts a pretty generic contracting business and works about as well as any other contractor.
After Doug Lenat passed away recently I also got the impression that Cycorp has been sustained for the past four decades with that exact business model.
At the end of the day customers have a working solution, but it’s all developed and operated in a completely bespoke way each time.
Dropbox for everything except photos, videos and security-related info.
I used to keep photos and videos on an external hard disk with a jwz-style backup mechanism and Lightroom 3 for organizing it (kept the light room database file on the hard disk itself)
Now just gave up and use iCloud Photos. Not as good as Lightroom but can't find anything better that's also easy.
Secure details go into 1Password with a printout of emergency keys in a wardrobe under lock.
I used to use Evernote but moved away from it soon after they started introducing chat and a bunch of crap no one cared about.
I keep copies of often-referenced items from Dropbox in Apple Notes but the master copy is a file in Dropbox.
I'm using the Shortcuts app on the phone to take a receipt from an online payment and file it away in the /receipts folder in Dropbox.
I used to have an IFTTT integration to take all the photos I posted on Facebook and keep a copy of them in a Dropbox folder as well. It probably still works but I don't really post stuff anywhere any more.
I made this comment the last time the SSO Tax question came up: We routinely deploy our platform to large customers for 6 or 7 figure contracts. The number of them who actually deployed SSO (without just asking if we comply with it) is less than 20%.