pythko

I think you and the parent comment are talking about different scales. A large SaaS company deal could be $300k per month per customer, and the sales process for a company like that can involve changing the software to meet the needs of the customer. A very early lesson is that what the customer says they need is not always the same as what they actually need.

One of the many reasons calls happen is that customers say "I need XYZ feature in order to do this deal," and the salesperson then needs to ask why they need XYZ feature, and what they want to accomplish, and maybe existing ABC feature actually meets their need, or maybe the company needs to develop XYZ feature to secure the contract. Once you get into a complex domain, that is not happening over email.

The article contains good advice to many businesses out there, but it's worth considering the situations where it doesn't apply, too.

I really like this idea, and would love to subscribe when you’re ready!

I think many commenters have pointed out reasons why this model is not suited to widespread user adoption, but I just want to say that may not be a bad thing. Meme content moderation is not a big problem if your users are not the type to submit or upvote a lot of low effort memes in the first place. A paywall will inherently limit your user growth, but if the users you get end up being people who are happy to create and support high quality content, that seems pretty ideal to me (unless you are looking for maximal growth, VC level returns, and/or an IPO).

If there’s a mailing list or other way to get notified when you’re ready to do a full launch, I’d love to sign up for that!

I agree; I’ve had multiple instances recently of booking through a third party where getting changes or refunds is very slow and clunky, if they will even do it at all. Contrast that to my experience with booking a hotel directly through their website, where I mistakenly booked the wrong dates. One phone call to the hotel and 2 minutes later they changed it with no hassle.

It’s free to end consumer, but these schemes make money by charging a percentage to merchants. And those merchants will compensate by bumping up their prices a little to cover the transaction costs.

In the best case, these are pointless services that only transfer money to the finance industry. In the worst case, they incentivize people to spend money on things they can’t afford (and also transfer money to the finance industry).

You seem to be the lucky lightning rod comment on this!

I guess it's fitting that the tech world gets particularly up in arms about this; we're certainly a group who enjoys demanding standardization while refusing to change our own practices.

(But also, if you're not using ISO 8601 in a code context, what are you doing?)

I've settled on the explanation that this is just a cultural difference, and anyone arguing from a place of "logic" or "correctness" is refusing to accept that it's all convention, and different people do things differently.

As an analogy, some languages put the verb at the end of the sentence (e.g. Latin, certain German grammatical structures). As an English speaker, this is weird because I don't really know what's going on until the sentence is done, and it feels like I'm putting together a little puzzle in my head. Whereas to a fluent speaker, it presumably just makes sense and you don't really find it difficult. Same thing with dates.

As an American, I like our convention for writing dates. I usually care about month first. Immediately upon seeing a date, I know the rough time frame. Is it this month? Next month? Around Christmas? Around my birthday? Then the day pins it down to something specific. I will assume a date is referring to the current year, unless I see a different year, in which case it's a quick update to my mental model. April 12 flows as "soon, and exactly 18 days away" and September 12 flows "far away, and the middle part of the month".

I get that computers are a different use case, and there I'm a ISO 8601 advocate.

Executive summaries are part of the industry, where people boil down non-fiction books into short pieces of text. E.g. Blinkist (not affiliated, just the first result on Google)

It is somewhat funny that presumably a good amount of work goes into padding the book, and then work goes in on the other side to strip the padding away.

In a hospital setting, nurses and doctors round regularly. No one is talking about using AI as a replacement for that, because no one has anything approaching that much trust in predictive models.

Predictive models are most often used as either an alerting mechanism or an additional data point on a dashboard. You need to careful of alert fatigue, where too many false positives cause humans to disregard all alerts from the model. And if you don’t get people ignoring alerts, you can waste a lot of people’s time and energy by having constantly having them run to check on someone who is actually fine.

I think what you described falls under #2 in my reply. “Doing it well” is not a trivial option that people are ignoring; “doing it well” is the thing people are trying to solve. AI is not a magic bullet that always makes everything better.

I can tell you that the current focuses of AI implementations are around real, impactful issues: sepsis risk, readmission risk, deterioration index, etc.

The problems with AI in healthcare are:

1) People don’t want it to be a black box - that means quantifying the factors that go into a recommendation

2) Operationalizing AI recommendations is hard. AI tends to give gradiated information on binary decisions (e.g. there’s a 68% chance this patient is septic. Should someone go check on them? What if they were 49%?). The challenge becomes deciding how that information should be shown to people and what the acceptable false positive and false negative rate are.

3) The same problems of AI everywhere. Things like garbage in garbage out, unrealistic user expectations, feeling like it basically tells you what you already know, the challenge of getting insight from a pile of data.

They are finally reaching the point of rolling out their new clients that get off Visual Basic, so that’s something.

M, however, ends up being a combined database/business logic platform (and it’s fairly speedy at that, if that’s what you want). Extracting data into a nice tidy relational database does take time and development effort, though, but they have a reasonably robust process for this already.

This article seems to be a relatively mundane announcement to me. You could already do this same stuff with Epic on Azure, but I guess more options are nice.

I don’t think Epic’s install costs are secret or a “gotcha”. Any administrator interested in Epic can look at 20 years of installs and see that an Epic implementation is routinely a multi year, $100 million+ project for large organizations.

I’m also not sure what these “Epic Engineers” you’re referring to are, but I know that IT staffing is a conversation that happens early on in the sales process and it is not a surprise to anyone who’s looked around at existing Epic sites.

Whatever Epic’s flaws may be, I don’t think “public boondoggle” is a fair portrayal of how they do business.

Some college guys I know rode 200 miles around essentially a big roundabout (the loop length was probably less than 300 meters) at 20mph. When asked why they did it, they basically just shrugged and said they thought it would be a cool challenge. And I guess it was.