Invest Like the Best with Patrick O'Shaughnessy - Dustin Moskovitz – Eliminating Work About Work – [Founder’s Field Guide, EP. 19]

Episode Date: February 4, 2021

My guest today is Dustin Moskovitz, co-founder and CEO of Asana, a team-centric product management tool used by over 1.3 million users around the world. Dustin started Asana in 2008, 4 years after co-founding Facebook. In this conversation, we dive into Dustin's belief about the diminishing returns of hard work, the shocking amount of productivity lost in doing "work about work", and Dustin's philanthropic investment strategy around leverage and maximizing ROI. I hope you enjoy my wide-ranging conversation with Dustin Moskovitz.    For the full show notes, transcript, and links to mentioned content, check out https://www.joincolossus.com/episodes/88012555/moskovitz-eliminating-work-about-work ----- This episode is brought to you by Tegus. Tegus has built the most extensive primary information platform available for investors. With Tegus, you can learn everything you’d want to know about a company in an on-demand digital platform. Investors share their expert calls, allowing others to instantly access more than 10,000 calls on Affirm, Teladoc, Roblox, or almost any company of interest. Visit https://www.tegus.co/patrick to learn more. ----- This episode is brought to you by Vanta.  Vanta has built software that makes it easier to both get and maintain your SOC 2 report at a fraction of the normal cost. Founders Field Guide listeners can redeem a $1k off coupon at vanta.com/patrick.  ----- Founder's Field Guide is a property of Colossus Inc. For more episodes of Founder's Field Guide, go to https://www.joincolossus.com/episodes.    Stay up to date on all our podcasts by signing up to Colossus Weekly, our quick dive every Sunday highlighting the top business and investing concepts from our podcasts and the best of what we read that week. Sign up at https://www.joincolossus.com/newsletter.   Follow Patrick on Twitter at @patrick_oshag Follow Colossus on Twitter at @JoinColossus   Show Notes [00:03:19] – [First question] – Balancing hard purposeful work and too much work that leads to burn out [00:05:41] – What led to this way of thinking [00:06:54] – Regulating hard work through culture [00:08:25] – False tradeoffs and how Asana represents this [00:09:43] – Origins of Asana [00:13:22] – Organizing the chaos of a project [00:18:09] – Change vs discipline of the mission [00:19:55] – Transferring good ideas from one company to another [00:23:19] – Instilling leverage as a concept in an early company [00:25:21] – New learning curves in building Asana [00:26:52] – Hardest boss battle during his time at Asana [00:28:43] – The role of the work graph [00:31:46] – The proliferation of the work management space and the overall landscape [00:32:56] – The idea of radical inclusiveness [00:36:31] – Best reasons to start a new company [00:37:47] – What will lead to Asana’s continued success [00:38:59] – Lessons building the product [00:41:13] – Work with the Open Philanthropy Project [00:43:44] – Work on pandemics and biosecurity [00:46:11] – Where he sees the future of artificial intelligence [00:50:47] – Kindest thing anyone has done for him

This episode of Founders Field Guide is brought to you by Teegas. I started hearing about Teegas when when several of my close professional investor friends sent me passages or ideas they'd found on the Teague's platform. Conducting effective primary research shouldn't take weeks. It should take hours. Searching for answers shouldn't be lengthy, cumbersome process. It should be easy and nearly immediate. Expert calls should not cost $1,000. Teagis solves these problems and makes primary research faster and better for professional investors. Tecis has built the most extensive primary information platform available for all investors. With TIGIS, you can learn everything you'd want to know about a company in an on-demand digital platform. Investors share their expert calls allowing others to instantly access more than 10,000 calls on a firm, teledococ, Roblox, or almost any company of interest.

All you have to do is log in. Still want to do your own calls, Tegas has a solution. Experts that are just as good or better than what you'd find on other networks for just $300 per call, not the $1,000 or more that others charge. If you're curious about Teegas, call the top performing investment manager you can think of. They're probably already a Teague's customer and they'll point you in the right direction because customers, myself included, love Teegis. Visit tegis.co slash Patrick to learn more. This episode is also brought to you by Vanta.

Does your startup need a SOC2 report to close big deals? Or do you already have a SOC2 report and want to make it easier to maintain? Vanta has built software that makes it easier to both get and renew your SOC2. With Vanta's continuous monitoring solution, you avoid hosting auditors on site and taking hundreds of screenshots to prove that you are compliant so you can focus on building your business. Vanta partners with audit firms who file your SOC2 report directly inside of Vanta at a fraction of the normal cost. Hundreds of companies, including more than 100 Y Combinator businesses, are leveraging Vantas today to streamline compliance and focus on building

their businesses. Founders field guide listeners can redeem a $1,000 off coupon at vanta.com forward slash Patrick. That's vanta.com forward slash Patrick. Hello and welcome everyone. I'm Patrick O'Shaughnessy and this is Founders Field Guide. Founders Field Guide is a series of conversations with founders, CEOs, and operators building great businesses. I believe we are all builders in our own way and this series is dedicated to stories and lessons from builders of all types. You can find more episodes at investorfield guide.com. Patrick O'Shaughnessy is the CEO of O'Shaughnessy Asset Management. All opinions expressed by Patrick and podcast guests are solely their own opinions and do not reflect the

opinion of O'Shaughnessy asset management. This podcast is for informational purposes only and should not be relied upon as a basis for investment decisions. Clients of Oshonosi asset management may maintain positions and the securities discussed in this podcast. My guest today is Dustin Moskowitz, co-founder and CEO of Asana, a team-centric product management tool used by over 1.3 million users around the world. Dustin started Asana in 2008, four years after co-founding Facebook. In this conversation, we dive into Dustin's belief about the diminishing returns of hard work, the shocking amount of productivity lost in doing quote unquote work about work, and Dustin's philanthropic investment strategy around leverage and maximizing ROI. I hope you enjoy my wide-ranging

