As with most of these companies, user-facing feature development is only a small part of the engineering workload.
I would assume the majority of those engineers are working on less visible tasks: Devops, build systems, infrastructure monitoring, security, backups and data integrity, internal tooling for customer support, billing and accounts management, and other critical but otherwise invisible tasks.
Duplicating the core 80% of Asana's features as a one-off product wouldn't be extraordinarily difficult. Scaling it into something that can operate as a business with hardened security, reliable data storage, consistent uptime, and reasonable internal tooling for customer service is where things get difficult.
That said, companies often go overboard with hiring in the run-up to IPOs or acquisitions. Excessive R&D spends can be fixed on the road to profitability. Restoring a company's reputation after a major data loss disaster or a security breach is much more difficult, so it's safer to err on the side of throwing too many engineers at polishing everything. If they can't scale revenues to match, expect the engineering workforce to be cut down significantly.
How many of those jobs would be required if Asana was simply sold in a shrink-wrapped box that you installed on your desktop or the downstairs server run by the corporate IT guy.
In some ways SaaS is a big win because it offloads all those tasks to a centrally hosted service. No IT guy or tower server in the corporate mail room required. OTOH not everyone has the same ops requirements. Not every customer needs 99.999% reliabilty. Or ultra-hardened HIPAA-compliant security. Or heck, even remote access outside the office LAN.
By delivering Asana as SaaS instead of shrink-wrapped software, it means the Asana hosting team has to deliver to insanely tight operational requirements to every single customer. If one customer requires 5-9s of uptime, then basically every customer requires it. That certainly explodes the cost-of-goods-sold beyond selling shrink-wrapped software.
But, still a fair good comparison of the shrink-wrapped software startups of yesteryear to today's SaaS business model. Operating systems certainly seem inherently more complex, so that should handicap things in favor of Asana. Of course, Red Hat is just re-packaging what's mostly developed by external open source contributors. But still, if we're talking about the overhead of support/services/sales, if anything that should make things harder for Red Hat.
In terms of COGS (cost of goods sold), its amazing how close the two land together. 14% or revenue at Asana and 17% at Red Hat. Since COGS includes technical support, it doesn't really seem that shrink-wrapped software is significantly more costly to support than SaaS.
For both companies sales is a major expense item. Still Red Hat's model seems to have a handy advantage. Its "only" paying 32% of revenue to sales, whereas Asana is paying a whooping 76% of revenue to sales. To be fair Asana is achieving a much faster growth rate than 2005-era Red Hat. Still, there doesn't really seem to be any clear sign that shrink-wrapped software is more expensive to sell than SaaS. At least in the enterprise space.
However with R&D costs the discrepancy's pretty clear. In 2005, Red Hat was spending 16% of revenue on this line item. Asana triples this rate by spending nearly 50% of revenue on R&D. And again, ipso facto it certainly seems like Red Hat is developing a much more complex product.
Also, with SaaS you can get access to log files, if it's installed on prem that can be heavily restricted by regulation.
Also if stuff goes wrong in the node model, the customer will blame you even if it's mostly their fault. So it's also important for brand benefits.
I agree trade-offs, but I sometimes feel the gain has not been all that great.
That's not even taking into consideration the fact that you no longer quite know what's going on in those 70K instances, which leads to extremely rigorous tests or the need for a big support team.
It would be interesting to know what costs the Jira self hosted option has put on the product for comparison to Asana's running costs.
Individual companies don't benefit from low productivity, and neither does the economy as a whole.
As a simple example, watching a movie doesn't produce anything, but it does give people joy. Similarly, eating anything tastier than the bare minimum gruel to keep you alive and healthy mostly just gives you extra joy.
Orthodox economics is perfectly fine with that. They deal in 'utility'. Fun is a perfectly fine product to deliver.
So eg gambling or playing the lottery can be perfectly rational, as long as you are aware that you are doing it for the entertainment value, and not as a financial investment.
Now for our situation: I hold that the extra work here doesn't provide any net gain in utility. Not even for people who like programming: there's enough other programming work left that's not just churn and that's not any less enjoyable.
Of course, the humble agnostic choice of orthodox economics is not the only possible one. If you are some kind of puritan or a paperclip maximizer, you'll know for a fact that producing fun is not productive. Only paperclips count (or whatever puritans optimise for).
Not to mention that they didn't have the advantage of duplicating features. Developing an application from scratch requires significant experimentation, false starts, deprecated features, associated tech debt, reinvention, etc.
Just because you can drive across the US in four days, it doesn't mean the first explorers to make the journey were lazy.
However I am not sure how much is strictly necessary.
I honestly think a small team could achieve lot more . You loose the agility of smaller team at >50 have large company problems without the benefit of sheer manpower 500-1000 typically brings.
Scaling devops is not as hard as it sounds . There are plenty of cloud native services which scale pretty well more or less out of the box( you still domain knowledge I.e. need to know that service’s unique limitations)
scaling it for cheap is harder, still not as hard as it used to be, plenty of mature tech is available today. Ironically devops engineers with modern cloud skills generally are more expensive than the ones who know how to stand a server in a DC.
A lot of startups like WhatsApp , Instagram built great products at scale with less than < 50 so it not impossible to achieve
One interesting thing to note is that as these constraints relax (business stabilizes, growth slows) the engineering teams can make better decisions in the present, clean up the decisions of the past, and reduce their overall need for people. If the company has built a money-printing machine the redundant people are then moved to new lines of business funded by the money-printer. If there's no money-printing happening, margins are super thin, and there's an incentive for the company to cut costs... where do those people go?
It is easier to solve problems by adding more people, especially when financial resources is not a constraint. However like technical debt, process and people debt will keep growing. There are some methods to have handle on it like the Spotify pod model, but no method is the magic bullet.
Every resource you add is additional cost not just on the payroll but also on the work overhead. 2x sized company will not do 2x work after all. At some point the incremental value of new resource is not worth the incremental cost.
I am not sure many startups consciously think this through while scaling up.
Yet many companies invest in it because in the end, the client is happy to pay for all your additional expenses, knowing that they can trust your service.
Kik messenger had 300M users and a tiny team. Same with WhatsApp - and it's reliable.
Asana scales more or less horizontally, meaning that they don't do anything much at the scale of all of Asanas customers. No individual customer repo should be massive (unlike say Facebook, where a user search searches the entire world.)
SaaS services with easily replicatable software live or die by building barrier to entry, usually this is done by building up a wall of feature add ons and integrations, in the case of Asana, integrate with all the things and suddenly it's a pain in the arse to replicate it all.
I would hazard a guess most the development effort is based around building up that wall of features.
The reason reminded me of when I get quoted a large price for an hours work like dentist or plumber and they are like i have insurance and car expenses ;)
Most of these other things are absolutely useless.
Billing is easy until you have to serve 200 countries, each with their own regulation and tax systems. Sure, you can outsource that but it won't be much cheaper once you reach scale (as parts remain manual).
And I don't think many would agree that customer support is useless. As a developer, I wouldn't want every customer request to hit my desk. Having customer support that cannot only filter out requests but also respond in a less technical way than most developers is invaluable.
Eg backups and data integrity sound rather important.
Eg build systems are only useful as an enabler for the other things your company wants to do, true.