Live data from Hacker News

Asana S-1

sec.gov

191–200 of 251 posts

Re: Asana S-1

#191
post #180
post #77

Earlier quoted context omitted.

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 manag…

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.

Re: Asana S-1

#192

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 oversimplify…

Most of the tracking systems require enterprise integrations and need to support migration from other platforms.

Re: Asana S-1

#193
post #18

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.

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.

[0] https://astogi.com

Re: Asana S-1

#194
post #74

I know Asana is prettier than MS planner but: 1. Planner is bundled with 365 2. Planner works with Azure AD SSO for free. 3. Planner is 100% integrated with Teams. This makes Asana an outside bet for me.

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

Re: Asana S-1

#195
post #51

Earlier quoted context omitted.

Very crowded market - not very sticky either relative to other SaaS type cos. I would avoid this one personally.

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?

Zendesk?

Intercom?

Salesforce?

Re: Asana S-1

#196
In the "History" section (p.2) they state that

"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 ?

Re: Asana S-1

#197

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 oversimplify…

> 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…

>> 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.

Re: Asana S-1

#199
post #150

Earlier 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…

Those downsides could also be considered upsides from a certain perspective: More work, more jobs; the industry grows.

Whose perspective is that, though?

Individual companies don't benefit from low productivity, and neither does the economy as a whole.

Re: Asana S-1

#200

Earlier 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…

>> 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.

Useless in what sense? And which of those things?

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.

Post reply on HN