conversation with Dustin Moskowitz. I was thinking about the most interesting place to begin this, and sometimes I think of these episodes and try to come up with the title ahead of time. One idea I had for this title was the diminishing returns of hard work. reading through Asana's history and your history, I'm really intrigued by the balance that Asana as a culture tries to create between purposeful hard work and what we'll call like too much or burnout. Can you walk me through that part of the business? I know it's kind of a strange place to start, but it really stood out in my research and would love to hear what you've learned that you could share with us all. First of all, thanks for having me on the show. A lot of my thinking is just

based on my own story of basically working too hard at Facebook and seeing the repercussions of that. I think you see a lot of narratives that you should work as hard as possible. That's the way to maximize success. You see a lot of people competing about how many hours per week they're working. And I think it just turns out to be a fallacy, both based on my own empirical observations and any sort of rigorous study that I've seen on it. That's always hard to quantify output, but there have been a few studies on this. Not only do you get diminishing returns as you go beyond, call it 50 or 60 hours per week, but you can actually get to negative returns quite quickly, where you're actually making all of your hours less productive, such that the sum is just less than if you had worked less. And there's some software issues, too,

of when you're burnt out state, you're just not as good of a teammate. It's easier to get into conflict. It's harder to work through disagreement and just make productive progress with the team. I've really just tried to impress that on our team, that the goal is not to maximize your hours, it's to maximize your output, and in particular, over the long run. It's easy to kind of sprint and can be fast in the short run. Can kind of burn the candle with both ends for a limited amount of time, maybe three or four weeks of sprinting, but you'll basically have to pay for that after in the form of a week or two of degraded productivity.

So you want to be really careful about when you do that and not just try to be pressing on the gas all the time. The basic axiom that you'll hear about this is it's a marathon, not a sprint, and it's just really true. I've been at a sauna for more than 10 years now. If I had burnt myself out, then we just couldn't have possibly gotten as far with me as the leader. And we have quite a number of employees that have actually been with the company for a long time, some of them more than 10 years as well. And I attribute that to them being able to have a

sustainable work life day and day out. Was there an episode personally that it was the aha moment or that the switch flipped for you to make you realize the benefits of this way of balancing work or the amount of work that you were doing maybe in contrast to what you mentioned at Facebook? I don't know if I had a sort of personal me hitting rock bottom story. or something like that. I do know when I got to a more sustainable part of my life, it just felt really different. I was able to look back and realize what was going on. But one thing that I did observe a lot while I was at Facebook, and especially in the years after I left, is just sort of seeing this pattern of very promising people who are still early in their career that were either

quitting the company or just going into early retirement and not doing something after. Part of that was They were wealthy and they didn't have to, but part of it was they were just tired. And it became a pattern that instead of taking a vacation, when people got burnt out, they would quit. They just needed a really long reset. And after seeing four or five of those in my immediate network, I just thought, well, this seems like a real waste. Maybe there's another way to approach the time they are spending at work that can make it feel more sustainable so they can have longer careers.

What I often find with these really interesting ways of approaching systems and problems, is that on paper they're really powerful. And in practice, you just come up against realities. Everything interacts. So especially on moderated hard work, don't burn yourself out. Some of these things naturally happen. Like, people just start working harder and harder and harder. How have you learned to regulate using culture, going outside the standards?

Some things I think are purely cultural and memetic. It's really about setting an example and having other people follow that example. For example, I think Asana actually is a quite strong cultural. around not working late at night and on the weekends. I think that's very much because people like me and the other senior leaders are just mindful about that. Maybe I'm working late or on a weekend, but I've got this great system of Sana. I'll just make a task for myself, write up a note, and then when I come in on Monday morning, I'll go and fire off a few of these. And that really helps people who might otherwise feel at the effect of perceived urgency

from their boss feel okay on plugging. And then you get more of a separation between your work and your personal life. And this is another reject false tradeoffs thing for me of people often talk about work life balance just strictly in terms of number of hours per week. I also think it's really important to have that polarity, the separation of when you're working, you're really focused on work. And when you're resting, you're really focused on rest. You're not constantly checking your email and getting push notifications and keeping half of your mind in the work context. That's sort of the number one is making sure that people have that separation. In the category of rejecting false tradeoffs,

What are the things in that category do you think are the most unique to Asana, where Asana represents the most divergent view on that principle versus your generic software company? Having it at all, I think, is quite divergent because I think that the psychist right now is to have these very simple axioms or like single metrics that you optimize for and to be as simple as possible. And in Asana, we embrace complexity and nuance a little more. If I had to PIP just one, I think it would be ARR, recurring revenue. But we typically present it to the company balance with things that I think of as quality regulators or sustainability regulators. The net retention statistic is a quality of revenue metric. Operating margin is a sustainability metric. And I think

you need all three legs of that stool. In terms of other sort of more concrete examples, a favorite one that has started to spread to other companies. And we took from Facebook as no meeting Wednesday. Some companies are like, we don't do meetings at all. Meetings are evil. My philosophy is more like meetings are very useful, but they also chop up your calendar and can interrupt focus time. And Facebook introduced it around the time that Paul Graham published that really famous maker manager schedule. And so we really took that to heart. No meeting Wednesdays is a way to have your cake and eat it too. I'd love to dig now a little bit into the history of Asana itself from start to finish. And I was like to start at the beginning. So you were in a very unique situation in having had exposure to

and success with a huge business very early on in life. Taking that as context, what was the, I'll call it spark or insight or period of time that Asana sort of was brewing in the sort of primordial ooze, if you will, of a new business. Just walk me through that period of time and what got things going. I was a first time manager to say the least. So it was only 20 when we started Facebook. I was just really at the effect of the chaos of managing knowledge worker team.

