Good on them, but can Silicon Valley people stop conflating their corporate operating bloatware with Eastern Spiritual Terms?
Completing that outstanding customer ticket is not like the process of achieving englihtenment.
Asana S-1
221–230 of 251 posts
Re: Asana S-1
#222As 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?
It seems just coincidence.
The reason for coincidence might be cash-out for investors due to fear of covid-19? I do not know that.
Re: Asana S-1
#223Dumb question - but with all these tech IPOs, how does one get in/invest at IPO time without buying on the open market?
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.
Re: Asana S-1
#224Earlier quoted context omitted.
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.
why both? isn't that wasteful? which one wins if they disagree? do you sync both at the same frequency?
Re: Asana S-1
#225I'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.
In case someone's in the market for a fast, developer-first alternative to Asana, check out https://kitemaker.co
- list views of issues (if you prefer that over the board)
- can do everything without touching a mouse (if you're into that)
- integrations to GitHub, Slack, etc.
- reach editor with markdown shortcuts (similar to the Notion editor)
Re: Asana S-1
#226Earlier quoted context omitted.
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 corporat…
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.
Re: Asana S-1
#227Earlier quoted context omitted.
> 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, bac…
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 corporat…
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.
Re: Asana S-1
#228This 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 [1] https://www.sec.gov/Archives/edgar/data/1477720/000119312520...
Disclaimer: I'm not a professional investor and I'm not familiar with Asana's business
Re: Asana S-1
#229According 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…
Why not model based on expected future cash flows? That's basically the gold standard in finance and what you'd expect most investors to follow.
Re: Asana S-1
#230Earlier quoted context omitted.
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 manag…
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 makin…
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.