Wow, this is a torrent of IPOs today. Investors / boards are wanting to get money out before things turn south I feel.
Aside from that, I'm surprised how much it costs Asana on engineering R&D, for essentially a ticket management system. How does a team grow to ~300+ developers ($89M R&D) to figure out how to attach PDFs and videos to tickets, and email people when there's a change in status? (ok yes I'm oversimplifying a bit, but not that much)
And (as with all such companies) how much they need to pour into Marketing/Sales to sell this thing. These above costs basically wipe out the gross profits by 2x.
> How does a team grow to ~300+ developers ($89M R&D) to figure out how to attach PDFs and videos to tickets, and email people when there's a change in status?
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.
This makes a lot of sense. But in some ways it shows the downsides of the modern obsession with SaaS.
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.
If it was shrink wrapped software they would need a bigger sales team, a bigger support team, a bigger professional services team, etc. It’s just trade offs.
That's a really interesting point, and it piqued my curiosity. I decided a pretty fair comparison was Red Hat at the time of its 2005 IPO.[1] Its annual revenue for FY2005 was $278 million, so adjusted for inflation, a little smaller than Asana. (I'm annualizing the last reported quarter for Asana, because of its meteoric growth rate.)
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.
I've been involved in debugging a bug in a software that occurred on Kubernetes cluster at the client site but couldn't be reproduced locally. Reproducing that is so much harder than a similar software installation. You have so many moving parts that it's pretty much impossible to create a test cluster with the same properties.
Also, with SaaS you can get access to log files, if it's installed on prem that can be heavily restricted by regulation.
The point is, Asana has 300 people, but with a SaaS model, their clients need less IT staff than with an in-house server. If Asana has 10,000 customers, they’ve just reduced IT personnel costs across the industry with 300 Asana employees, which is almost guaranteed to be a net cost reduction for the industry.
One of the subtle things about SaaS is far less "up-front" costs or fixed costs. This helps sell to business around the lines of pay-as-you-grow rather than commit to x years of SLAs. Shrink-wrapping software takes away this key sales lever and leads to longer sales cycle which might be part of the reason why SaaS models are so attractive.
Good luck now having to build and maintain software that needs to reliably and correctly update itself on +70K instances not under your control.
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.
I think at least a segment of (an, The?) economy grows from some kinds of unproductive churning. Maybe it depends how you define productive. I'd argue that gambling or gaming are not productive even though they are lucrative for some and fun for many.
Well, now we are getting into philosophical territory.
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).
> Duplicating the core 80% of Asana's features as a one-off product wouldn't be extraordinarily difficult
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.
This is common reason cited . I don’t disagree as such, as my own product grows I see it happening .
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
A major reason why engineering teams at these sorts of companies grow so large is because of how quickly the business operates and the company's rate of growth. These factors put the engineering team in a position where they're constantly having to choose the faster, easier option in the present despite the fact that it will produce a lot more work for the team in future. When the future rolls around they're still under the same constraints so they hire more people to deal with the problems caused by their past decisions while making the same kinds of decisions in the present. Rinse and repeat for several years as the company grows into a behemoth before going public.
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?
I wouldn't say 'unnecessary' as such, adding people is one way to solve problems just not the only way
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.
A lot of internal tools is overengineered bullshit... if that’s what they are spending it on (doubtful though - it’s probably mostly some form of sales).
For most companies I've seen, enterprise sales is what costs most money. It's worth it in the end but there's nothing you can automate around all the calls, forms and processes you have to go through to get a big enterprise client.
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.
Also keep in mind the old wisdom that the safest way to delay a project is to throw more engineers at it. Hiring engineers breeds hiring more engineers.
To give you an idea how many engineers are actually needed, Instagram hat 13 engineers when they were acquired, WhatsApp had 60. And that was 8 or 6 years ago respectively.
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.)
Messenger services live or die by network effects.
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.
Yes I agree. But my point with the Messengers is that it's not really 'scale' so much. Or dev ops. It's more likely the 'wall of features' and perception in business as being the Gartner 'Magic Quadrant' leader etc..
a technology company’s operational work is larger than its development is a bad signal.
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 ;)
>> 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.
Most of these other things are absolutely useless.
Companies saving money on backups pay for it at some later date. Also, you won't/shouldn't really pass any audit without sound processes in place.
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.
There's always a comment here on HN wondering why company X has so many engineers for such a seemingly simple product.
The answer is, unsurprisingly, not that they're terribly inefficient. Rather it's that running a popular service at scale is hard, the long tail of features is really a long tail, and a lot of effort goes into even simple things because small differences really add up when multiplied by large N.
This is a big part of it, but I wouldn’t downplay the inefficiency too much. A pattern I’ve personally seen:
* Small team of 5 devs and maybe 1 manager working on some large area of the product is very efficient
* Startup is growing users/revenue very fast, attracts big VC investment
* Major hiring, a year or two later that same area of the product has 30 devs, 5 product managers, 5 dev managers, 3 designers, a manager of the dev managers, a manager of the product managers/designers, and a manager of the dev and product managers
* There’s too many cooks in the kitchen, nobody feels empowered to make decisions, meetings multiply like crazy, every decision takes exponentially longer to make than before
* Instead of planning 1 sprint ahead, you start doing quarterly plans, 3 year visions, customer facing roadmaps, etc. “Predictability” becomes more important than productivity
* Teams know that only predictability matters, so they start making really conservative estimates, just to be safe
* If you have 2 months to do 1 month of work ... it’ll take 2 months. And this starts becoming the new norm
* Plus, you start spending more and more time planning, “scoping out epics”, etc., to get “better” estimates
You get the idea - pretty soon that 45 person team ships not much more than the 6 person team used to. Nobody is purposefully dogging it, or trying to go slow, but it happens when companies grow unless you’re really, REALLY good at fighting it. And few companies are. Everyone is BUSY, but they’re busy doing quarterly plans, “full potential analyses”, change management, meeting with stakeholders, working on all sorts of checkboxes to get all sorts of security certifications to sell to one or two big government buyers, working on “business development” projects that users don’t care about, etc.
It's also about the kind of features you implement. At the start you implement all the easy features, that's no problem. Once you mature and want to get B2B sales, you need to start supporting all kinds of connectors to legacy Enterprise software, networking stacks and environments. That's much harder and much more frustrating than building a simple ticketing system.
As an example, supporting OAuth is easy. But making sure your software works with all kinds of on prem LDAP for authentication is much harder.
Yeah totally. I think most feature work at a B2B SaaS company can be classified as either trying to drive retention, or trying to drive new sales. The “new sales” features are often focused on one or a handful of potential large customers with very specific needs, who won’t buy without feature X. This kind of work is basically invisible to almost all of your customers, but is necessary to close the largest deals.
I would argue that some of that baggage doesn't make you less efficient. I mean it makes you less efficient at the features per hour metric, but what about the business value metric? If you have meetings to really think things through and plan, maybe whole areas of sterile development work are avoided and that is valuable.
Remember there are businesses that do well writing no code at all! Code or features isn't what it is al about, but in a tech company it is somewhere between nothing and everything.
Yeah, fair point. This is more an answer to “how can you have such a large product/development team, and ship so few new features”, as I believe that’s a natural consequence of having a larger business, with far more communication overhead, far more focus on planning and predictability, etc. That’s not necessarily bad for the business, but it does mean you have a lot of people shipping a relatively small number of features, especially compared with your velocity in your startup days.
Yes companies definitely get more inefficient as they grow, for all the reasons you cite and more. I've experienced it first-hand.
Adding an engineer to a team slows down the whole team a little. There comes a point where adding head count actually results in less productivity overall. This is typically countered by splitting up work into various teams with minimal interaction between them. Like Amazon's famous two-pizza team strategy. This is the main attraction of microservices, each team can own their own piece of the code and change it and deploy it without (ideally) having to consult with anyone else.
There's always a mix between "now we're at scale and need to solve this really hard data sync problem" and "let's build an internal slack clone because we can".
Ouch, data sync his close to home for me. That was my first job. Not an easy problem at all.
Tip for those of you with the same problem, if you can, try to sync both the data and the actions taken to produce the data (event sourcing) and try to eliminate sources of indeterminism.
It depends on the business logic. If e.g. a user updates a numeric value on an entity, and there's a conflict probably you choose the most recent value. The action taken (user updates value) is pretty useless in this case. In other cases, e.g. inventory reduced by X because X units purchased/consumed - then it's more important to have the action itself, and a conflict would involve applying both actions and possibly alerting someone if that causes the value to be invalid (e.g. inventory below 0.)
Except for the part where even if you ignore the sales and marketing expenses they're barely breaking even. They're failing to make software for less than they can sell it for, and perhaps some of those hard problems which took 50 engineers to solve would have been better to have gone unsolved even if they lost some sales as a result.
That's normal in a SaaS. They gear everything towards growth in revenue, not necessarily profit, since it's much easier to keep existing SaaS customers (most good SaaS have 95+% retention) than to earn new ones, and at a certain point you've got a flywheel going so that you can perhaps reduce headcount increases or stay flat while your revenue continues to grow, and then you coast into profitability from there.
"Our founding engineers had learned from their experience working at Google and Facebook that to ensure a performant and stable application, they would need to build their own framework"
I didn't believe that was an actual quote from the article until I read it. It sounds like a joke and I can't imagine anyone reasonable would say that.
There are definitely good reasons to build your own framework but performant and stable applications isn't one of them. Usually it's a solution looking for a problem.
In fairness the decision was made in 2009. I still don’t think it was the right decision but it feels a lot more understandable to have made that choice when looking at the frameworks available in 09 rather than 2020.
I never worked at Asana but I heard it was both, it had code sharing between client and server, some server-side javascript before node.js (I think it was based on JSC) and something similar to isomorphic javascript before this term was coined by Airbnb. If you look at Meteor, a lot of similar ideas migrated there.
At Google or Facebook that makes sense. If you encounter much larger scale than pretty much any other company, it's hard to find libraries that work for you. So the observation was correct but they should've concluded that this is just a result of scale and complexity, not a general strategy.
Luna wasn’t a programming language, it was a framework. The link you yourself provided equates it to “React, RxJS and Firebase” and states the closest OSS equivalent as Meteor (developed by ex-Asana employees).
IMO this will be one of the failed IPOs of the 2020.
I understand (but not approve) 300 devs - they got a ton of integrations, enterprise client handling, lot of mobile, frontend and backend surface area to cover, lots of devops and support, teams to build new features, maintain tooling and so on... given time, any software team will slow down and scale up, unless it is specifically countered by the company. There's always stuff to be done (create, maintain, or both), pressure comes from the top and the usual response is "throw bodies at it". The less hackerish/the more corporate the company, the faster the engineering team blows up. Kinda inverse function of the red tape.
But the reason I believe Asana is going down is that their product is just what it sounds like - boring. It's a problem that's been solved a million times and they are just lucky they got on the ride in the early days. But they never evolved and the marked is getting new competition every day that is fighting to take their users away the moment they google asana alternatives. On one hand, they got Jira/YouTrack to fight on the enterprise side and Trello/Monday/Clubhouse/Notion to fight at the startup & SMB sides. If they don't evolve their product and bring something unique that will differentiate them and save their customers more time or mental context, they will remain the "boring" choice in a time where people are looking for the "fun" thing. And while it's good to be the boring choice, it's also a good way to haemorrhage users and profits.
If I was steering Asana, I'd look at stuff like Notion and JetBrains Space for inspiration and product evolution, focus on minimising users context burn rate, developer and general UX optimisation and visual noise reduction.
If there is no large changes soon, grab some popcorn and watch it burn - I give it about a year before it starts tumbling downwards.
We were. It's doubtful that we still are. GDP growth has clearly popped back above negative for the third quarter, which will break the two quarters technical requirement. Most economic readings right now are strong, from manufacturing to retail to job creation.
It's more like we're in the equivalent of the first or second inning of the post great recession recovery now.
This recession isn't broad, it's unusual in its disjointed hit. It's primarily hammering lower income labor and specific types of small businesses. 40% of low income households lost jobs just in the March and April shutdown. That's where most of the job damage was at:
CNBC "Households with income below $40,000 were hit hardest by the coronavirus pandemic. Almost 40% were laid off or furloughed by early April, according to the Federal Reserve."
Jobs in the top 2/3 have largely been unscathed, which is why the broad housing market continues humming along in most regards (whereas housing got smashed in every way in the great recession). It's also why hiring has been so ferocious and unemployment has recovered dramatically faster than during the great recession; it's specifically because the context isn't all encompassing. The great recession didn't spare the middle class and higher income groups nearly so much, it was a very broad recession.
Which all makes sense, this wasn't a normal recession, it was a temporary forced shutdown of some parts of the economy due to a pandemic (further, not all of the economy was shuttered during the second quarter, the majority of the economy kept functioning throughout the pandemic).
A thousand people are dying of COVID-19 every day, it’s not a normal recession, but pretending it’s over is silly. The markets have likely priced in a second stimulus which at this point probably depends on a different president.
Product innovation and quality represent very little of a company’s value. Distribution is where value is derived, and Asana’s distribution is incredible. And their product isn’t bad!
No, you're oversimplifying a lot. Just security and infrastructure operating at Asana's scale requires several dozen engineers. Additionally, Asana has been developing all sorts of features around working with "tickets" - Gantt charts, automation, 3rd party APIs, mobile apps, etc. All of this while working with a large legacy codebase that makes development slow.
(Note: I worked at Asana when it was ~100-150 engineers, and it felt like we could use double that. Having since moved to a FB team, I find I can develop UI features at probably 3-4x the speed in comparison to my time working on Asana UI, simply due to using modern React code with jsx and functional components using hooks)
wait and hear, all the justifications around hn that they need 300 engineers. when their competitor basecamp has around 50 engineers. only difference is one is vc funded + dustin's fb funds, while basecamp is bootstrapped. and a lot of sv hype in terms of the tools they use to build asana. basecamp html + sprinkles of js. asana react + redux. on the backend asana 100s of microservices, basecamp 1 monolith. reading the comments, based on experience at fb | google they made their own language. if that's not peak sv shoot me!!
> Investors / boards are wanting to get money out before things turn south I feel.
How would you distinguish that motivation from "Investors / boards feeling that the business is in a strong position, and the worldwide uncertainty from the pandemic has stabilized enough to feel confident about continued growth, so they're ready to go public"?
Why assume such a negative viewpoint without giving any reasoning or arguments for it?
One other conflicting thing about your view, is that if filing now investors are still probably a year out from being able to sell their shares. If they thought things were about to turn south, that's a long time to wait. Surely it would be better for them to sell on a secondary offering and get out sooner if they were sure of that?
I think at least part of the motivation to IPO is that if the US has a new president starting 2021, said person has stated his intent to vastly increase capital gains taxes, probably starting with tax year 2021. Add to that increased corporate tax (which probably affects VCs' math, although I'm not sure how), there's probably a lot of people who would prefer to accelerate their taxable events.
And you don't plan IPOs depending on polls. They're way too expensive and complex for that. You can accelerate the process or delay it if markets aren't receptive but the general decision to IPO won't be made because there might be an unfavorable election.
I'm at a company that grew from 10 to 200 engineers. Basically the first 10 build the actual product, and the next 190 build one-off customizations for enterprise customers.
If Airbnb filed their S-1 last week, and these companies filed their S-1s today, then wouldn't Airbnb be further along in the process and not "much earlier"?
Maybe a surge in IPOs for HN crowd? An IPO of a construction company won't make the front page but Asana does. Maybe VCs increase pressure to cash out or management is motivated by other successful IPOs of the recent past.
I don't know any hard evidence to say if overall IPOs increased but the examples named in this thread are very biased towards tech.
This is a hell of a market to short anything. In the near term anything that helps remote work like this is probably going to spike up. Good luck with that. I know that I wouldn't personally be comfortable being confident I could make collateral to outlast a bubble or guess correctly when the tide is going to turn to make money off of an option trade when it comes to a remote enabling company in a stock market as crazy/driven by politics and the fed as this one
You can offset your short with a long in a competitor. That takes out the market beta. However, it isn't free and it can take a long time until a bad company goes under (not saying Asana is one, haven't used their product).
Wirecard laundered money over years and the FT reported on it, it still took a long time for it to collapse.
Banks generally benefit from steeper yield curves. The yield curve is still quite flat and will likely stay that way due to the Fed buying-back long term treasuries.
Hope you have good margin rates, you could be waiting a long time. A lot of these are steaming piles of shit if you think about fundamentals but the market doesn't care about fundamentals.
Interesting, I would say that once an organisation has gone a year or so with Asana, they are very unlikely to move as it would involve creating new processes and re-skilling non-tech savvy colleagues, therefore making it incredibly sticky. Which SaaS companies would you say are more sticky than this?
>Things already turned south (in March) and are on the rebound now.
The stock market is not the economy.
What has changed since March, except a whole lot of small-business bankruptcies and closures, cities burning in mass protest, and an even-closer, tightly contested election with massive political consequences?
There’s plenty to be worried about in the real world, but what’s changed is in March the market was down 30%, and now it’s back at all time highs. The Fed is the most important factor in the market these days, not the economy, and since we’re talking about ipos the market is what matters.
This was my take on it as well, bottoming out around June-ish (off the top of my head. can't exactly recall). I thought we were beginning the steady slog back up?
I’m astonished by all the sibling comments to the affect of “takes a lot of R&D to scale.” Spending to scale some things, like fb, makes sense because the value of the participant network is higher than the cost to scale. What value is created by scaling a todo app past the group of teams level?
I know it’s hip to assume the market crash is days away, but what makes more sense is: saas companies have proven to be the most resilient type of company in this market. It couldn’t be a more perfect time to IPO.
The reason the market looks so good right now is because tech stocks represent a significant portion of the indices. Many other stock are still way down (appropriately)
That's just the way corporate America operates. They hire lots of people because it's a better utilization of money than just giving money back to investors. If you give money back to investors, you're not growing anymore and have failed. If you reinvest (and for a pure tech company with no physical assets, that has to be hiring), maybe one of them can grow the company.
What specific indicators besides covid / asymmetric v-shaped recovery (v-shaped recovery not distributed evenly across economy) are you pointing to? I understand VC's want to favor profitability earlier on in the funding cycle now than say in 2014 - 15, but that was kinda expected before the 'rona hit in March anyway.
My armchair guess would be, this is a win win market. Its booming, so you can ride it as it goes up. And if you don't do well, you can blame COVID. A lot of companies were on the cusp and this probably accelerates them all.
Just look at the price action on any big tech stock and pretend you're a tech investor looking for a big exit. People are pouring money into equities, particularly tech.
I really don't understand how Asana excels at anything, let alone is a '10x'. They probably need to spend a fortune in marketing just to get people to sign up.
It makes a lot more sense for marketers and others like us. I've tried getting away from Asana over and over but keep coming back. Everything else either isn't feature rich enough or is too difficult to use. They manage to strike the right balance. To me Asana is the epitome of the Churchill quote "Democracy is the worst form of government except all the others that have been tried"
Can someone in-tune to this world explain why Moskovitz purchases equity through a trust, in the form of convertible promissory notes? It seems like he isn't taking any compensation in stock or cash, but prefers to "invest" in the company's stock, through this trust and promissory-note scheme?
If you're confident that the company's eventually going to exit (obviously a big "if"), and you have the cash liquidity (which he obviously does, as one of the original co-founders of fb), is this essentially a method of getting compensation that isn't taxed as compensation? I'm trying to understand what the justification is for maintaining what looks like a fairly complicated transaction. It looks like they've done it a few times (2017, 2020 jan 2020 june). His entities also participated as investors in the Asana Series D and Series E rounds.
Not meaning to cast aspersions, just curious because I haven't seen these kinds of setups in S-1's before. But most S-1 companies don't have people with pre-ipo, >1bn net worth founder-CEOs, so it makes sense that this one might be a bit anomalous.
That's a fair question. I am not a lawyer or accountant or anything in that field, but I can try to answer anyway.
1) Often trusts and LLCs are used for liability protection and anonymity; you see this used by investors owning multiple residential real estate properties.
2) Your comment on tax is interesting; of course, capital gain in the US is taxed at 20% (plus your state), while income tax gets to roughly twice that. So, potentially, that could be a way to reduce how much taxes you will pay.
However, in relation to #2, I doubt that Moskovitz really cares to save 100k-200k a year in taxes. It's probably more about #1.
Again, this is my $0.02. Please correct me or improve my comment if you know the subject more than I do.
Trust tax brackets are steep enough that income tax and cap gains benefits are negligible. Anything that could be done in a trust w.r.t. cap gains could also be done as an individual, so there's no win there.
Inheritance tax benefits might be substantial though.
You're probably very right about the liability and anonymity aspects.
I believe these types of trusts (without knowledge of the exact trust setup) are to limit the inheritance tax when he dies, by having the trust own the shares at an early stage (lower valuation, lower inheritance tax). It can appreciate within the trust without accumulating additional inheritance tax on the appreciation. The downside is the trust owns the shares and he can't liquidate it for his own use, which he doesn't need to cos he's already rich enough.
Indeed. It's quite common to move your assets to a living trust in California for this reason, even for the only somewhat wealthy. It's basically SOP to set up a trust rather than just a will if you have assets above the simplified probate threshold. (I'm sure Moskovitz, being more than somewhat wealthy, has additional reasons.)
Another thing trusts and convertibles can be used for are getting around transfer restrictions placed on the securities or owner
You can always swap out the trustee on a trust, giving full control without transferring title of the security
A lot of fun things you can do in the financial engineering space
edit: I’ve seen them done on employee shares/stock options, or on LLC membership interests, but in this case I could imagine being able to change ownership without reporting insider sales (likely not 100% compliant from the regulatory perspective but its likely never been challenged in court especially if nobody knows the trustee changed lol), or just easier asset management for inheritance purposes
I've found Asana to be a much, much nicer product to work with than Jira (at least as a developer, not sure about from the management side.) I genuinely wish them success and hope they're able to grow their marketshare.
Do you have up-to-date experience on both? I ask because, this year is my first time using Jira in 10 years. I was in big corp 10 years ago and we were on Jira and it was a disaster to have to use. UI was a mess and it constantly went down or went slow (big corp; self-hosted.). My current startup started using Jira Cloud recently and I found it to be much better than my past experience, and better than Asana.
I last used Asana at my last company, which I left 2 years ago. It was slow and a resource hog even on our pretty beefy work MacBook Pros. Compared to my current Jira Cloud experience in 2020, I much prefer Jira now.
This was about 2 years ago - at that time I found both Asana and Jira to be similarly slow, so kind of a wash in that regard. But it was corporate self-hosted Jira, so perhaps Jira Cloud is a smoother experience.
Jira self-hosted is actually often a lot faster than Jira Cloud, if you have decent gear to run it on. You run the database too, so it's a matter of how much cash you want to throw at it. Jira and Postgres on decent storage can be pretty quick, though of course it's still 100x slower than any normal 1990s desktop app.
I was in two jira cloud projects this year and in my current project we're using Asana. I've used Asana on and off over the years and I kind of prefer it. Jira is just a constant pain in our industry. It seems what process heavy product people gravitate too. So, I'm well familiar with it; know how to customize it (you have to); and know how to work with it instead of against it.
Asana is pretty complex these days and neither is perfect. Both are kind of slow. But crucially, bulk editing tickets in Asana is just a lot nicer. This is the single reason I prefer it over Jira because anything bulk is just a hell of multi modal dialogs: click, wait, click, wait, etc. It completely sucks the life out of me and makes me curse at my laptop.
Asana feels more like a spread sheet when you are bulk editing. I can switch to the list view, multi select a few tickets and e.g. add some tags, assign to the same person, etc. Boom done. This is so satisfying. I also love bulk inserting tickets in the list view: type, enter, type, type, etc. No modal dialogs involved for two key activities. No process bureaucracy imposed. This is why I like it so much. Jira does not even come close to enabling this level of efficiency.
I'm mostly a developer but seem to always end up taking on a lot of product management tasks as well. Comes with the job when you hit a certain amount of seniority. I tend to be vastly more experienced than some of the junior PMs I work with as well (by some decades). So, inevitably, I end up spending quality time with whatever ticketing system is used and translating their business requirements into actually actionable tickets suitable for consumption by developers (i.e. doing their job). I'm experienced enough to know that the tool is rarely the problem or the solution (it's always the process) but the tools do bias the process (jira and scrum-butt go together real well) and tend to become part of the problem. PMs preferring Jira because that's all they know is usually the reason it's used.
A pain point with Asana is that it is indeed quite slow for some things. E.g. drag and drop of tickets is very sluggish on Firefox. Initial page load is also not great; but once loaded things are reasonable. However, Jira cloud is painfully slow in comparison. I've seen 10-20 second page loads for ticket detail pages. That's appallingly bad and IMHO completely unacceptable for a paid product. It looks to me that they UI is doing lots of REST requests all the time and some use cases seem to end up doing way too many of those.
So any time they get busy, the seconds add up. It's what makes using Jira such a miserable experience because absolutely everything involves multiple such page loads. If you can avoid having to go to detail screens, it helps. Unfortunately, inevitably the fields you care about are scattered over different views.
Asana is much less painful in this respect. But both have challenges on this front. Jira is the more feature rich (in the everything and the kitchen sink sense); but the features that matter to me (as opposed to the gazillions of crap bolted onto Jira over the past 20 years) are all there in Asana. Also, it seems to be a bit more opinionated on what the UI should be in the sense that you don't end up spending a lot of time heavily customizing it; which is a thing in all Jira projects I've been on.
I can work with both but prefer Asana.
An issue with both is that they integrate poorly with things like Github pull requests and version control in general. These days what I look for and have not really found yet (despite lots of plugins) is deep integration with and visibility into CI/CD. IMHO the life cycle of an issue includes events from these. At some point PRs are created, CI tests them, the PR is merged (and thus closes the issue), and CD deploys the change to production. I'd love to have a Github issue tracker style integration into either Asana or Jira. In fact with a little feature work to adopt some asana like features, the Github issue tracker could end up being superior.
Linear.app has nailed the experience IMO. It's simple, fast, developer-first, and has the advanced features you'd want without the bloat. Asana IMO is just too slow performance wise and functions more as a product manager-first tool as opposed to a developer-first tool.
Ooof I'm on asana for the first time after using jira for 10+ years. I hate it. Asana is a generic workflow tool where jira leans towards software development. This means that every part of your process you need to create in asana then explain to your team this is the one true way to use asana.
Example Epics. A way to roll pieces of a project into a larger ticket describing that project. There's no concept in asana. So you have to hack it by doing sub tasks and manually adding the project to each subtask so it shows up on the board.
I am a software developer working for clients that both use Asana and Jira so I used both. About a year ago I had to pick my own 'task management system' to work with other (freelance) people on client projects, I decided to pick Asana. The reason why? Asana isn't perfect, but at the very least it works and does what it does very well. It is really easy for people to understand the concept and start using it. Also, I really appreciate how easy it is to create a task and work on it yourself or assign it to someone else.
That being said, there is one thing I have been missing in all of those years. That is the ability to have automatic numbers assigned like Jira does (e.g. TE-01, TE-02) and allow those to be referenced in Git messages. So that is why I built a 3rd party integratie[0] that does this and integrate this. The Asana API was a _joy_ to work with, it works fast, quickly and the documentation is top notch. Now compare that to my experience with both the BitBucket API and Jira API.
What are the main differences. I just found it to be pretty much similar and what I find really confusing is my current and last company both had both of them one for business and one for devs. Both doing the basic kanban board and nothing else as far as I could tell.
Not a fan of the board/card focused view, mainly. I think it's visually cluttered and hard to read at a glance. Asana's list view (esp. with inline subtasks) feels a lot more like a to-do list, and I prefer that UI.
Am I reading this correctly in that they had a net loss in 2019 of $50.1 (42.4 adjusted) million dollars, and then in 2020 a net loss of $118.6 (68.2 adjusted) million dollars? (bottom of page 58)
And that their plan is to just continue trying to upsell and acquire new customers?
The thing that drives me absolutely bonkers with Asana (others do this as well) is that the freelancer has to upgrade their "free" account to roughly $70/month to get functionality like seeing a Timeline (think Gantt). Their pricing isn't clear that to upgrade to Premium (to get Timeline) says it's $10.99/month. It's not until you get to the next screen that it tells you it's 5x10.99/month because there is a five person minimum.
Almost none of these project management tools are built with full functionality for a freelancer who manages projects and people doing the tasks/projects, but doesn't need them to log into the project management tool.
Single-license freelancers are never the target audience. From my experience running a similar business, this is the hardest category of customers to deal with. Stuff like demanding very project-specific features for free overnight and cursing you when you explain how requests are prioritized from user numbers. Or demanding instructions on tangential topics (like how to troubleshoot some network issue their customer has) by claiming that it stops them from using the product.
I mean, there are nice guys as well, but statistically it's just not worth it.
Most single-seat customers are fine, of course, but a very vocal minority can cause a lot of problems.
I believe it's due to the mindset shift. If a team or company decides to use a specific software, people are more likely to accept the decision and learn to work within the tool's features and limitations. The cost of switching tools is high, so they tend to stick around for a long time.
Single-user freelancers can change tools at any time, because they don't have to negotiate with anyone else. As such, they feel they have more leverage in threatening to cancel their subscription if the company doesn't cave to their demands.
Most of them don't realize that the company isn't making much, or any, money off of their single-seat license when they're consuming hours of customer support or social media engagement time every month. It's better to see the squeaky wheels just leave the platform.
For another data point: At scale, you get a lot of threats from people claiming they're going to Tweet about how bad your product is to their thousands of followers, or write a newsletter about how much they hate your product, unless you implement the specific feature they're demanding. These threats exclusively come from the single-seat users, because no company is dumb enough to try to extort another company with threats of tarnishing their reputation in public.
It's unfortunate, but it's true. It's vastly easier to just deal with enterprise customers or larger teams who have better things to do than tie up customer support time for every little complaint or suggestion (or demand)
Fun fact. If you don't reply at all, and completely ghost them afterwards, no matter what they say, the chances of them carrying anything out gets close to zero.
I'm not sure I'm really buying your statistics. There are ways to go about prioritizing roadmap items that aren't rooted in customer size (think UserVoice). The company can also have a well documented and published roadmap so that I can easily see what's coming down the pipe and whether or not it's going to factor into my buying decision (I get item x which is something I really want - in a couple of months).
Dunno. You can look at their pricing tiers for yourself: https://asana.com/pricing. Also, it's not obvious that the Premium tier and above, despite saying it's "per person/per month", it's 5 person minimum. Gah
I am assuming that's on purpose. For them the number of people on project is proportional to the money they can earn. Why would they cannibalize their revenue by allowing shadow profiles.
Edit: re-read your comment. It seems like you clarified or I missed about the five person being the minimum thing for that.
I simply put tasks in Asana and want to view it on a timeline like a Gantt chart. I can't do that unless I pay 5x10.99/month. There is a huge gap between $0 and $70/month.
What revenue are they cannibalizing if I'm not going to go from $0/month to $70/month when I'm only one person? They just lose me as a customer going forward.
Sales and marketing and R&D fuel rapid growth. This should be maintained until growth nears its ceiling and the company starts encountering diminishing returns on investment in growth.
According to the filing Asana has 1.2m paying users. Each user is worth maybe $1000. That puts Asana at 1.2bn.
The median forward revenue multiple for public enterprise SaaS companies is 10x, and with 2020 revenues of 150mn that results in a 3bn market cap.
A third data point is they raised 75M 16 months ago at a $900m post money valuation. With growth at 100% annually that puts their current valuation at 2.5bn or so.
Three different 30 second valuation strategies that result in the same ballpark numbers.
Their business plan is $30 a month, so I'm tempted to say each paying user is definitely not worth $1000.
Given their revenues of 142M and 1.2M paid users, that's an average a tad below $120 a year per user, which would actually be less than their cheapest plan. That doesn't add up, it smells of free trials counted as paid users.
Trying to calculate revenue per user in this way assumes that they started the year with 1.2M paid users.
Napkin math, assuming the user acquisition was evenly distributed throughout the year, came out to maybe $160/user.
$1,000 LTV would mean that each user stays a user for ~6 years.
I'm not sure if that's a reasonable assumption or not. Just sharing numbers because I was curious how much the average user might be paying, after seeing the discussion above.
That 3rd point is outdated, as you have more recent valuation data - the stock recently traded at 13.04-25.00 price, with 151M shares outstanding and 33M in unexercised options.
I'm not sure where you get $1000 per user. Is that a CLTV number? The amount of money put into the company by Dustin himself, the declining efficiency metrics (costs increasing faster than revenue), and the 10x number you mention points to a valuation more around $1.5B.
Based on a few of the comments on this thread, I wanted to point out that filing an S-1 is not something that you just do overnight. When companies decide to go public it's a lot of work usually involving multiple dedicated teams on the business side. It takes many months and can take over a year.
So while the timing here is interesting, nobody decided on Friday that many well-known tech firms would declare their intent to go public on Monday.
This is false. A lot of these companies started their IPO process earlier but then got delayed due to COVID. Not everything is as pessimistic as you’re making it sound. It just happens to be before November (companies usually dont go public during election season) so this is the only viable window for companies to go public for the remainder of the year.
Dustin is also notable for starting Good Ventures (https://www.goodventures.org/about-us) which funds a lot of research and philanthropy into some great causes.
"We started Asana because our co-founders experienced firsthand the growing problem of work about work. While at Facebook, they saw the coordination challenges the company faced as it scaled. Instead of spending time on work that generated results, they were spending time in status meetings and long email threads trying to figure out who was responsible for what. They recognized the pain of work about work was universal to teams that need to coordinate their work effectively to achieve their objectives. Yet there were no products in the market that adequately addressed this pain. As a result of that frustration, they were inspired to create Asana to solve this problem for the world’s teams."
I can only imagine that the complexity of the coordination inside Facebook continued to grow after Asana was created.
So is Facebook a client of Asana to solve this problem ? How does a company like Facebook handle the "coordination problem" ? Do they have one tool that solves all the issues or a myriad of project management tools ?
Except Planner has no timeline or Gantt charts, despite claiming most of last year, that Gantt charts where on their roadmap. I've found Planner to be nothing more than a glorified Kanban board, which is also something Trello does much better even on their Free Tier using your 1 powerup of a Gantt chart.
Trello does it much better for a small team in a non-enterprise setting. Having to manually add and remove users, and manage external sharing is a huge drag in any bigger environment
Yeah, seems like that. When Covid-19 hit, there were layoffs in AirBnB etc. and everyone was talking about how IPOs will get pushed for future. Seems like all those worries have evaporated considering Tesla is trading at $2000.
I've read a lot of comparisons between Asana and Jira, but I was curious if anyone can explain the difference between Asana and Basecamp? I don't have experience with either service.
This filing looks like it has a ton of red flags about the way Asana is running their company. As an example, one of the images tries to highlight Asana's timeline and their achievements [1]. One of the things they mention is opening an international office with ~100 employees and <11k customers. Based on their current figures of 75,000 paying customers and revenue of $142,606,000, you would expect a revenue of ~$19 million for 11k customers. Why is a company with 100 employees & <$19 million in revenue opening international offices? Likewise, why is the company spending 74% of revenue on sales and 63% on R&D? How are they managing to lose 83% of revenue? It seems like the company has 0 responsibility with how they spend their cash and beyond that, it's unclear whether they even have a path towards profitability if they're spending 75 cents on the dollar just to make a sale and throwing almost $100 million at R&D every year. Despite substantial revenue growth y/y (~70%), they've managed to outpace it by growing losses twice as fast at ~140%. It seems like the company has a pretty good product and a great gross margin as well as good revenue growth, but I don't see them becoming profitable with their current management -- it seems like the folks in charge right now have no clue how to run a successful business and will just throw money away as soon as they're given it.
As a non-American who knows little about the IPO process, is there a reason why there have been a flood of S-1 reports listed on HN over the past 24 hours?
I mean, the driver for these record high multiples is that the Fed has made it very clear that cash will be extremely abundant over the next couple years, and hence worth a lot less. It would be a dereliction of duty for those public investors to not get rid of it ASAP and put it into scarce resources, like the stock of hot Silicon Valley companies.
The folks who are the real losers are any suckers who think they're going to get by with a fixed wage, particularly if they're in a competitive labor market.
OP means in general, and to be fair the tech IPO market post financial crisis has actually been fairly weak. the number of tech IPOs happening right now is at multi year highs
Summer is traditionally quieter since people are on vacation; still kinda holds true now. With S-1s out this week, you have more than enough time for the grunt work to be done before people are back in the office after Labor Day. I'm sure bankers have advised clients to get their ducks in a row because there's going to be a lot of supply and you really don't want to be the last out the door.
Likely because it's the end of the second quarter and they all have high numbers because of Coronavirus and such. For some companies their Q3 ends inside of just after November.
And we all know what happens in the U.S. in November every four years. So there's going to be great concern about the market dipping or taking a dive.
It is indeed a race to the finish before the whole thing crashes down soon.
Maybe as soon as they heard Airbnb and Palantir planned for their IPOs, everyone started to run for the hills for their own IPO filings before the whole thing falls over soon.
Reminds me of the dotcom era. Now this is the time again.
I totally get the feeling behind this, but you can't blame market participants for taking actions that are rational, regardless if the overall market fundamentals are/seem to be irrational.
If the market is desperate for returns, and tech equities are one of the few remaining avenues for such returns, and you are the owner of those equities, what else would you expect to occur? "No no no, don't buy these valuable shares of my company, invest elsewhere!" No way, you're going to cash out as fast as possible before your gains evaporate when the market transitions.
Most undesirable actions by the powerful have a rational character. It's bizzare to me that this is so commonly used as a defense. It says to me that the problems are seen to be individuals, not systems of power.
Note: I'm not commenting on the specific case here, just this argument in general.
Makes sense they're going for the IPO at the start of the work from home era. Asana has been around awhile and my team always used it for remote team communication and project management. We never saw the need for apps like Slack or Basecamp because working with the tool is very similar to the Getting Things Done system (or Toodledo).
I'm looking around their site and blog (and the S-1) and read a lot of 'marketing-speak', but no simple one-liner about what they actually do and what value they bring.
Am I missing something obvious?
What comparative companies are they like? I saw someone mention Jira. Are they 'a Jira'?
While better than Jira in UI, I haven't been able to like Asana as a product for some reason. In my previous company we moved away from Asana to Jira because it seemed PMs and higher management found Jira easier to work with.
Not a dumb question at all. The thing to keep in mind is that IPO stocks are allocated. There's a fixed amount of shares, and they are priced hoping for a "pop". So basically banks use IPO allocations (in hot companies) as a way to reward good customers. How important are you? Unless you are worth north of $100MM the answer is "not very."
The first step is to have a relationship with a private banker at a big bank/asset manager. You can tell her that you're interested in purchasing stock at IPO. Most big banks will have some allocation available.
Often the minimum ticket size is something like $100K--but there's no guarantee you'll get it. At some point before the IPO, your banker will tell you how much IPO stock was allocated to you. This will tell you how important you are to the bank. They might, maybe, throw you a bone and give you $10K of allocation.
You have to remember that IPOs are intended to be "free money." They are purposely underpriced. This isn't actually as nefarious as it sounds--the only people getting hurt by this is the issuing company, and not really. They want to have as good a relationship with the big bags of money as the issuing banks do. And there is some risk involved, they don't always pop, etc etc.
An important detail is that, because the IPOs tend to be mis-priced, they also tend to be pretty small. A company going public at a 2B valuation might only be offering 100MM worth of stock. At a 30% pop, that's basically 30MM of "free money" to distribute across the entire planet, which is honestly not that much.
my guess is that a detailed account of the consumer goods you have purchased - including possibly the device upon which you typed out and submitted this comment to this web property - would indicate otherwise
Aside from that, I'm surprised how much it costs Asana on engineering R&D, for essentially a ticket management system. How does a team grow to ~300+ developers ($89M R&D) to figure out how to attach PDFs and videos to tickets, and email people when there's a change in status? (ok yes I'm oversimplifying a bit, but not that much)
And (as with all such companies) how much they need to pour into Marketing/Sales to sell this thing. These above costs basically wipe out the gross profits by 2x.