And I'm totally steeped in it. I understand this is totally ubiquitous experience. But back then, I was kind of naive and I was like, there should just be a better way to do this. So I started trying to do a few different things. I mean, the very first thing I did was just the normal. I have a one-on-one with all of my direct reports every two weeks. They would each have one-on-ones with their directs every two weeks. And at the end of a four-week period, I'd have a good sense of what was happening in the organization a month prior.

That was not good enough. And I was a software engineer, so I started designing some database systems. where I could keep track of the state of the world and just record my own notes in a more structured way of which program team was doing what. And then I thought it'd be a lot better if I could get the other leads to update this on their own rather than me trying to track all the information across the organization. And that's what led me to start to build a web-based system where we could collaboratively create the source of truth of the plan. So this was probably 2005, 2006. Jira started way back in 2005. So there were a couple alternatives out there,

but they're very nascent and just weren't quite coming out the problem the way I wanted to. So I built one version of that tool. And then my co-founder, Justin, came to the company from Google, and he had a very similar story as a product leader in the Google organization. And he similarly built an internal task management system. And later I found out that's a really common story, Almost all of the fastest growing tech companies in the 2000s had some sort of internal task management system. Their engineering teams built because they all had the problem and they were empowered to fix it for themselves. But then Justin and I were able to collaborate what for both of us was a version two of this idea and build something much better and originally built it just for the engineering team, but it's kind of pulled out of our hands and used by teams throughout the organization. So IT wanted to use it for inventory tracking, sales team wanted to use it for lightweight CRM.

and recruiting was using it as an ATS and sort of gave us this notion of there's a bigger idea here, really. This is a cross-functional need, and it's not being met by the market. When you have people sort of pulling toy internal tools out of your hands, there's a big demand for it. So after a couple of years of collaborating together inside Facebook, we were left with a really big vision of what this could be and a lot of feature requests coming from other teams and about a crossroads of do I build a three or four-person internal tools team and build this one product for Facebook internally, or do we leave and actually recruit a real team around this bigger idea and really see what's possible? Convince myself that this would be the best way to actually create an internal work management

system for Facebook would be to recruit a team and do it in a first class way. I can certainly attest we use it as our coordination tool when building software at Ashanti Asset Management. And before using it, it's interesting how much chaos there is. You only realize that after the fact. Once it begins to be organized, the knowledge work thing begins to be organized, you realize what a disaster it was prior. And it's not just for engineers. It's for everybody. What was the most surprising observation or set of lessons you learned in the earliest years of Asana? One thing just to build on the prior answer, I'm still continuously shocked by the scale of the chaos problem that you were describing. So we actually, I've seen a bunch of different research and we now run our own 13,000 person survey yearly. called the Anatomy of Work Report. There's this really consistent results that knowledge workers say they're spending 60% of their time on what we call work about work. Sending these long email back and

forth, going to status update meetings, we're generally just in some way communicating about work rather than doing the creative work that will result in output for the business. First of all, it's just a shocking number. Crazy. Crazy. Yeah. It speaks to the business opportunity here. Because we can not only hopefully give back all of that 60%, but we can also make the 40% more. leveraged and effective by giving people clarity about what's most important, what the strategy is, what the goals are that they're working towards. The scale of the problem and the scale of the opportunity, I think is the most shocking, even though I was living it. When you see it in numbers, it can still really quite surprise you. How do you tackle how to dismantle the 60% step by step as the product

evolves? I'm sure in the work about work, if you broke that 60% down, if it was possible to, you could say, okay, X percent of that 60 is devoted to this and this and this and this. I'm assuming you want to tackle the biggest percentages first to reduce that workload on just coordination stuff. How did you think through that, through the product lens, maybe from the very beginning and as the product has advanced and progressed? The pyramid of clarity is basically the top is mission and then strategy and then your top-level objectives like OKRs, if you run that kind of process, and then portfolios, so portfolio, of projects or workflows that represent big cross-functional initiatives, and then you have the

projects and the tasks, the atomic unit of work. So we really started at the bottom there with projects and tasks because I think that most of that work about work is really exchanging status information and getting on the same page with your team. So the way that companies that don't use Asana do this is they might have a daily stand-up meeting and they just go around, they say, well, what are you working on right now? What's the status of the thing you're working on? last week. We've got three jump balls here. We need to figure out who they're assigned to. We need to figure out when we expect all of this to be done. It just takes a lot of time to do all that. And when you actually build it out in Asana, first of all of all, you can do it in

distributed way. Everyone can just kind of list the things they're working on. And then all of a sudden you've got a fully built out project with all that detail. But it's also kept up to date. There's no reason to do this daily because as people change the metadata or complete things, that's just immediately reflected. Everyone can see it. They can also celebrate it and sort of share in that achievement. So it's also creates this motivating factor. And you just find yourself killing that status update meeting or starting to use it for something more productive, like actually working through a difficult problem or just for team bonding. That was sort of the obvious biggest piece that we should go after. And then a secondary thing, I think, is a lot of time gets wasted because you don't understand

what's important or you don't understand what somebody else is doing. So you might literally duplicate work that somebody else in the team already accomplished. And a lot of that is because there's lack of clarity about why are we doing this, especially if you're in a very large organization, you might just get a task from your boss, get a task from other places in the organization, and they all just look the same to you. They're just like a soup of tasks, and you don't know which is more important or which is more urgent. But when you help people connect to the higher parts of that pyramid of clarity, you give them that context. So they know which thing to prioritize, and they're also more motivated to do it because they understand why it matters.

I think the thing that most makes people feel like a cog in the wheel of a machine is just getting these things that made me feel our frivolous or unimportant. And in some cases, they might be right. But in a lot of cases, if you just help them walk up, well, this will help us achieve this higher level initiative, which connects to this subjective. And that's how this helps us reach the mission. Then they say, okay, I get it. I'm really excited to do this now. And in the earlier days of Asana, my co-founder, Justin, would just do this manually when people would get demotivated. You know, he'd say, okay, what's at the top of your task list right now, reground you in why this is important to the company by walking up this chain of events.

Now in the product, we've actually built those higher level parts of the pyramid of clarity. So we have the portfolio's functionality, introduce goals over the summer. You can start from either side. You can start from a task, walk up that chain and see how it connects, or senior leaders or just people who want to understand the company overall can start from the top level objectives and drill down to an arbitrary level of depth and see all the detail of the work that contributes to achieving that. Intuitively, I would think that the pyramid is clarifying, no pun intended, that the stuff at the bottom should change the most often and the stuff as you march your way up the level

should change less often. So first, do you agree with that? And when would you not agree with that? When is it right, especially at the very top, to consider change versus being very disciplined on the why, the mission, et cetera? I think that's absolutely right. In fact, I usually say the mission, that shouldn't change. Sometimes it happens. I think you basically have a new company at that point. They'll need to hire some new people and some people will walk away, cases like Slack.

But Asana has always had the same mission. We've reworded a little bit. It's very constant. The strategy is very consistent. have it written down. I've refreshed it before, but it's basically thematically similar to what it's always been. And I do that every like three or four years. And then the objectives, I mean, we run an okayRs process. So we do that annually. But we actually keep mostly the same structure of the objectives and just change what the targets are and what some of the particular initiatives are in each year.

So even that has quite a bit of continuity. But sometimes you do need to make a change. So for example, last year, COVID hit us in March. And it was only. six weeks after we had finished our objectives process because we're on a February Jan calendar and said, yeah, all of this has to change. We're not doing our 300 customer events all around the world in different cities. The financial targets need to change. The operating envelope needs to change. And we had to kind of go back to square one on that. But we knew that we needed to do it. And we had this formalized system. So once we changed things, we were able to communicate that back out to the company and get everyone realigned on what the new plan was because they're

familiar with that structure. So we were able to reconfigure pretty quickly. You came from obviously a famous company in Facebook, and I'm curious what you brought with you in addition to the no meeting Wednesdays in terms of thinking about how to run a business. But I'm also just generally interested how a pretty much pure knowledge business, not only the one that you built, but also those that you serve, best assimilates new things from people joining the company. So if you were the first one coming from a big successful company, what did you bring? And what have you learned about just bringing good ideas from other knowledge companies as those people join us on. First of all, things we brought from Facebook, one, I think just a belief in leverage.

It sort of almost seems not worth saying to me. I see so many other companies that don't seem to really operate with that philosophy, but just do the most important things first. Literally try and stack rank the roadmap in terms of time and effort to customer value, do the things that have the best hour high at the top. I'm sure as an investor that seems totally obvious to you. but I think it was very core to who Facebook was, and I think it's core to what Asana is. I do think Facebook did a better job than most in having internal transparency and internal clarity

about what the goals were and communicating that regularity to the company and creating a lot of different channels for people to ask questions and not really hiding anything. So we brought a lot of that to Asana. Of course, the product we build makes that especially powerful, because if you're a new employee coming into Asana, you can literally go back through the entire history of the company and find almost any decision and see the conversation about how we got to that decision, see the data around it, and it's all just there and organized in a way that's pretty accessible. And then we also have summary docs like the strategy docs where if you want to sort of grok it at a high level,

creates a lot of opportunity for people to learn. And then on the flip side, extracting things from other people, I mean, first of all, we're just students of what makes work great. So even if we don't have an employee from a certain organization. We're sort of devouring best practices and writings from companies like Netflix and Google and Apple and just trying to figure out what makes them successful and incorporating what we learn. And then when employees come in from organizations, I really impress at them beginning to leverage the beginner spine because they can see things that we've sort of lost perspective on. It's just like water to us because we've been in the organization for so long. So really being thoughtful about what works.

and doesn't work, trying to take some notes, but also being curious because sometimes people come in and they see something works a certain way and they're used to being done differently and they're just like, well, this way is bad. You should totally change it and do it the way I'm used to. But usually there's a good reason for things at Asana because we're very intentional. So we tell people write it down, but then ask the why. And sometimes you'll discover there isn't a good reason. And then that's a good time to bring up the alternative. And we create some formal channels for that. So in Asana, we have two very powerful projects. One is called product opportunities. People can just suggest functionality for the product. And our new employees have often

not used it before. And so they've got Beginners Mind with the product as well and just hit rough edges and can suggest things. And then we have likes in the product. So it's very easy for people to kind of pseudo vote on them. We can easily see what rises to the top there. And then similarly, we have Asana opportunities, which is more about cultural things and processes and people can suggest stuff there. Often it's like a request for a new kind of employee benefits and then leaderboard of what people are most interested in changing about the company. I want to go back to leverage because it's one of those classic things that's simple but not easy. It sounds obvious that that should be at the center of every company, but probably most companies, it is not.

What recommendations would you have or advice for those maybe with younger companies trying to instill leverage as a concept? And I think of this as a capital allocation concept early on in the business, both do's and don'ts. What advice would you give? Well, I do think it's good to be clear about what you're trying to achieve. Everything at Asana, we try and start with goals because right away, we'll often discover you're talking past each other or just coming to the table for different reasons. I already talked about objectives for the company, but also like you go into a meeting. We want to have what are the goals of this meeting and often the non-goals. And when we're building a new feature, what are the goals? What are the specific metrics we're trying to move with this?

And then you end up with a set of falsifiable claims, especially if you have a strong testing framework. So if we say we're doing this for adoption reasons, then we want to ideally have an AB test that demonstrates that we got an adoption one from that. Sometimes maybe tests be wrong. You know, you have both false positives and false negatives. But I think it really eliminates a lot of what is otherwise some wishy-washy thinking on maybe you thought you were doing it for adoption, beginning. and then you didn't move that metric, but you got some interesting customer feedback and people felt

good about it. And so you sort of ex post rationalize, well, we actually did it to please these particular customers or just to create good vibes in the product or something like that. It's a lot better if you can be clear about what you're trying to achieve and then objectively evaluate whether you did achieve that and having systems for that. And then over time, you'll calibrate more and create more clarity within the organization and have a better sense of what was really effective at achieving our goals. I would just balance it with don't be dogmatic because sometimes things are good, but they're hard to measure. I love the falsifiable claim scientific method for feature building or business building. It's really neat. As the business has progressed,

how has it changed most for you personally? What have been the major new learning curves in the 10 years at Asana that you've had to run up where you didn't have prior experience? I view this as a question sort of helping younger founders preview what? their future may hold. I've written a lot about the need to persevere as a founder because I think if you're going after a really big mission, it's just often going to take a lot of years. Better be really committed to that. I think that was something I understood at the beginning with Sana, but now I really understand that, you know, this is basically my whole career. And there are going to be some ups and downs and the role's going to change. And you've got to have something motivating you

throughout that's strong enough to pull you through that long journey. And then the other thing is the role changes. So when I started off of Asana, I was software engineer. And Justin and I were writing the product and we hired a few more. And then over time, my role gets more abstracted and became more about establishing that clarity that I was talking about earlier, the why and the what of what we're doing, really just talking to employees, talking to customers, talking to investors. Very little of it is about any sort of concrete work output. Joke with my team that the higher you go up the corporate ladder at Asana, the more your work actually is just the work. about work. That's all there is. You get to be the big boss. It's just 100% work about work and talking

about the work. It's actually very leveraged if what that is doing is creating the clarity that allows everyone else to do much less of the work about work. What do you think the hardest boss battle that you fought in the history of Asana has been? I use the video game term all the time. Some major challenge to be tackled and bested. The big boss. Yeah. Yeah. I think the one that most sticks out is we had to do a re-architecture. I'm sure you talked to a lot of founders. This easily can kill a company. One of the things that was really important to how we thought about the product experience is we needed to be really fast. We launched the paid version of Osana in April 2012. And at the time, a lot of enterprise software was still client's server model,

so like on-premise using operating system-based software. We wanted to build it in the web. We had some experience doing things like that in Facebook, where you have very rich client experience in the web. But the way Asana operates now is totally novel at the time. So we built a custom architecture called Luna that helped us to achieve that experience. But our first run at it was just not very efficient. And it did create the rich client site experience. So the single page load, you never have to refresh or click to a new page in Asana. But it was ultimately very slow, especially as customers scaled and put a lot of data in the system. So around 2014, 2015, team. We had a pivot or persevere conversation, realized we needed to start over, and we knew it was

going to be a very big, painful project, and we knew we wouldn't be able to do a whole lot else. Basically had half the engineering team or so working on this re-architecture while the other half was trying to meet customer demands and advance the product and help us compete in the market. It was very long. I mean, in some ways, we're still doing that re-architecture and rewriting parts of the original system. And it's just easy to become demoralized. And a number of people throughout the organization. We're just like, we're never going to finish this. We have to give up or wanting to start over and do like a third architecture. And it was just, it was a slog. I'm really interested. I think the obvious reality of the future is more and more knowledge work, more and more coordination like

Asana facilitates. Someone told me to ask you about this concept of the work graph. Everyone talks about the social graph or the interest graph or whatever. What is the role of the work graph in our lives, generally speaking? So we talk about the work graph as the data model of our product, but it's meant to mimic what we see is the real world structure of work. So the work graph, it's representing all of the units of work. So it's things like tasks, ideas, goals, agenda items, the information about that work, like relevant conversations, files and status information, and how it all fits together,

including really importantly, who's responsible for each piece. And companies that don't use work management software, they just do this with status update meetings and often with spreadsheets. But most of the teams that use work management software, that isn't Asana, are still organizing it in what we call the container model. They're not actually using a work graph data model. They're trying to fit things into what is effectively a spreadsheet like structure. In financial modeling, if you have a spreadsheet, you might have a row of data. That row lives only in that spreadsheet. It doesn't live in any other spreadsheets.

Most of the work management software that's building tasks and project management, similarly, every task lives in exactly one project. And Asana tries to free you from that container model. So tasks exist and they can be put in as many contexts as makes sense. So this is really useful for cross-functional work because you often have, for example, when we're putting together the earnings call, you have a lot of different teams that are involved in that. You've got the leadership team. I'm going to be reading the script and writing it, invest relationships involved,

legal is very involved, marketing teams very involved. And they all want to be working off the same source of truth. So, of course, the actual script, the content, but also where are we in the process, which version are we on, understanding whether it's gone through legal review or not. And the work graph allows them to contextualize that in each of their worlds. The design, the marketing team might have their own sort of request queue of work they need to do. And this is somewhere in that prioritization. Legal's got their own request queue.

In a container model, those are all copies of the source of truth. Because in a container model, that task can only live in one of those things. If legal wants it to live in their thing, they just have to make their own reference for it. But as soon as you do that, the source of truth starts to drift. This is what creates the work about work, is basically trying to fight that drift about what the status of that task is. You start having, well, there arenings calls coming up in two weeks. We've got to have a daily call so we can do that around the room thing and understand where everyone is. Whereas if you have the work graph model, then everyone just is working off that same source of truth,

but they're organizing it in the context that makes most sense for their workflow. You don't need to supplement it with other process. And that's really enabling the Asana product to actually model the way work happens in the real world where teams are working together to create these different outcomes. That helps make Asana really the best for cross-team work work work for the other work management products. What to you today, it's not so much in the future, but just what's going on right now, is most interesting to you about this huge proliferation of tools in both work management and knowledge management, which I would assume you think of as very different things. but there's just been so many interesting companies that seem to have sprung up out of nowhere in the last two, three, four years. What's your take on as a participant in this landscape, just watching the ecosystem itself today? Part of it is people are really embracing what's possible

with software and what's possible with some of these new delivering mechanisms like the web. I think that the history of a lot of technology is you sort of port old ways of doing things onto new mediums, emails or just digital faxes. And I think that a lot of the first versions of productivity software, spreadsheets and word processors, we're just sort of mimicking these flat formats that you have in the physical world. And now we're seeing people really break out of the box, think about what's only possible when you're in this pure relational database-driven way

of building and working with data. So I think that we're seeing the creativity sort of meet the technology and enable a lot of value for people. I want to go to the other end of the spectrum from where we started, which was the diminishing returns of hard work, to maybe what I'll call like the increasing returns of radical inclusiveness. This is a concept that you've written about publicly. I'd love to hear your thoughts on, maybe I'm phrasing it wrong,

you can correct me, but this idea of radical inclusiveness, what it might mean and what it feels like to participate in. I think it's really countering the status quo of people, thinking in very community or personality or identity-driven ways about who's allowed in certain spaces or to participate in certain ways. And I don't know if you've been to Burning Man East Coaster. It's just very physically embodying this because there's little kids there, there's hippies, there's people from the tech community, there's quite a few people further in age. I actually brought my parents one year. 95% of it, just whoever shows up is

totally welcome and embraced and included and encouraged to participate. And I think it's just beautiful expression of multiculturalism. And I think it's something that we aspire to within us on as walls. And I think it's certainly become a much bigger part of the national conversation everywhere. How do you think you get that to bleed from an idealized setting like Burning Man? What my favorite part of this post was how when you encountered the Winklevoss twins for the first time, your instinct was to hug them. And it was actually the first time you had met them, which is just a funny little episode that tells the story. What do you think is the key to bleeding that mindset, assuming you think it should be bled from unique setting, I'll call it like that, back into, you know, a company or a group of

friends or why doesn't it bleed faster? Why isn't the transmission rate higher? I think some of it is just patterns in status quo bias. So society is currently organized to not be radically inclusive. And so you actually have to kind of fight that, whereas Burning Man is both designed to be a step out of the current world into a completely different world in pretty much every conceivable way. So it just sort of resets your expectations. And it was intentionally designed with one of these core values built from a small group into a larger group that was representing those values. And I think that's one of the things that's really great about a company is if you think about culture very early on and are intentional about it, you can kind of foster some of these principles

and nurture them and build on them. You can be a lot more successful. If you successfully indoctrinate a certain value, 10 people, you're much more likely to have it when you get to a thousand or 10,000. And unfortunately, a lot of companies don't think about it that way. So I think the one other sort of big lesson from the beginning, I always try and tell new entrepreneurs is don't put this off. I think the conventional approach is focus on product market fit, see if you're actually still going to exist a few years later. And if you are, then start to think about culture and you sort of do this anthropological, let's go observe what our values turned out to be. I'll document them so that other people can have the culture be legible.

And that's fine, but it's just very path-dependent. Whereas literally, we sat down in the first few weeks and we said, this is the product we're going to build, this is the architecture, and this is sort of the cultural architecture. These are the values we're going to have in the principles. And they haven't been perfectly persistent. We started with maybe like 15 or 20 and have whittled down to more like seven or eight values. But like I was saying, the strategy, they're still thematically consistent and sort of

rhyme with each other. And I really attribute that to being able to start small and just turn that crank year after year, identify problems and identify divergences and try and bring things back towards our intentions. And there's still a lot of work to do. But I feel much more confident being able to do it successfully because we're starting with a strong foundation. You mentioned the early story of a new company. What do you think are the best reasons to start a new company versus going to work at an existing one? I think people have a lot of different reasons. Other people have reasons that I think are valid but don't resonate as much.

It's just like the lifestyle I want to have. I want to be the boss or maybe I want to actually have a personal small business that just affords ultimate flexibility and I can take six months off of the year. Those are fine reasons if you want to do that. But I think the thing that works really best is just being extremely motivated by bringing something new into the world that doesn't currently exist and that you think you're uniquely well suited to bring into the world. It's not going to happen without you in some sense.

again, this goes back to what I was saying earlier, if you need to just be extremely perseverant as a founder, that will be the why that kind of pulls you through all the difficult hows. And just to state what's obvious to me, but a lot of what you read about entrepreneurship in the press is a survivor bias. You're reading about the easiest, most successful stories, and you're seeing this Instagram picture perfect version of it rather than like all the messiness underneath. And you're not reading anything about the failures. I just really try and impress on people that entrepreneurship, it's going to be really hard, probably much harder than you think. So your motivation needs to be that much more sort of outsized to kind of bring you through it.

I know you reject one metric to rule them all, but just to use the one you said if you had to pick AARR, if we look out five or 10 years and Asana is 10 times the size on that metric that it is today, to what do you think that will likely be attributed? So what would have to happen for that kind of outcome for Asana to continue to creep in and solve more and more of this work about work problem. Well, I actually think it's easier than that because I think for 10x growth, we simply need more penetration into the existing market. We think of the TAM. It's about 1.25 billion knowledge workers. Right now, us and all of our competitors combined still only reach a very small fraction of that. So if you just take the existing deployments and actually get to the TAM, I think you can easily tell

a 10X growth story for Asana. Even within our existing customers, we're only about 3% penetrated into the employee bases. So we don't even necessarily have to reach new customers. We just have to actually expand those deployments in our existing ones. I feel pretty good about that possibility. It means that we also have to be the best product in the category so that we're the ones that reach that TAM rather than a competitor. But that's basically it. And I quite like the starting position for that race. I should have said 100x. I wasn't ambitious enough on your behalf. You mentioned product. You know, obviously you have to be the best product. Any pure product lessons that can share with the audience having built a fairly complex product that's evolved over the years.

Are there guiding principles or North Stars for good product that you could share in extra points if it applies even beyond software? I think it's worth diving into this process we use called Voice of the Customer. So I talked about leverage before. And we're very into leaderboards at Asana. So we actually create a stack, ranked list of these are the most promising opportunities to add more customer value. And we do this by aggregating a bunch of different perspectives on the customer perspectives from our support team, from the sales team, from the customer success team, from user research,

who's literally bringing people into kind of a formal lab setting and walking them through things. And they each sort of express their view on like the top 100 opportunities and give them their own ranking. And then we kind of do like a merge sort to get this unified leaderboard. And I think that ends up being a very robust process to actually point to us at the most important opportunities. And then I think meeting people where they are,

especially in terms of their adoption lifecycle. So Asana is designed to be really easy to adopt. It can be very lightweight when you're first getting started of literally this experience of your personal task list to mimic a blank sheet of paper, add a line, press enter, add another line. But then it can develop step by step into this really powerful, flexible tool

that can be used wall-to-wall and large enterprise organizations. But really trying to meet those people early in their life cycle, where they are of just starting with a single task or a single project and allowing them to focus on that experience and get to the power as it's needed and reveal it at those right moments. Sometimes you have to lead them to it too. So a lot of people adopt us on in a totally self-serve way, but the ones that adopted best probably do interact with our customer success team and certainly with a lot of our self-serve content to understand what we see

is the best practices for managing work in general and the best practices for managing work in Asana. Yeah, really just trying to do as much as you can to make the adoption experience successful and the product easy to adopt and use as possible. I'd love to hear a little bit about your work with the Open Philanthropy project, an idea and a project that I just find really intriguing. And having now talk to you for an hour, a lot of it makes more sense because I think some of the observations you've given us about Asana and business will rhyme with what you've learned at OPP, but can you describe that journey of yours and your families and, again, the major

divergent maybe lessons that you've learned about that world? After Facebook, my wife and I were left with what was a fairly large amount of wealth and decided we wanted to get philanthropy. And again, we were just very naive, didn't quite know how to go about doing this. So we started talking to other philanthropists and advisors and just trying to take those first few steps. And usually those conversations would start with what are you passionate about. I think that's the sort of like common thread in philanthropy is pick your cause area first and then strategize from there. Possibly as a function of being younger, we didn't really have that.

We're just thinking about it more like Elon Musk's recent tweet of we actually just want to be very effective. We want to do as much good as possible. We were cause agnostic. We had trouble finding people who would sort of meet us at that level, helping us choose the actual causes to work on that would help us maximize the. the leverage of the dollars we were giving away. So that's the sense in which it rhymes is I was trying to look at it like an investment portfolio or like a sort of building a product of I want to maximize

ROI. I want to stack rank with opportunities and go after the ones at the top. And we were very fortunate to meet the give well team who thinks about the world exactly this way. So now we understand there's this whole philosophy called effective altruism. This is what they do. They do strategic cause selection. And specifically they're looking for not just the most important causes in the world, but the ones that are most important on the margin, there's a lot of philanthropists already out there funding a bunch of things. What is not funded that should be funded because the marginal dollar going into it is going to have very high ROI. So they're looking for things that are important and they're neglected and then they're cost effective. Givewell focuses a lot on global

development and poverty alleviation, basically because a lot of philanthropic dollars in the U.S. are focused domestically. As soon as you take one of those dollars and you move it out of the U.S., it's immediately more leveraged because the need is so much greater outside of the U.S. So we still work very closely with Givewell, but we decided to start this additional organization Open Philanthropy project with the goal of looking for opportunities outside of global poverty and health and just looking for other causes that can sort of meet those three filters and have tremendous impact on the world. Are there a few of those causes that you might share just as examples of high leverage,

maybe underserved concept, which is really neat? One that's very germane is we actually started four years ago working on pandemics and biosecurity. I wish that we had started even earlier because a lot of the things we were funding ended up being very helpful, especially in the beginning as the pandemic was developing. But some of the things we were funding weren't quite to market yet, but would have been just tremendously useful. For example, at home, fast diagnostic tests. There's a few things we're interested in there that I think could have been transformative

and will be transformative in future pandemics. But we got into this because COVID-19 was possibly the easiest disaster to predict on the horizon. Bill Gates also talks quite a lot about this. We saw that it was neglected and we saw that there were a lot of opportunities on the margin to do great work. That's one specific area, which is part of a bigger group that is called global existential risk. So the other one that looks like that is risk from advanced artificial intelligence. One other category that I think is very illustrative of factor valtruism is we actually work on factory farm animal welfare. which a lot of people say moral worth of a cow or chicken is not worth thinking about it

at all until all humans are out of poverty and living great lives. But if you think they're even worth a very small fraction, one 10,000th or one millionth, even, the opportunities on the margin are so effective that it ends up being an incredibly important area for philanthropic dollars. And again, there's a lot of philanthropy that is an animal welfare, but it's usually focused on the animals that people are more familiar with. So cats and dogs or wild horses. and I want those animals to have great lives,

but the fact remains that there are literally billions of animals going through the food system every year, living lives that involve quite a lot of suffering. Relatively small amount of philanthropic dollars, you can actually make quite a lot of progress there in doing things like moving more supply chains towards sourcing eggs from cage-free chickens or improving the standards for dairy cows or for pigs.

That ends up being this kind of interesting example. It's a little weird to a lot of people. It's definitely not what most philanthropic would think of first, but you just look at it analytically, R.I proposition is just so clear. It's actually how I first heard about your work in this area. I have a friend whose ambition is to do this for chickens most specifically. Same argument, right? Like, it's shocking the volume of these things and how bad the conditions are and how far the early dollars go in making meaningful change to the problem. I just think it's such a fascinating way to think about the world.

I want to just ask one more question on the, called the future of artificial intelligence. I was going to ask as well how you think AI figures into Asana's product and mission because you've got this work graph. It seems like something ripe for training models on top of, lots of data, lots of transactions or processes that you can map. So I guess I have a two-part question. What's the agony and the ecstasy of the future of artificial intelligence on the good side as it pertains to Asana and on the bad side as it pertains to humanity writ large? Oh, man. Answering that one answer it will be a challenge. I'll start with the good side with Asana. A lot of what I've described, this idea of the work graph, the pyramid of clarity. One way to think about it is really helping

you create a map for how work is happening in your organization. And maps are very useful, but something that makes them even more useful is having a sort of navigation system that helps you find the best paths through that map to reach your goals. Artificial intelligence at Asana will really be about that, helping identify bottlenecks or ways of shifting focus around to minimize the time and effort it takes to get to a certain goal. And we can do that in simple ways. For example, we have a resource management feature in Asana right now. And just with simple heuristics, it's not AI, we can show you these people are overloaded. These people maybe have some more space. We can sort of suggest, well, maybe you should move this particular work to these

other people. But it can get infinitely more sophisticated as we understand, well, this is the type of work that Catherine does all the time. And a new task just popped up. And it's unassigned, and we can sort of read the title and description of that task and understand. Catherine would be a great person in the organization to take this on. Holy grail version of this is what we think of as almost Spotify playlist-like experience for individuals where the system knows everything that's assigned to you. It knows when it needs to be done and what's most blocking other people's work, and it just tease things up to you one at a time.

This is what you should work on now. It's what you should work on next. Schedule all your meetings for you at the right times when it's most convenient and corrective for everyone. And then from the team leader's perspective, doing that before things are assigned, just putting all the things in the system, the system tells you these three should be assigned to person A and these three should be assigned to person B. You should do them in this order. Here are all the dependencies, map out the whole Gant chart for you and tell you when you're going to be done. That would be the sort of ultimate expression, I think, of artificial intelligence in the

system. I think fortunately we can do a lot of these things piecemeal, simple heuristics that build into more complex technology and save people time along the way. So that's the good part of AI. Just interrupt you for a sec, before we go to the bat, it really puts the 60% thing in an interesting light. If you agree that a lot of progress, especially technological, which drives leverage, will be made by knowledge workers and 60% of their time is spent on work about work, then all of a sudden, this Spotify playlist genius idea is not a trivial thing. Like, you're talking about a forced magnifier on productivity growth, which is just like the coolest concept. So sorry to interrupt, but that really helped me understand the scope here in an interesting way. So back to the end of the

world, back to the end of the world. What's going to, what do we need to guard against? There are two things really, and this is true for the bio area as well, which is there's accidents and there's misuse. I think when you talk about AI, you hear a lot about the accidents and runaway paperclip machines and sky net. I think that stuff could happen, but it's less what concerns me and more the misuse, especially in the near term, because you don't actually need SkyNet level intelligence to do very bad things in the world. In fact, I think you can look at autocratic governments today and see them using artificial intelligence to do things like free speech suppression, classifying people who might be counter to the government in some way and then

directly oppressing them. I think those are already existing misuses of AI, and it's going to get worse over time as we start combating AI into autonomous weaponry. Just basically think about, if you look back on the history of the most evil people in the world, they have the same goals, but now they have AI to help them achieve those goals. It's not good. Yeah. Very difficult problem. There are no easy answers in how you mitigate it.

But it definitely rises to the level of being a civilization existential risk, both in terms of you could lead to an outcome like global nuclear war that literally wipes people out, or you could lead to just a very perverse dystopia of an autocratic, oppressive government that just has perfect control. And there's nothing people can do about it because the AI is just perfect that's suppressing everything. Those are my scary nightmares about the future and your future, unfortunately. So it's not to end on that note. It's a great use of my traditional closing question, which I ask of everybody. And that question is to ask what the kindest thing that anyone's ever done for you is. When I was starting off as leader of Facebook, I was very young and I was not.

very wise. So I think like a typical 20-year-old, I was just full of ego and arrogance and budding up against a lot of the other people in my work life. And when I disagreed with somebody, they were not only wrong, but they were bad. They were an enemy. Brought out all my worst instincts to people. And so I spent a lot of time just sort of raging at my peers and being destructive. And a couple people helped me work through this. And one in particular is Adam DeAngelo, who's the CEO of Cora. And he's also one of our board members. But we were getting in a couple of these conflicts and he would never, some people just like sort of rise to the challenge and their ego comes into it too and you're just flooding heads. And Adam was just totally chill about it and just working

through the disagreements and eventually just sat me down and was like, why is this so hard? We can disagree without it meaning that you have to hate me. It just sort of gave me this alternate way of looking at it of when you disagree. It probably just means we have a difference of assumptions somewhere. What we should do instead of trying to assert through emotion that one of us is more right is just to try and decompose the problem and analyze it and figure out what those assumptions are. That takes all the motion out of it because maybe we'll change each other's mind on what those assumptions are. But at the end of the day, they're just a set of facts that you can be more objective about. And I'm still learning to have conflict in this style. But I think that really

sort of jump started me to a different way of being able to collaborate productively with my teammates. Well, I love it as a closing story and lesson in the conversation full of lessons. I now understand Asana in a much more clear way than I did before in terms of its potential and its impact. So this has been so much fun. Thank you so much, Dustin, for your time today. Thank you for having me. To find more episodes or sign up for our weekly summary, visit investorfieldguide.com. Thanks for listening to Founders Field Guide.